4 ms·
If you don't understand, please don't make assumptions. Java itself is fine. The progress Java is making, is also fine. I'm sure you could give Java, Python, R
by BlargMcLarg 7y ago
If you don't understand, please don't make assumptions.
Java itself is fine. The progress Java is making, is also fine. I'm sure you could give Java, Python, Ruby, C#, Javascript to a group of newbie programmers each, and satisfaction would be similar.
The problem comes from a mental perspective combined with the problems of enterprise. If I use Java at home, I'll learn all these cool features that I have to push through 3, maybe 4 layers of management before I can use it at work. It'd just agitate me not being able to do it in the language I'm using at that point. I had the same issue with Unity, where I couldn't use half the features of modern C# because Unity Engine was still on C# 2.0 or something, but at least there I personally opted to use Unity. Besides that, I'm just not a fan of Java on a personal level.
>I have never seen a correlation between obsessing about code concepts and success. Those who tend to be more successful care about requirements, design, algorithm, and observability more than about lambdas or verbs vs. nouns. It is difficult to understate the importance of those things compared to most other software concerns.
These aren't mutual exclusive and frankly, dragging this into the discussion is a bit of a low blow. Yes, ultimately, what matters is the product and its future maintainability. What isn't trivial is deciding whether to introduce a system where a bug may be hidden in 3 layers of reflection, 5 layers of abstraction and requires you to read hundreds of lines only to understand what is going on, much less why, because everything is written 2-3 times (in code, in comments and sometimes even something else). Spending hours because Bob's great plan was to introduce another if-else statement, now nested 3-deep, inside a try-catch block, and you have no clue where the value was assigned anymore.
That same thing happened at the place I work at now. They focused on immediate results more than long term code maintenance. They got amazing success. Now they have a massive technical debt, and people have trouble understanding what the code was supposed to do. No fancy tricks, no interesting algorithms or one-liners. Just old, verbose, imperative / OO Java code to power forms. The simplest of data manipulation. In the end, these things still end up at the skilled seniors anyway, because the juniors don't understand, the mediors don't have the required domain knowledge and everyone else doesn't have the skill to comprehend what is going on.
And frankly, I have managers and deadlines to keep me from spending too much time. So far, those guys haven't complained, despite thinking about ways that the codebase could be improved.
- pron 7y agoBut the problems you run into would occur with any language that manages to accomplish what Java has. The fact that in addition to being used in those domains Java is also successfully used in very different ones (robotics and industrial control, formal methods, simulation and many others) -- something that was never true for, say, COBOL, which has always been a "business only" language -- only speaks to its strengths. You don't see as much technical debt in languages that haven't successfully scaled to large codebases, large teams and long lifetimes. We can't say for sure whether, say, Ruby, JS, Go, Clojure, or Haskell intrinsically scale worse, but we sure can't say they scale better. Could there be a better way to do those things than Java? Sure, but we haven't found one yet (or, at least, haven't demonstrated that we have).