3 ms·

> Progressively slower development seems like a pretty massive risk these days, where not being able to chase a competitor's big feature can be the death knell

> Progressively slower development seems like a pretty massive risk these days, where not being able to chase a competitor's big feature can be the death knell to your company. You are conflating to different layers. Not being able chase a competitor's big feature can be the death knell to your company, yes. But this does not mean that building your business software on stable and proven foundations is a high risk. On the contrary you want to be fast moving with your business features not with keeping up with quicksand under your feet. I.e. a stable well understood basis, is IMHO a prerequisite to moving fast above of it. In addition to my arguments above, one still has to consider whether a tool matches the problem. Writing an Excel plugin in Java is probably a very bad idea (I really don't know, I just assume that anything based on .NET would be a better fit), although both Excel and Java value long term compatibility. If you want to follow the latest trends in AI without really understanding what is going on, it is probably best to follow all the tutorial about AI and use Python. But if you plan to hire people that understand the details of AI libraries, you might come to the conclusion that the AI libraries on the JVM also provide the basic blocks you need, the higher levels are customized to your application anyways. To come back to the original point, a technology or programming language is not good if it moves fast, it is good when it fits your problem, doesn't create too many new problems, is well understood by you and your team and is maintained.

BlargMcLarg 5y ago
You're the one conflating my argument here. What I'm pointing out is this: there's somewhat of an assumption that java moves slow yet steady, therefore not generating the code mess other languages get blamed for, ending in either an undecipherable mess, or degradation of development quality and speed. The idea being that java makes one more likely to win the marathon in favor of losing the sprint. Whereas many other languages can only win the initial sprint, become messy, and then proceed to be unable to move with competitors anyway later down the line. In practice, I've barely ever seen this assumption truly come to fruition. I see java codebases degrade, become undecipherable messes filled with reflection, inflate themselves to become incredibly hard to understand or work with, at similar rates. I still see JSPs throwing garbled stacktraces that barely help understand what's wrong. Still see business shoot itself in the foot because it said "this should never happen", so the code is made under the assumption it doesn't happen, because null is still available and no one uses optionals, and 2 months later you have clients show you another NPE after going through 15 layers of business-modifying logic and people spend a week uncovering how the situation can take place (or worse, it is retroactively sealed up and the actual bug is still there). If there's some magic spell that helps java become less messy than other static languages or even some dynamic languages, I have yet to see it. At that point, one has to question: what are we losing the sprint for? Are we truly increasing the odds of us winning the marathon? Not even its most espoused benefits, libraries, write once work everywhere, etc., seem to be remotely unique anymore. The only two answers I see, are legacy, and the number of java devs available. Lose a java dev, no problem, just pop in another. Want to rewrite the app in a different language, or even in less verbose, modern java? Good luck convincing management firmly believing that a rewrite of one month is more costly than pushing out features at 1/10th the speed post-refactor for another 2 years.
- JAlexoid 5y ago
  And yet... That is what I got from a less than 2y/o Python application. Java isn't the problem. People lacking a broader view are.

BlargMcLarg 5y ago

You're the one conflating my argument here. What I'm pointing out is this: there's somewhat of an assumption that java moves slow yet steady, therefore not generating the code mess other languages get blamed for, ending in either an undecipherable mess, or degradation of development quality and speed. The idea being that java makes one more likely to win the marathon in favor of losing the sprint. Whereas many other languages can only win the initial sprint, become messy, and then proceed to be unable to move with competitors anyway later down the line. In practice, I've barely ever seen this assumption truly come to fruition. I see java codebases degrade, become undecipherable messes filled with reflection, inflate themselves to become incredibly hard to understand or work with, at similar rates. I still see JSPs throwing garbled stacktraces that barely help understand what's wrong. Still see business shoot itself in the foot because it said "this should never happen", so the code is made under the assumption it doesn't happen, because null is still available and no one uses optionals, and 2 months later you have clients show you another NPE after going through 15 layers of business-modifying logic and people spend a week uncovering how the situation can take place (or worse, it is retroactively sealed up and the actual bug is still there). If there's some magic spell that helps java become less messy than other static languages or even some dynamic languages, I have yet to see it. At that point, one has to question: what are we losing the sprint for? Are we truly increasing the odds of us winning the marathon? Not even its most espoused benefits, libraries, write once work everywhere, etc., seem to be remotely unique anymore. The only two answers I see, are legacy, and the number of java devs available. Lose a java dev, no problem, just pop in another. Want to rewrite the app in a different language, or even in less verbose, modern java? Good luck convincing management firmly believing that a rewrite of one month is more costly than pushing out features at 1/10th the speed post-refactor for another 2 years.

JAlexoid 5y ago
And yet... That is what I got from a less than 2y/o Python application. Java isn't the problem. People lacking a broader view are.