Lombok makes Java cool again • Hacker News Board

Re: Lombok makes Java cool again

#151

Post by ArloL » Fri, Feb 01, 2019, 6:42 AM UTC

blr_traffic wrote: post #141

ehnto wrote: post #133

Earlier quoted context omitted.

I see the opposite. I see an industry all too willing to throw away years of hard earned knowledge, experience and purpose built tools in order to chase the shiny tools the popular kids are using. New tooling often follows a commom cycle of being light weight because they ditched the stuff that looked unecessary. Then slowly a whole ecosystem of plugins and libraries springs up to rebuild the missing tools. Like the…

> an industry all too willing to throw away years of hard earned knowledge, experience and purpose built tools in order to chase the shiny tools the popular kids are using. Why do you think people in the industry are doing this? There must be multiple factors behind this.

My take on it is that it boils down to the profession being so young. Since it's so young we have a lot of young developers ( [0] http://worrydream.com/refs/Brooks-NoSilverBullet.pdf

[1] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/E...: the business community, which, having been sold to the idea that computers would make life easier, is mentally unprepared to accept that they only solve the easier problems at the price of creating much harder ones

[2] See why Martin Fowler stresses Technical Excellence basically every time he get's on stage: https://www.youtube.com/watch?v=G_y2pNj0zZg

Re: Lombok makes Java cool again

#152

Post by jicea » Fri, Feb 01, 2019, 6:42 AM UTC

kodablah wrote: post #108

rufugee wrote: post #96

Earlier quoted context omitted.

As someone considering using Kotlin for my next project, your comment is interesting. Care to share what flaws you've uncovered?

Assuming it's for the JVM, you should definitely choose Kotlin for your next project. Most of the flaws I find are for advanced usage (e.g. interop, coroutines, etc) or tooling (e.g. gradle issues, dokka) or just general advanced language use. I don't keep a running list of issues (I made one back in the day [0] but not all of it is still applicable), but nothing would keep me away from the language. It made a lot of…

Jetbrains has a very good 4 weeks free course on Coursera https://www.coursera.org/learn/kotlin-for-java-developers. We’ve beginning to introduce Kotlin in our code based, and also begin to use Kotlin Dsl on our new Gradle projects; for the moment, the experience is excellent. Interop with Java is really good and the support from IntelliJ is also fine.

Re: Lombok makes Java cool again

#153

Post by jrockway » Fri, Feb 01, 2019, 6:44 AM UTC

fogetti wrote: post #103

zestyping wrote: post #83

Reading this just reminds me of all the terrible things about Java. The lack of reasonable default string representations, comparison and hashing methods, etc. are all glaring mistakes in the language design that have wasted huge amounts of time for millions of programmers. It's as though Java programmers are so deep in the grips of Stockholm Syndrome that ordinary, sensible behaviour seems amazing and "cool". This i…

I am sorry to disagree but if you think that the iterator or visitor pattern or the state pattern or abstract factories are only bound to Java than you have a very low skills/understanding of those patterns and you really don't understand their importance and/or applicability.

I think it's a cultural thing. Other languages don't name things that seem obvious, like iterators or filters. Consider something like filepath.Walk in go; you give it a function that gets called for every file and directory in the root of your choosing. They don't call it a visitor, though, they call it a "walk function". It's just as clear, it's just as much of a design pattern, but they don't make a big deal about it.

Meanwhile, I'm sure in Java that you have to implement some class that is the visitor, which means you have to create a new file, and probably install some VisitorUtils for making file visitors easier to implement, ... that is where it's gone off the rails. (But I am perfectly willing to believe that the exact same API exists somewhere in Java too, and most people browsing directory trees don't have 13 classes to print the names of the files in a directory. But at the same time, I feel like there are pressures pushing you in that direction. That's where the complaints come from.)

Re: Lombok makes Java cool again

#154

Post by edejong » Fri, Feb 01, 2019, 6:45 AM UTC

chii wrote: post #105

zestyping wrote: post #83

Reading this just reminds me of all the terrible things about Java. The lack of reasonable default string representations, comparison and hashing methods, etc. are all glaring mistakes in the language design that have wasted huge amounts of time for millions of programmers. It's as though Java programmers are so deep in the grips of Stockholm Syndrome that ordinary, sensible behaviour seems amazing and "cool". This i…

> all glaring mistakes in the language design that have wasted huge amounts of time for millions of programmers. i would think javascript is the language with which the mistakes wasted the millions in man hours, not java.

And the DOM, CSS, HTTP and ad-hoc HTML extensions.

Re: Lombok makes Java cool again

#155

Post by edejong » Fri, Feb 01, 2019, 6:47 AM UTC

jrockway wrote: post #149

fraggle222 wrote: post #91

Earlier quoted context omitted.

You either like strongly typed object oriented langs or you don't. If you do, then a bit of verbosity is really nothing. If there are actual lang improvements beyond saving me a few characters, I'll take them.

I don't think that any of Java's warts are related to liking strongly-typed object oriented languages. I think the standard library is Java's biggest problem (read through the code that's been around since the 1.0 days, it's AMAZING in the way that a car crash is amazing). The community has done a good job building a better standard library (back when I did Java it was Guava, maybe that's not the state of the art any…

All these words for saying: I think class inheritance is a bad idea. Lots of folks agree. Rust might be your thing!

Re: Lombok makes Java cool again

#156

Post by Illniyar » Fri, Feb 01, 2019, 6:48 AM UTC

arcticbull wrote: post #135

apo wrote: post #132

Annotation-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…

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.

Re: Lombok makes Java cool again

#157

Post by twblalock » Fri, Feb 01, 2019, 6:51 AM UTC

Terr_ wrote: post #111

twblalock wrote: post #18

Earlier quoted context omitted.

The problem with checked exceptions is that any method can throw runtime exceptions, whether it declares checked exceptions or not. So the presence or absence of "throws" does not really change your approach to error handling. An exception might happen either way, so you need to exercise the same level of care either way. Furthermore, checked exceptions force you to bubble up implementation details all the way up to…

Your second paragraph has a direct-equivalence to complaining about return-types and advocating that everybody should just specify "Object" to make things easier. ( https://imgur.com/iYE5nLA ) In both cases it's about constraining and describing the results from a method. The only difference is that most developers are so much more accustomed to thinking and coding along the happy-path, where they will willingly do a…

Declaring only some of the things that might go wrong, which is the case with checked exceptions, does not solve the problem you described and only makes it more difficult to write code.

If every kind of exception was checked, then every method in Java, including constructors, would need to declare that it throws RuntimeException and IOException and NullPointerException and NoClassDefFoundError and InterruptedException because those things could happen in any method.

So we settle for declaring the type a function is expected to return, with the understanding that if something exceptional occurs a magical thing called an Exception will be thrown and it's not handled the same way as a return value. This lets us get our jobs done. It's engineering, not science.

When you solve the halting problem we can talk about formalizing every possible failure state as a return value. Until then we will get on with our lives.

Re: Lombok makes Java cool again

#158

Post by Tharkun » Fri, Feb 01, 2019, 6:51 AM UTC

chii wrote: post #107

Tharkun wrote: post #51

Earlier quoted context omitted.

> My main issue with Java is all the annotation based programming. That seems like an easy problem to solve. Don't use annotations. Snark aside, it can be a bit of a tricky balancing act. When there are more annotations than actual code, that's a code smell in my book and something needs to change. Separating concerns usually does the trick. I'm heavy on code generation, so anything that's boring enough to benefit fr…

why differentiate annotation from non-annotation code? they are both code, and they are both lines you have to maintain/debug.

That's a fair point. IMO it's easy to mix a whole array of concerns with annotations, much more so than what you'd likely do in 'normal' code. Some annotations are really compiler instructions ("don't print these warnings"), some influece the build process, some are AOP entry points, some add runtime behaviour etc, some are security related etc. I guess I like things to be simple.

Re: Lombok makes Java cool again

#159

Post by pjmlp » Fri, Feb 01, 2019, 6:57 AM UTC

ganonm wrote: post #3

Lombok is a useful crutch if you're writing lots of Java code on a day to day basis. However, given how easy it is to use Kotlin alongside Java I would question whether Lombok is the right solution to the problem. Kotlin has data classes which auto generate sensible 'toString' and 'hashCode' methods which is a massive time saver. Really, if you are considering introducing Kotlin to a Java project I'd recommend you ju…

Kotlin has not flawless integration and some attention is required when writing libraries for Java consumption.

Additionally the JVM wasn't enough for JetBrains and code written for multi-platform has slightly different semantics (see Kotlin/Native and immutable data).

Kotlin is a good alternative on Android due to a frozen Java 8.

Against Java 12 not so much.

It is very hard to displace platform languages when others just feel like guests.

Re: Lombok makes Java cool again

#160

Post by patelh » Fri, Feb 01, 2019, 7:03 AM UTC

Why not just use Scala, you get all of that out of the box, no need for annotations, and you can still maven ;-)