[crm]

I think those guardrails often help with the humility the article discusses - they reduce cognitive load, and let you focus on the problem at hand, at the expense of expressing total creativity. It's a tacit admission that we aren't all knowing, and often need help from our tools to save us from ourselves.

[lmm]

I find it's just the opposite - when working in a Java codebase you can't focus on the actual problem because you have to spend so much of your time reading past the needless verbosity - or, often, debugging the crazy reflection framework that your organization has introduced because that verbosity became intolerable.

[ratww]

I think you're both correct.

I find that the language itself is quite good, simple to use and has some nice features and performance... but the issues you mention are also there, however they're part of the frameworks and individual codebases.

[marcosdumay]

> crazy reflection framework

Did the Java community get over their love of code generation already? Last time I used it, I'd debug the crazy 1000's of computer generated lines that people changed here and there.

[lmm]

That's never been my experience in over 10 years of JVM work - people mainly use reflection or bytecode manipulation (aspectj) to do the kind of things you'd use code generation for. The only exception is thrift/protobuf and that's dumb serialization code that hopefully no-one's editing.

[marcosdumay]

Oh, the last time I've made any extensive use of Java was more than 10 years ago. I've met an off the shelf code generation based platform on the meantime, but luckily it was deemed too expensive so I didn't need to even finish a technical evaluation (much less use the monstrosity).

Anyway, that is great news. That unexplainable love for code generation was one of the things holding the language back. It's always good to see things improve.