5 ms·

Java is miserable to write. You don’t realize this until you work with other languages. It was literally built with guardrails to keep enterprise coders from ge

Java is miserable to write. You don’t realize this until you work with other languages. It was literally built with guardrails to keep enterprise coders from getting too creative

podunkPDX 5y ago
I can’t speak to the actual act of Java development, but I can speak to Java applications from a sysadmin perspective (15 yr Sr. QA Engineer to a 3 yr Linux admin (don’t ask)) — I’ve got no real beef with Java from the development side, but maintaining some of those stacks in production is pure pain.
- lmm 5y ago
  Huh? Java is probably the least demanding stack from the sysadmin side - no big chains of library dependencies, no docker, strong backwards compatibility that means you can fearlessly upgrade the language. All you have to do is keep an up-to-date JVM installed on your servers and deploy single-file fat JARs to them.
  - lovasoa 5y ago
    Until you get an out of memory error. Then you need to start fiddling with the JVM. Or until you realize that you have a 99th percentile latency of multiple seconds...
    - lmm 5y ago
      No language is immune to slow or memory-hungry code. The JVM is probably the easiest runtime to monitor/instrument/profile (and it's not like having no runtime makes that any easier, quite the opposite), and has probably the most tuneable GC going. I guess enabling your users to do that might be work for a sysadmin, but that's more a reflection of those users having higher expectations for Java than for other runtimes - providing your users with the same capability in other stacks is never easier than Java, and often significantly harder.
    - oblio 5y ago
      There are only a bunch of out of memory errors, though. And they're easy to fix.
  - smitty1e 5y ago
    Then you get into managing a collection of Java projects where each on ships its own JVM and keystore to obviate version issues. And then you have to deploy certificates against all that. I'm not bitter.
    - twic 5y ago
      The keystore situation is indeed poor. For several years now, it has been possible to do more key management in-app, so you don't need to manage keystores (i have written programs which pull standard PEM-encoded keys from environment variables). But the practice of using a JKS keystore is so ingrained that it's very rare to make use of that.
crm 5y ago
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 5y ago
  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 5y ago
    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 5y ago
    > 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 5y ago
      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 5y ago
        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.
livesinhel 5y ago
> It was literally built with guardrails to keep enterprise coders from getting too creative Just as Go.
- saagarjha 5y ago
  Go somehow takes the worst bits of Java in this regard and makes them even worse :(
goto11 5y ago
Yes lets rewrite everything Ruby on Rails and CoffeScript, it is just so much more productive and creative! At least this was the opinion on HN a few years ago. Now of course other tools and languages are fashionable. And nothing against Ruby or CoffeScript per se, but the demands of an enterprise where software lives for decades is just different than for a startup which rewrite the whole stack every six months. Creativity and cleverness is a double-edged sword, which is exactly what Dijkstra is talking about.
- nmfisher 5y ago
  Compare writing Java professionally with writing Kotlin professionally. It's like night and day. Same projects, same VM, all that's different is the language. Distaste for Java isn't elitism or arrogance, it's just that the language is so damn painful to write. If you start your career with Java (as I did), dipping your toe into another[0] language for the first time feels like Neo being ejected from the matrix and waking up to reality. You realize your eyes are finally open, you're awake, and you can see that all that pain was just what Java saddles you with, and wasn't "the way programming is done (TM)". [0] depends on which language, of course. Java to C# isn't a big jump.
  - ajuc 5y ago
    Could you write your top 3 Java pain points? I started working in C++, moved to Java, used several other languages commercially (Python, JS, PHP, Groovy, Kotlin), and about dozen other languages for personal projects including the hip ones like Clojure, Prolog, Ruby. My first programming languages were C64 BASIC and Turbo Pascal. I've written some Ada and SML. And I just don't understand the Java hate.
    - ArnoVW 5y ago
      Haven't upgraded Java since version 9, so take this with a cube of salt (my suspicion is that many hardcore Java haters were created by Java 5, 6 etc).. but my general issue is the readability. The idioms used to perform 'standard' things are verbose. The worst for me is that it's impossible to catch exceptions in lambdas. The absence of named or optional parameters. Mind you, I'm only saying that after having spent 2 years in Kotlin. The Stockholm syndrom is real: you don't realize how much better things can be from the inside. Programming has become enjoyable again, my work 'feels' cleaner, more readable. Null safety makes reasoning about code that much easier. I can switch to functional programming when it's convenient. I keep all the tooling from Java, including the amazing IntelliJ IDE. At the end of the day, choices are a matter of arbitration. Do I want the speed of C, the ecosystem and resource pool of Java, the locality / mathematical guarantees of functional languages, and the IntelliJ IDE? Sure. But they don't exist in one language. So when I'm programming embedded, it's C. When I'm creating a complex data treatment pipeline for machine learning, it's Scala. And when I'm making a CRUD application that will have to support a team of 15 developers hacking on it for a decade, I'll go with Kotlin.
the_arun 5y ago
Problem is not with programming languages. It is with lack of programming principles. For eg. Consistency, Readability, Maintainability. Software requirements keep changing with time & so if we do not do continuous refactoring, we see a decay. Also in enterprises team ownership keeps changing & we miss the accountability. This erodes software. People need to give a damn to maintain software.
rendaw 5y ago
I know this is just flamebait, but I write a lot of Rust, Python, Java, C++, Ruby, Typescript, etc. Java is fantastic to write in. What guardrails are you talking about?
- oblio 5y ago
  My guess? Lack of first class functions and macros. Maybe higher kinded types. The first one is annoying, not really something a professional software developer would care about for more than 10 minutes while creating a new product. Macros can be major footguns, they're something that can only be realistically used efficiently and safely in large code bases by actual senior engineers. So the jury's still out how much they really increase productivity for the averaged developer. Higher kinded types seem great, but it seems that they're not easy to implement and they also slow compilation down a bunch (someone please correct me on this). These seems hard to bolt on to an existing language, so Java can't be faulted much.
  - smitty1e 5y ago
    Java itself may lack macros, but by the time you get in reflection and libraries with XML and compile-time magic to work around the lack of macros and the whole thing is a giant plate of spaghetti, maybe macros were no' so bad after all.
  - rendaw 5y ago
    Those would've been my guesses too, but Java's had first class functions in the form of anonymous classes since 1.1, and as the other commenter mentioned reflection takes care of a lot of macro use cases.
ajuc 5y ago
That's like a mason or an engineer complaining that the bricks are too boring and predictable :) There's a place for "artistic licence languages" like Ruby or Clojure and I like them for experimenting, but when you want to build a house you want the bricks to be boring.
0xbadcafebee 5y ago
> It was literally built with guardrails to keep enterprise coders from getting too creative You say that like it's a bad thing...

Java is miserable to write. You don’t realize this until you work with other languages. It was literally built with guardrails to keep enterprise coders from getting too creative

podunkPDX 5y ago

I can’t speak to the actual act of Java development, but I can speak to Java applications from a sysadmin perspective (15 yr Sr. QA Engineer to a 3 yr Linux admin (don’t ask)) — I’ve got no real beef with Java from the development side, but maintaining some of those stacks in production is pure pain.

lmm 5y ago
Huh? Java is probably the least demanding stack from the sysadmin side - no big chains of library dependencies, no docker, strong backwards compatibility that means you can fearlessly upgrade the language. All you have to do is keep an up-to-date JVM installed on your servers and deploy single-file fat JARs to them.
- lovasoa 5y ago
  Until you get an out of memory error. Then you need to start fiddling with the JVM. Or until you realize that you have a 99th percentile latency of multiple seconds...
  - lmm 5y ago
    No language is immune to slow or memory-hungry code. The JVM is probably the easiest runtime to monitor/instrument/profile (and it's not like having no runtime makes that any easier, quite the opposite), and has probably the most tuneable GC going. I guess enabling your users to do that might be work for a sysadmin, but that's more a reflection of those users having higher expectations for Java than for other runtimes - providing your users with the same capability in other stacks is never easier than Java, and often significantly harder.
  - oblio 5y ago
    There are only a bunch of out of memory errors, though. And they're easy to fix.
- smitty1e 5y ago
  Then you get into managing a collection of Java projects where each on ships its own JVM and keystore to obviate version issues. And then you have to deploy certificates against all that. I'm not bitter.
  - twic 5y ago
    The keystore situation is indeed poor. For several years now, it has been possible to do more key management in-app, so you don't need to manage keystores (i have written programs which pull standard PEM-encoded keys from environment variables). But the practice of using a JKS keystore is so ingrained that it's very rare to make use of that.

crm 5y ago

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 5y ago
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 5y ago
  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 5y ago
  > 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 5y ago
    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 5y ago
      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.

livesinhel 5y ago

> It was literally built with guardrails to keep enterprise coders from getting too creative Just as Go.

saagarjha 5y ago
Go somehow takes the worst bits of Java in this regard and makes them even worse :(

goto11 5y ago

Yes lets rewrite everything Ruby on Rails and CoffeScript, it is just so much more productive and creative! At least this was the opinion on HN a few years ago. Now of course other tools and languages are fashionable. And nothing against Ruby or CoffeScript per se, but the demands of an enterprise where software lives for decades is just different than for a startup which rewrite the whole stack every six months. Creativity and cleverness is a double-edged sword, which is exactly what Dijkstra is talking about.

nmfisher 5y ago
Compare writing Java professionally with writing Kotlin professionally. It's like night and day. Same projects, same VM, all that's different is the language. Distaste for Java isn't elitism or arrogance, it's just that the language is so damn painful to write. If you start your career with Java (as I did), dipping your toe into another[0] language for the first time feels like Neo being ejected from the matrix and waking up to reality. You realize your eyes are finally open, you're awake, and you can see that all that pain was just what Java saddles you with, and wasn't "the way programming is done (TM)". [0] depends on which language, of course. Java to C# isn't a big jump.
- ajuc 5y ago
  Could you write your top 3 Java pain points? I started working in C++, moved to Java, used several other languages commercially (Python, JS, PHP, Groovy, Kotlin), and about dozen other languages for personal projects including the hip ones like Clojure, Prolog, Ruby. My first programming languages were C64 BASIC and Turbo Pascal. I've written some Ada and SML. And I just don't understand the Java hate.
  - ArnoVW 5y ago
    Haven't upgraded Java since version 9, so take this with a cube of salt (my suspicion is that many hardcore Java haters were created by Java 5, 6 etc).. but my general issue is the readability. The idioms used to perform 'standard' things are verbose. The worst for me is that it's impossible to catch exceptions in lambdas. The absence of named or optional parameters. Mind you, I'm only saying that after having spent 2 years in Kotlin. The Stockholm syndrom is real: you don't realize how much better things can be from the inside. Programming has become enjoyable again, my work 'feels' cleaner, more readable. Null safety makes reasoning about code that much easier. I can switch to functional programming when it's convenient. I keep all the tooling from Java, including the amazing IntelliJ IDE. At the end of the day, choices are a matter of arbitration. Do I want the speed of C, the ecosystem and resource pool of Java, the locality / mathematical guarantees of functional languages, and the IntelliJ IDE? Sure. But they don't exist in one language. So when I'm programming embedded, it's C. When I'm creating a complex data treatment pipeline for machine learning, it's Scala. And when I'm making a CRUD application that will have to support a team of 15 developers hacking on it for a decade, I'll go with Kotlin.

the_arun 5y ago

Problem is not with programming languages. It is with lack of programming principles. For eg. Consistency, Readability, Maintainability. Software requirements keep changing with time & so if we do not do continuous refactoring, we see a decay. Also in enterprises team ownership keeps changing & we miss the accountability. This erodes software. People need to give a damn to maintain software.

rendaw 5y ago

I know this is just flamebait, but I write a lot of Rust, Python, Java, C++, Ruby, Typescript, etc. Java is fantastic to write in. What guardrails are you talking about?

oblio 5y ago
My guess? Lack of first class functions and macros. Maybe higher kinded types. The first one is annoying, not really something a professional software developer would care about for more than 10 minutes while creating a new product. Macros can be major footguns, they're something that can only be realistically used efficiently and safely in large code bases by actual senior engineers. So the jury's still out how much they really increase productivity for the averaged developer. Higher kinded types seem great, but it seems that they're not easy to implement and they also slow compilation down a bunch (someone please correct me on this). These seems hard to bolt on to an existing language, so Java can't be faulted much.
- smitty1e 5y ago
  Java itself may lack macros, but by the time you get in reflection and libraries with XML and compile-time magic to work around the lack of macros and the whole thing is a giant plate of spaghetti, maybe macros were no' so bad after all.
- rendaw 5y ago
  Those would've been my guesses too, but Java's had first class functions in the form of anonymous classes since 1.1, and as the other commenter mentioned reflection takes care of a lot of macro use cases.

ajuc 5y ago

That's like a mason or an engineer complaining that the bricks are too boring and predictable :) There's a place for "artistic licence languages" like Ruby or Clojure and I like them for experimenting, but when you want to build a house you want the bricks to be boring.

0xbadcafebee 5y ago

> It was literally built with guardrails to keep enterprise coders from getting too creative You say that like it's a bad thing...