Earlier quoted context omitted.
The IDE support is pretty good these days, as least in IntelliJ.
Not sure why you were downvoted. IntelliJ’s Scala plugin is top-notch in my experience.
+1 works great
Lombok makes Java cool again
181–190 of 239 posts
Re: Lombok makes Java cool again
#182Earlier quoted context omitted.
I liked to refer to the genre as MOP -- Magic Oriented Programming. Every ecosystem I've seen go down that route ends up bailing out. A good example of this would be Apple's Cocoa Bindings [1] on macOS that were killed with fire when the iOS APIs were defined, and KVO [2] which is flat out rejected at every company I've ever worked. On the other hand, when built into the language, this kind of explicit but automatic…
Rails would be the opposite example. Magic all the way down and the ecosystem is not even contemplating the idea of bailing on it.
I recall my limited time with Ruby and Rails being the really frustrating, seconded probably only by Tornado (either misleading error messages or no error messages whatsoever, requiring me to get dirty with the debugger for the most minor of things).
RubyMine had no idea about more than half of the Ruby code being written in the project. I couldn't grasp the concept of symbols in Ruby reliably enough. E.g. methods used either symbols or strings - I couldn't discern a pattern for which to be used when. This was the magic part of it - things seemed to work seamlessly but when they wouldn't, I had no idea where should I even begin to look.
Also every file had to be annotated for the strings to be treated as immutable. No ways to set it globally, project-wide.
It felt like a mess. On the plus side, there were gems.
Re: Lombok makes Java cool again
#183Just switch to C# already.
/s (just a bit)
Re: Lombok makes Java cool again
#184Earlier quoted context omitted.
Rails would be the opposite example. Magic all the way down and the ecosystem is not even contemplating the idea of bailing on it.
Yes, but as a programmer when I'd start working on a new project, I would call it a Rails project, I've never heard of a Lombok project. Sure, I've seen Spring/J2EE projects that used Lombok... some 10 years ago, but the idea seemed to have died down, maybe it's my own bubble. Automagic is ok for a specific type of problem (Rails for webaps?), Lombok however reminds me a bit of the promises of AOP which failed to gai…
> I've never heard of a Lombok project.
You've must have heard about Spring projects. I'm yet to come across a Spring project that doesn't use lombok.
> Sure, I've seen Spring/J2EE projects that used Lombok... some 10 years ago, but the idea seemed to have died down, maybe it's my own bubble.
Perhaps it's my bubble as well but I'm still seeing Spring projects in production today that feature lombok extensively.
Not all organizations are willing to burn through cash to jump to the flavor of the month every couple of months. If you deployed a system and the system works, you need to discover a very good reason to throw a revolution and start from scratch with a new tech stack.
Re: Lombok makes Java cool again
#185Why do you need to write all these getters and setters? Why not just a public property?
Re: Lombok makes Java cool again
#186Earlier quoted context omitted.
The same can be said about Scala and Groovy. (Groovy brings in those generators via an annotation)
Of those three (Kotlin, Scala, Groovy), Kotlin is by far the most pragmatic. Scala is nice, more powerful, but has a high cost when it comes to learning curve, complexity, and the library ecosystem. I'm not sure of the state of Groovy at this point after it got transferred to the apache foundation. Kotlin on the other hand strikes a nice balance in many areas.
Kotlin got a major push on Android, thanks to a stagnant Java 8 support.
With ChromeOS and Fuchsia on the game as well, it remains to be seen who will win Google's internal OS wars.
So far Android seems to be the one taking them all, though.
Outside Android I don't really see a major benefit switching whole teams away from Java, Eclipse/Netbeans and rewriting/wrapping libraries to be idiomatic Kotlin and such.
Re: Lombok makes Java cool again
#187Earlier quoted context omitted.
Scala syntax is decent tbh, unless you decide to go overboard with operator overloading. Most libraries — SBT is one example — have shifted away from the use of excessive overloading.
Tend to agree. But if you work in a team, there will be someone who just loves implicits and overloading and you won't be able to change his mind. Strong code style policies help, but they are really rare in real processes.
Your team can make a decision as a group to not allow defining operators in the team's codebase. As you mentioned you can then enforce that with scalastyle (set FieldNamesChecker and MethodNamesChecker regexes to ^[a-z][A-Za-z0-9_]*$). Is that not enough to handle the one person who loves overloading?
Re: Lombok makes Java cool again
#188Annotation-based programming might seem cool now, but wait a few years. Magic always seems cool when you add it to a project - hey, look - I don't have to do anymore. Then time goes on, and you (or your successor) opens up the project to track down a bug. Only there's no logical flow - things just seem to happen as if by magic. Lombok strikes me as magic in these ways. I actually had to go to the project home page to…
Remember the days of Aspects all over Java codebases?
I seemed a cool idea, however I thankfully no longer need to fix bugs in such projects.
Re: Lombok makes Java cool again
#189Annotation-based programming might seem cool now, but wait a few years. Magic always seems cool when you add it to a project - hey, look - I don't have to do anymore. Then time goes on, and you (or your successor) opens up the project to track down a bug. Only there's no logical flow - things just seem to happen as if by magic. Lombok strikes me as magic in these ways. I actually had to go to the project home page to…
> Annotation-based programming might seem cool now, but wait a few years. I even have this experience on my own projects and with much shorter span than a year. When I go back to a code base I worked just 3-4 month ago -- I have very hard time following Dagger injections. Braking one of the Dagger providers (I use dagger 2) creates 10s and 10s of compilation errors. So I have been slowly removing dagger from my code…
Thats fairly funny, since I find Rx to be the very complicated thing if used extensively in a project and hard to reason about memory usage and other things when trying to dig into problems.
On top of that it creates huge ass stack traces that makes finding your code difficult unless your debugger can filter out specific packages:
https://github.com/ReactiveX/RxJava/issues/4834
Kotlin on the other hand is a fairly clear language!
Re: Lombok makes Java cool again
#190Earlier quoted context omitted.
The IDE support is pretty good these days, as least in IntelliJ.
Scala support in IntelliJ is ok, but still not great. There are some Akka constructs IntelliJ underlines in red for years and JetBrains doesn't fix it. I've never seen something like that with Kotlin. The hard truth is that Scala was not designed with tool support in mind and it probably never will be. For example hierarchical implicit conversions, while powerful, are terrible for tooling.
> Scala was not designed with tool support in mind and it probably never will be
You should pay attention to what's going on in the ecosystem. Dotty comes with LSP support. The Scala Center's main focus is tooling. JetBrains has been pretty committed and cooperating as of late. And several projects are building serious alternatives to SBT.