12 ms·

Yeah. Java is pretty boring but I wouldn’t recommend for the majority of cases.

the_af 6y ago
Why not? Java is used to great success in the software industry. It's a good language and platform, fads to the contrary notwithstanding.
- pdimitar 6y ago
  When you are actually coding Java -- yes. But as a sibling commenter pointed out, there's a lot of "XML as code" in the Java world. That's really hard to work with.
  - the_af 6y ago
    I haven't dealt with "a lot of XML" in Java for ages. I've been using it in my day job for a decade, and about the only XML I touch is pom.xml (that's the build file for Maven). This is like complaining about stuff in Java 1.4 -- sure, but we haven't been using it for ages. Please don't take it the wrong way, but the days of XML for everything are long gone, and for years in Java it's been XML for nothing as a counter reaction.
    - pdimitar 6y ago
      Your experience doesn't nullify mine, and vice versa. There's a huge pile of legacy Java applications out there still needing maintenance and occasional new features.
      - deleted 6y ago
        [deleted]
      - the_af 6y ago
        You cannot judge a language and platform merely by legacy software. By that token, almost everything today is horribly broken, even trendier technologies like NodeJS or Go. You'd have to judge C by K&R standards, and C++ as the horrible preprocessor it initially was. It makes no sense! You must judge Java by the developments of the last decade at the very least. Otherwise you're ignoring the practitioners. Java hasn't used XML in ages and you cannot fault it for legacy apps. You could similarly complain about the horror of EJBs -- sure, but the industry has moved on and acknowledged they were a mistake.
        ByteJockey 6y ago
        > You must judge Java by the developments of the last decade at the very least. Otherwise you're ignoring the practitioners. I think plurality of situations it's actually used for currently would be a better standard than what you're advocating for. This has the advantage that the merits people judge things on, and the experience they will most likely have using it will line up. The downside is that, the merits used may differ a bit between markets or industries, but I'm personally ok with that.
        the_af 6y ago
        The problem with judging a language by how it was a decade ago is that you're going to be left claiming absurd, outdated things. Imagine if I claimed I didn't like Java because it lacks generics, or because it lacks lambdas, or because I really, really dislike working with EJBs, or because working with Java means "working with a lot of XML" (this would flunk you in an interview, by the way). Imagine if I complained about Linux and all I used as an argument was the Unix Haters Handbook. Imagine if I complained about Windows and the most recent version I had used was Windows 95.
        ByteJockey 6y ago
        That depends on what you want from the judgement doesn't it? If you want to be able to know the theoretical things you could do with the language, I think your definition is right. If you want to know the most likely experience you would have using the language, I think mine is right. I think it also depends on what circumstances you're using the language. Spinning up a new project probably lends itself more towards your definition. If you're looking to join an existing project, mine is probably more useful.
        pdimitar 6y ago
        I am judging a technology by its amount of foot guns. That's why I am more fan of languages with only one way of doing things (and even that gets increasingly rare). Java is a pretty solid tech and the JVM is one of the best runtimes in the world. But it does offer you infinite possibilities to write awful code and that made me less interested in it with time.
      - randombytes6869 6y ago
        That doesn't make Java a bad choice for building new things
        pdimitar 6y ago
        Agreed, it doesn't at all. I am saying that when I was contracting with Java some years ago it was a complete crapshoot: you could get an almost brand new project with a lot of thought put in that made it a pleasure to work on, or you could get an ancient EJB mastodon that made you want to slit your wrists. And that gamble still exists if you want to contract with Java. A lot of preliminary negotiations have to be done in order not to find yourself in a situation where you should have charged $30k a month due to the insane amount of digging you have to do just to make the thing accept one new feature.
        the_af 6y ago
        That gamble exists in one way or the other with any tech platform. I double dare you to take on a codebase written with NodeJS, Golang or Python without checking its sanity first. This isn't exclusive to Java.
  - HelloNurse 6y ago
    XML as code can (and often does) work as intended. It's much less annoying than "exciting" episodes and habits: - let's see if our SSL certificate has been actually updated on all servers in the cluster - let's find out what I need to restart after deploying my web app update - who knows what the classpath loading order will be this time; if it's broken you can try a restart - finish the test quickly before the sysadmin committee begins an application server upgrade and everything goes offline for as long as it takes, hopefully only a few hours
    - pdimitar 6y ago
      Not sure how what you said fixes the points you enumerated? XML as code simply wraps other people's libraries in a different DSL and if they have bugs and/or operational complexity, no DSL on top of it will change that.
  - randombytes6869 6y ago
    I haven't used XML in our Java apps in many years. Most of them don't contain a single XML file, unless they use Maven, then they have one.
wpietri 6y ago
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.
- mlthoughts2018 6y ago
  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.
  - the_af 6y ago
    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.
    - 6y ago

Why not? Java is used to great success in the software industry. It's a good language and platform, fads to the contrary notwithstanding.

pdimitar 6y ago
When you are actually coding Java -- yes. But as a sibling commenter pointed out, there's a lot of "XML as code" in the Java world. That's really hard to work with.
- the_af 6y ago
  I haven't dealt with "a lot of XML" in Java for ages. I've been using it in my day job for a decade, and about the only XML I touch is pom.xml (that's the build file for Maven). This is like complaining about stuff in Java 1.4 -- sure, but we haven't been using it for ages. Please don't take it the wrong way, but the days of XML for everything are long gone, and for years in Java it's been XML for nothing as a counter reaction.
  - pdimitar 6y ago
    Your experience doesn't nullify mine, and vice versa. There's a huge pile of legacy Java applications out there still needing maintenance and occasional new features.
    - deleted 6y ago
      [deleted]
    - the_af 6y ago
      You cannot judge a language and platform merely by legacy software. By that token, almost everything today is horribly broken, even trendier technologies like NodeJS or Go. You'd have to judge C by K&R standards, and C++ as the horrible preprocessor it initially was. It makes no sense! You must judge Java by the developments of the last decade at the very least. Otherwise you're ignoring the practitioners. Java hasn't used XML in ages and you cannot fault it for legacy apps. You could similarly complain about the horror of EJBs -- sure, but the industry has moved on and acknowledged they were a mistake.
      - ByteJockey 6y ago
        > You must judge Java by the developments of the last decade at the very least. Otherwise you're ignoring the practitioners. I think plurality of situations it's actually used for currently would be a better standard than what you're advocating for. This has the advantage that the merits people judge things on, and the experience they will most likely have using it will line up. The downside is that, the merits used may differ a bit between markets or industries, but I'm personally ok with that.
        the_af 6y ago
        The problem with judging a language by how it was a decade ago is that you're going to be left claiming absurd, outdated things. Imagine if I claimed I didn't like Java because it lacks generics, or because it lacks lambdas, or because I really, really dislike working with EJBs, or because working with Java means "working with a lot of XML" (this would flunk you in an interview, by the way). Imagine if I complained about Linux and all I used as an argument was the Unix Haters Handbook. Imagine if I complained about Windows and the most recent version I had used was Windows 95.
        ByteJockey 6y ago
        That depends on what you want from the judgement doesn't it? If you want to be able to know the theoretical things you could do with the language, I think your definition is right. If you want to know the most likely experience you would have using the language, I think mine is right. I think it also depends on what circumstances you're using the language. Spinning up a new project probably lends itself more towards your definition. If you're looking to join an existing project, mine is probably more useful.
      - pdimitar 6y ago
        I am judging a technology by its amount of foot guns. That's why I am more fan of languages with only one way of doing things (and even that gets increasingly rare). Java is a pretty solid tech and the JVM is one of the best runtimes in the world. But it does offer you infinite possibilities to write awful code and that made me less interested in it with time.
    - randombytes6869 6y ago
      That doesn't make Java a bad choice for building new things
      - pdimitar 6y ago
        Agreed, it doesn't at all. I am saying that when I was contracting with Java some years ago it was a complete crapshoot: you could get an almost brand new project with a lot of thought put in that made it a pleasure to work on, or you could get an ancient EJB mastodon that made you want to slit your wrists. And that gamble still exists if you want to contract with Java. A lot of preliminary negotiations have to be done in order not to find yourself in a situation where you should have charged $30k a month due to the insane amount of digging you have to do just to make the thing accept one new feature.
        the_af 6y ago
        That gamble exists in one way or the other with any tech platform. I double dare you to take on a codebase written with NodeJS, Golang or Python without checking its sanity first. This isn't exclusive to Java.
- HelloNurse 6y ago
  XML as code can (and often does) work as intended. It's much less annoying than "exciting" episodes and habits: - let's see if our SSL certificate has been actually updated on all servers in the cluster - let's find out what I need to restart after deploying my web app update - who knows what the classpath loading order will be this time; if it's broken you can try a restart - finish the test quickly before the sysadmin committee begins an application server upgrade and everything goes offline for as long as it takes, hopefully only a few hours
  - pdimitar 6y ago
    Not sure how what you said fixes the points you enumerated? XML as code simply wraps other people's libraries in a different DSL and if they have bugs and/or operational complexity, no DSL on top of it will change that.
- randombytes6869 6y ago
  I haven't used XML in our Java apps in many years. Most of them don't contain a single XML file, unless they use Maven, then they have one.

wpietri 6y ago

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.

mlthoughts2018 6y ago
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.
- the_af 6y ago
  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.
  - 6y ago