undefined | Better HN

0 pointsjosephg2y ago0 comments

The enterprise java programming style is worth avoiding because it’s a productivity killer. This style obscures your business logic, it makes debugging harder through needless indirection, and it creates pointless busywork from the need to write, maintain and document reams of unnecessary boilerplate.

Foundationdb has official bindings in C, Python, go, Ruby and Java. The real bindings are in C, and all other languages’ bindings are well written, idiomatic wrappers around the same C library exposing the same functionality. The Java bindings need over twice as many lines of code as the Ruby and Python bindings to achieve the same thing.

Even if this style of Java is only 10% less productive than that of idiomatic Kotlin, Go or Python, you will probably break even on the investment of migrating languages after mere months. I think that undersells it. The productivity difference is probably much higher. Especially for large projects.

Improving your personal and teams long term productivity is just about the highest value work you can do.

0 comments

stcroixx2y ago

All subjective. That style has plenty of people who don’t agree with any of your criticisms and could list many of what they consider benefits. It would also be very difficult to prove that extra lines of code have any financial impact, let alone one that could be recovered in a matter of months.

klibertp2y ago

I understand your viewpoint, but I think it's a bit too pessimistic. While we essentially don't know how to consistently write good code and deliver quality products on time (the whole industry, save for some niches, has this problem), it's also improbable that nothing we could try would get us closer to that ideal. Not too close to it, perhaps, and not in a matter of months, and not by simply switching one set of rules of thumb for another, but surely, there's got to be something that can have a noticeable impact. Especially over longer-term and in larger codebases.

Trying to replace X with Y, where both have similar expressive power and similar drawbacks (i.e. FP vs. OOP), won't help much. Not on its own, and not without many other conditions being met, including completely non-technical ones like the personality of a hiring manager. Surely, though, in every paradigm or style, it's possible to write better or worse code, right? So it should also be possible to create an environment where the code quality, on average, would be just a bit better than the norm.

I'm not looking for quick gains for a single project, but rather a medium-term strategy that can save the effort required to develop and maintain products. People who claim to know how to "get good code quick" are mostly swindlers, and it's really hard to confirm causality in practice, but we shouldn't give up on finding ways to get better-than-average results in development.