Hacker News Reader

Comment by wpietri | Hacker News Reader

Java is boring in one sense, but it's the wrong kind of exciting in another. I've had to touch it a couple times in the last few years, and there's still a ton of "enterprise" nonsense in the space. Everything feels bloated, confused, unpolished. It's like I'm walking along, step on a trapdoor, and suddenly am sucked down into a tangle of stack traces, class loaders, annotations, and XML configs.

For me, part of "boring" is being like a 2x4 or a claw hammer: simple, solid, reliable, well understood. A lot of the Java world is nothing like that.

View on HN

> For me, part of "boring" is being like a 2x4 or a claw hammer: simple, solid, reliable, well understood. A lot of the Java world is nothing like that.

TBH, this is exactly what the Java world is like. There are not many surprises in Java land. The language isn't getting fantasy land changes on a daily basis. There are libraries that haven't been updated in years because there hasn't been a need to update them - they just work. People want to leave Java because it's boring.

Is Java perfect? Of course not, no language is perfect. But, Java is the closest thing to a boring 2x4 the programming world has ever invented.

Java the language is decently boring, (although I appreciate how Kotlin has tried to advance while staying pretty boring). But not Java the ecosystem. When I returned to using Spring a couple years back, I thought, "Well, it was rough then, but I'm sure they've worked out a lot of the kinks." Nope. It had become more complicated and less reliable. I know a lot of Java-land stuff seems fine to people who live in enterprise-land, where people have a very high pain tolerance and no particular urgency around getting things done. But for me that's not the right kind of boring.

Java also seems to bring with it a lot of cultural baggage for bloated design thinking, like needing overkill factory patterns, accessor patterns, and more.

If you start creating something called AbstractMonthlyBillingReportAggregatorFactory that inherits from AbstractBillingReportFactory that inherits from AbstractReportFactory all of which implement a Report interface, things have gone unsalvageably far off the rails to be useful any more.

It’s fair to say you could do this same thing in C++ or Python etc., and sometimes that does happen. But just anecdotally observing this in many companies, it happens _on purpose_ with Java all the time, but much less so in other ecosystems. In other systems it’s just much easier to get things done without resorting to tons of inheritance misdirection, and many great common libraries already solve problems in those ecosystems with minimal inheritance bloat, giving lots of easy to follow examples.

This is true about enterprisey patterns, which for some reason plague Java more than other languages. I think it's a flaw of the moment in time when Java became ubiquitous -- I mean, it still runs most software than many fashionable technologies these days, but it's not as dominant as it used to be -- rather than the language itself. Modern Java doesn't look like that, but indeed older software built with it did.

These are fashions in the software engineering world. Had Ruby dominated the development world at the time Java did, you would have seen the same enterprisey patterns.

I think that’s largely true, but not completely. It just turns out that certain language features sincerely matter more for business software, such as rapidly mutating object & data models without needs to update them as a ripple effect through other designs in the system, and the ability to trade-off safety or correctness as resources just like memory or runtime complexity, which Java as a language is just not set up to do easily.

Maybe my brain is slow today, so please excuse me if this is not what you're saying. Are you arguing that Java is not set up to "do easily" business software or rapidly mutating data structures? Because Java as a battle tested platform has evolved many cool features for exactly those cases. There are even commercial pauseless garbage collectors (and the noncommercial ones are pretty advanced, too). Java and the JVM run circles around many of the technologies that became fashionable later, such as Ruby or the many javascript frameworks.

For an article about "stick to boring and reliable" there seems to be too much push back against Java. I understand the psychological processes involved: stick to boring unless it's the one technology one personally finds unpalatable -- for me that would be COBOL or ColdFusion (and yes, I'm aware Java has been compared to COBOL by proponents of trendier technologies! :P )

A reliance on object orientation as a non-negotiable language requirement is intrinsically antithetical to efficiency for business software.

If a language supports what I would call “lightweight OO” - extremely low boiler plate, zero required OO constructs (purely optional), and language features that render the concept of dependency injection intrinsically obsolete (because mocking can be done purely through introspection at no cost), then that flavor of OO is well suited for business problems.

It has less to do with things like JVM or GC oddities, because those can be straightforwardly engineered around. It’s more about what non-negotiable commitments to specific patterns or strategies come along with the language choice.

Pure functional languages are the worst offenders in this area, which is why their benefits aren’t actually benefits and they are poorly suited for business software. Of the core “industry standard languages” Java would be the next worst offender.

Conversely, I think C# is an ecosystem that suffered the same limitations as Java but found ways to extend and reinvent that make it more attractive now, though still far behind Python, C and C++.

> A reliance on object orientation as a non-negotiable language requirement is intrinsically antithetical to efficiency for business software.

and

> Pure functional languages are the worst offenders in this area, which is why their benefits aren’t actually benefits and they are poorly suited for business software. Of the core “industry standard languages” Java would be the next worst offender.

You seem to be talking out of principle instead of actually having hands-on experience developing large systems in Java. To be honest, it doesn't seem you're familiar with the language or the platform.

I'm not interested in debating your theoretical preconceptions.

I work in a company whose core systems are all written in Java, I deal with modern Java every day.

Well, it really, really doesn't show. I'll have to take your word for it. I suppose your company is doing badly, since Java is really not suitable for its needs?

You seem likewise uninformed about functional programming and how it has been used to write extremely high-performance fintech systems.

No, mlthoughts2018 doesn't "seem" that way. You have decided they are, and are camouflaging your personal chosen interpretation with false objectivity.

Sorry, I'm even less interested in arguing with what you think of another user who doesn't need your help defending their point.

In any case, that Java's OOP cannot be successfully deployed for business software is counterfactual. Anyone insisting on that point is unfamiliar with Java.

> Which for some reason plague Java more than other languages.

Is the reason a mystery? Java is the language that got a multibillion dollar marketing pitch at its inception. It was designed to be in "the enterprise" from day 1.

I'm not saying it's exactly a mystery. Java had the misfortune of being ubiquitous when XP and design patterns became all the rage. Every intern using Java had to learn "patterns", and schools where teaching them too. Heavyweight frameworks like Spring (and before that, EJBs( were all the rage too. It took a lot to extricate modern Java from that situation.

sorry i think I misinterpreted when you said "for some reason"

Yeah, boring vs exciting is a false dichotomy. Early-2000s Enterprise Java is neither - it's intimidating, because the code is so bureaucratic that it's impossible to properly understand the implications of any given action, and bureaucratic software is inherently buggy in my experience because there are so many interactions that inevitably something will trip over an unexpected edge-case of some other thing.

> For me, part of "boring" is being like a 2x4 or a claw hammer: simple, solid, reliable, well understood. A lot of the Java world is nothing like that.

Strong disagree. This is exactly what most of the Java world is like: well understood and reliable. I wonder if people who say things like you did actually use it for their day jobs, or rely on things people using other technologies claim in their blogs.

Wonder no more! Two years ago I did a 9-month contract in Java. I have used Java for consulting gigs going back to 2000. I honestly expected it to be a pleasure to work with this most recent time in hopes that things were usefully boring. That was not my experience.

Java is very similar to C++. Its boring in the sense that most things have been around forever and really old code is terrible but you still have to deal with it because backwards compatibility is so good. If you don't consider Java boring I wouldn't consider C/C++ boring either.

Reply on news.ycombinator.com