Hacker News Reader

Comment by arcticbull | Hacker News Reader

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 code generation can be awesome (as in Rust's #[derive()] traits [3]) but I think the difference there is the compiler/language vendor agree to support it indefinitely.

[1] https://developer.apple.com/library/archive/documentation/Co...

[2] https://developer.apple.com/library/archive/documentation/Co...

[3] https://doc.rust-lang.org/rust-by-example/trait/derive.html

View on HN

> An alternative approach to Lombok would be to think about how the project ended up with so many dumb data classes.

Mapping entities to/from data transfer objects is a well established technique, as using dumb POJOs to drive serialzation/deserialization.

If you throw CQRS into the mix you can get a POJO/endpoint ratio that is greater than 1:1.

Do you want to write bug-prone boilerplate code for all those POJOs you are forced to write? Or do you prefer to simply add lombok to the project and add a single class annotation?

It's disingenuous to blindly criticize the extensive use of POJOs and DTOs as if it was code smell. In some applications it's quite the opposite. There is a ver good reason why lombok is very popular, as are other projects designed to complement it. In .NET Core land, where POCOs are used extensively, AutoMapper is also a must-have just because the need to handle POCOs without having to write all the boilerplate code is very real and pervasive.

Why bother with getters and setters for a POJO though if it’s all in a project you control? You can always make a property private later if you really need to add behavior to the fetcher.

Rails would be the opposite example. Magic all the way down and the ecosystem is not even contemplating the idea of bailing on it.

Good point!

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 gain traction outside frameworks.

There are other highly opinionated frameworks/stacks that have mixed adoption in the java world -- jhipster seemed to gain some traction, but people seem to just use bare spring boot nowadays(which is quite opinionated)

I don't have absolutely anything against small projects, I'd love to work more on smaller projects, but 18000 lines of generated code is NOTHING, try to convince a medium team to use Lombok, you'll very soon end up with people loving or hating it, removing it for debugging purposes, creating their own generators and very soon it's a real mess. But all that is just my experience, I'm not trying to dismiss Lombok or any approach, if it works for you, great!

> 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.

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.

Reply on news.ycombinator.com