4 ms·

> Java is an extremely poor example of a helpful type system. With generics added 15 years ago, lambdas with argument type inference 6 years ago, local variabl

• romanoderoma 6y ago
  > , Java is practically becoming an ML For new code, yes. For old code, it's more in the realm of COBOL Also given that is one of the few languages that can speak fluently with technologies that are not very well known anymore, but still rocking many boats like SOAP webservices or AS400 mainframes The bulk of the Java applications are inside banks and insurance companies > are code organisation and tooling support (refactoring, code completion). Agree. Even though code completion has never been a problem for me in the past 20 years, not even with bash lately
  • pron 6y ago
    > it's more in the realm of COBOL If you're talking about programming style, I don't see the resemblance (have you seen COBOL code?), and if you're talking about usage, then Java is much more popular and used in many more domains than COBOL ever was. If you must compare it to anything, then the C of large server-side software would be a more apt comparison, I think. > The bulk of the Java applications are inside banks and insurance companies And Apple and Google and Netflix and Amazon and Alibaba and governments and militaries and telcos and cedit card companies and airports and power plants and factories; wherever you'd find big, mission critical server apps, really.
    • romanoderoma 6y ago
      > have you seen COBOL code? A lot of it Always stayed away from it > Java is much more popular and used in many more domains than COBOL ever was It was merely a comparison on the number of line codes deployed that never changed over decades and nobody wants to touch anymore because they drive critical systems, that move a lot of money The same reason why much of the COBOL in existence is still around I wasn't comparing the capabilities or the qualities of the two > And Apple and Google and Netflix and Amazon and Alibaba and governments and militaries and telcos and cedit card companies and airports and power plants and factories They rely on COBOL code too... Believe me
      • pron 6y ago
        Then C is definitely a better comparison. Code like that exists in huge quantities in any popular language used to write long-lived software for more than a couple of decades, but COBOL wasn't really such a language, like C and Java are. It was used a lot in some rather narrow domains and then it faded. It became popular in the late sixties, and by the mid eighties it was already falling out of fashion and became very niche. It barely had twenty years of dominance. If you insist, then a more modern language with a trajectory similar to COBOL would probably be VB. > They rely on COBOL code too... And quite possibly VB, too. But those companies write much of their new software in Java. They don't do it in COBOL (or in VB).
        • romanoderoma 6y ago
          C is not legacy. The same code from 20 or 30 years ago compiles today with little or no modifications Try to run a servlet from 1998 or a struts web app from 2001 with a recent JVM And yet you still find them in a lot of places, that you don't see, because you don't work with them, but that probably manage some of the transactions you make They are legacy because they are being maintained for clientst hat have been using them for at least 2 decades and are virtually untouchable, but are still being updated, slowly, to keep them running I'm not insisting, it's what it is. VB is not legacy, VB is dead No large company ever relied on VB to keep going __ever__ COBOL is still being developed, because it's still used To the point that COBOL can interface to Java or C# because companies prefer to update thei COBOL programs to call outside than rewrite them The final approved ISO (of Object oriented COBOL) standard was approved and published in late 2002.
• creata 6y ago
  > With generics added 15 years ago, In my experience, Java's generics were horribly confusing and not quite type-safe, in contrast to the dead-simple polymorphism in Haskell. But feel free to correct me here. > ADTs and pattern-matching gradually rolling out already What a language gives you is less important that what it makes easy, and I cannot imagine a more cumbersome syntax for ADTs than the one in the linked proposal.
  • pron 6y ago
    > In my experience, Java's generics were horribly confusing and not quite type-safe, in contrast to the dead-simple polymorphism in Haskell. But feel free to correct me here. Oh, they're typesafe (except for a bug in the implementation found a couple of years ago) but I agree they're more confusing than in languages without subtyping. I'd still pick Java over Haskell any day (but I'd take Haskell over Scala). Pick your poison, I guess. > What a language gives you is less important that what it makes easy, and I cannot imagine a more cumbersome syntax for ADTs than the one in the linked proposal. Nah, the syntax is fine. Somewhat more verbose than ML's or Haskell's, but it fits well with the rest of the language. So instead of Haskell's, data Expr = ConstantExpr Int | PlusExpr Expr Expr | TimesExpr Expr Expr | NegExpr Expr deriving (Show, Eq); You write, sealed interface Expr {} record ConstantExpr(int i) implements Expr {} record PlusExpr(Expr a, Expr b) implements Expr {} record TimesExpr(Expr a, Expr b) implements Expr {} record NegExpr(Expr e) implements Expr {} Not quite as succinct, but it's not really any more tedious (and you get component names, too).
    • creata 6y ago
      Yeah, I guess I overreacted to the verbosity — it's definitely a huge improvement over the current state of Java. But is there a reason not to add NonNull annotations to the fields of type Expr?
      • zaltekk 6y ago
        It’s much more common nowadays to have SpotBugs/Checkstyle treat everything as non-null by default. Then you use Optional where necessary (or maybe @Nullable).