7 ms·

I would love to have some Java programmer opinion on this piece.

by yenda 11y ago

daxfohl 11y ago
I'll bite, downvotes notwithstanding :) One advantage of the Java is that the interfaces are named, type-checked documentation. Yes it's more verbose, but a maintainer of that code can understand exactly the intention just from the interface names, without having to decipher it line-by-line. For the Clojure code, after you've added enough comments to explain what you're doing, so that the code can be reasonably maintained, then it's the same size as the Java code, but without the type safety. Granted for some of the simpler patterns like strategy, Java's verbosity just gets in the way, though much of that has been simplified in Java 8. FWIW I prefer Scala over both in all cases. But if Scala didn't exist, I'd prefer Java for the enterprise use case, and Clojure for the small applet use case.
- bpicolo 11y ago
  > it just doesn't work at an enterprise level Elaborate?
  - yenda 11y ago
    Judging by his comment I have the feeling that entreprise level means huge projects with thousands of lines of bloat code and comments which need vast amount of underpaid programmers to analyse and debug just to add minor features.
    - grayclhn 11y ago
      Why do you assume they're underpaid? :)
  - daxfohl 11y ago
    Big, not-very-interesting CRUD app. Every time the data model changes, you've got to go through manually and find all the places the code needs changed, and hope you didn't miss anything. It probably didn't help that it was running on MongoDB, so two levels of dynamic typing and impossible to remember what went where, and a DB that takes whatever you give without complaining. So no compile errors and often no runtime errors either, just incorrect behavior. Switched to Scala and SQL, and code is almost as compact but typed relations are far easier to reason about; if a relation changes then you change the core type and follow the compile errors. Once it compiles, it usually works. We've not missed Clojure in the least. Scala (and even Java) simply feels more structured, with relations between types, the resulting app more "designed", which seems necessary at the enterprise level. In my 2 years, Clojure constantly felt like just hacking. Would love to see some examples of Clojure being used well at an enterprise level so I could understand better how to do so, but CircleCI's recent flopping between core.typed and prismatic just makes me think it's a square peg in a round hole.
    - RussianCow 11y ago
      > Every time the data model changes, you've got to go through manually and find all the places the code needs changed, and hope you didn't miss anything. Isn't that what tests are for?
      - daxfohl 11y ago
        No, that's what types are for. Types are exactly for this. They're far less verbose than tests, they prevent compilation completely on error, they're integrated with your code, they're 100% comprehensive, and they don't contain bugs. Contrarily, tests don't work at all for model changes because the test still retains the old model anyway.
        catnaroek 11y ago
        I agree with your sentiment - why bother testing something that we can get the compiler to prove, once and for all? However, in Java, a typeful model of a program's specification is bound to be: (0) Imprecise, because of the holes in Java's static safety. You can establish a convention that statically unsafe features are verboten, but it will remain just that - a convention. (1) Verbose, because Java can't express even the simplest ideas without using at least 5 classes: Finite case analysis? Visitors. Higher-order functions? Strategies. Persistent data structures? Memento. Things don't get better if we move to a higher architectural level: Embedded DSLs? You need a separate class for each production rule in your abstract syntax. Type-safe database queries? Java has no structurally typed records, so you need to make a custom POJO class for every query that returns different columns. These things are incredibly unpleasant to deal with, and while it might be true that "unpleasant work builds character", I don't think it should come as a surprise that some people say "enough is enough", and seek alternatives that minimize or at least reduce their pain (like dynamically checked conformance to a schema), even at the cost of sacrificing some type safety (dynamic checks can't enforce higher-order invariants).
        paulddraper 11y ago
        I agree with you that Java is painful. But if "enough is enough", abandoning all types is throwing out the baby with bathwater. You make a compelling argument for languages with type inference and richer typing systems. There are many such languages. For the JVM, there is Scala.
- erichmond 11y ago
  I worked in java for 6 years before moving to clojure. Your experiences don't remotely reflect mine, I can't think of a single reason I'd ever choose java over clojure anymore (as tooling matures) but I appreciate you taking the time to comment!
  - d_t_w 11y ago
    Worked with Java from '97, Clojure for the last two years, agree with you completely.
- js8 11y ago
  > For the Clojure code, after you've added enough comments to explain what you're doing, so that the code can be reasonably maintained, then it's the same size as the Java code, but without the type safety. Funny, I feel the same about design patterns. So you bothered to find an abstraction in the code, you described it, gave it a name, and yet - you didn't tell the computer - here I am using this abstraction! And you rely on other humans to correctly infer what abstraction you used from reading your code, instead of just telling them. So what should really be done, design patterns, once identified, should be replaced with proper abstractions in the programming language (mostly functions?) and die. Frankly, most of them are just really fancy names for trivial things.
  - daxfohl 11y ago
    Totally agree. A fair amount of that is done in C#, with proper events, observables, enumerables, and functional constructs. Really when I say Java previously I mean C#; I haven't worked in Java proper in over a decade, so it's entirely possible I forget how bad it was.

I would love to have some Java programmer opinion on this piece.

by yenda 11y ago

I would love to have some Java programmer opinion on this piece.

I'll bite, downvotes notwithstanding :) One advantage of the Java is that the interfaces are named, type-checked documentation. Yes it's more verbose, but a maintainer of that code can understand exactly the intention just from the interface names, without having to decipher it line-by-line. For the Clojure code, after you've added enough comments to explain what you're doing, so that the code can be reasonably maintained, then it's the same size as the Java code, but without the type safety. Granted for some of the simpler patterns like strategy, Java's verbosity just gets in the way, though much of that has been simplified in Java 8. FWIW I prefer Scala over both in all cases. But if Scala didn't exist, I'd prefer Java for the enterprise use case, and Clojure for the small applet use case.

bpicolo 11y ago
> it just doesn't work at an enterprise level Elaborate?
- yenda 11y ago
  Judging by his comment I have the feeling that entreprise level means huge projects with thousands of lines of bloat code and comments which need vast amount of underpaid programmers to analyse and debug just to add minor features.
  - grayclhn 11y ago
    Why do you assume they're underpaid? :)
- daxfohl 11y ago
  Big, not-very-interesting CRUD app. Every time the data model changes, you've got to go through manually and find all the places the code needs changed, and hope you didn't miss anything. It probably didn't help that it was running on MongoDB, so two levels of dynamic typing and impossible to remember what went where, and a DB that takes whatever you give without complaining. So no compile errors and often no runtime errors either, just incorrect behavior. Switched to Scala and SQL, and code is almost as compact but typed relations are far easier to reason about; if a relation changes then you change the core type and follow the compile errors. Once it compiles, it usually works. We've not missed Clojure in the least. Scala (and even Java) simply feels more structured, with relations between types, the resulting app more "designed", which seems necessary at the enterprise level. In my 2 years, Clojure constantly felt like just hacking. Would love to see some examples of Clojure being used well at an enterprise level so I could understand better how to do so, but CircleCI's recent flopping between core.typed and prismatic just makes me think it's a square peg in a round hole.
  - RussianCow 11y ago
    > Every time the data model changes, you've got to go through manually and find all the places the code needs changed, and hope you didn't miss anything. Isn't that what tests are for?
    - daxfohl 11y ago
      No, that's what types are for. Types are exactly for this. They're far less verbose than tests, they prevent compilation completely on error, they're integrated with your code, they're 100% comprehensive, and they don't contain bugs. Contrarily, tests don't work at all for model changes because the test still retains the old model anyway.
      - catnaroek 11y ago
        I agree with your sentiment - why bother testing something that we can get the compiler to prove, once and for all? However, in Java, a typeful model of a program's specification is bound to be: (0) Imprecise, because of the holes in Java's static safety. You can establish a convention that statically unsafe features are verboten, but it will remain just that - a convention. (1) Verbose, because Java can't express even the simplest ideas without using at least 5 classes: Finite case analysis? Visitors. Higher-order functions? Strategies. Persistent data structures? Memento. Things don't get better if we move to a higher architectural level: Embedded DSLs? You need a separate class for each production rule in your abstract syntax. Type-safe database queries? Java has no structurally typed records, so you need to make a custom POJO class for every query that returns different columns. These things are incredibly unpleasant to deal with, and while it might be true that "unpleasant work builds character", I don't think it should come as a surprise that some people say "enough is enough", and seek alternatives that minimize or at least reduce their pain (like dynamically checked conformance to a schema), even at the cost of sacrificing some type safety (dynamic checks can't enforce higher-order invariants).
        paulddraper 11y ago
        I agree with you that Java is painful. But if "enough is enough", abandoning all types is throwing out the baby with bathwater. You make a compelling argument for languages with type inference and richer typing systems. There are many such languages. For the JVM, there is Scala.
erichmond 11y ago
I worked in java for 6 years before moving to clojure. Your experiences don't remotely reflect mine, I can't think of a single reason I'd ever choose java over clojure anymore (as tooling matures) but I appreciate you taking the time to comment!
- d_t_w 11y ago
  Worked with Java from '97, Clojure for the last two years, agree with you completely.
js8 11y ago
> For the Clojure code, after you've added enough comments to explain what you're doing, so that the code can be reasonably maintained, then it's the same size as the Java code, but without the type safety. Funny, I feel the same about design patterns. So you bothered to find an abstraction in the code, you described it, gave it a name, and yet - you didn't tell the computer - here I am using this abstraction! And you rely on other humans to correctly infer what abstraction you used from reading your code, instead of just telling them. So what should really be done, design patterns, once identified, should be replaced with proper abstractions in the programming language (mostly functions?) and die. Frankly, most of them are just really fancy names for trivial things.
- daxfohl 11y ago
  Totally agree. A fair amount of that is done in C#, with proper events, observables, enumerables, and functional constructs. Really when I say Java previously I mean C#; I haven't worked in Java proper in over a decade, so it's entirely possible I forget how bad it was.