4 ms·

So... awful and bloated Java code (with javadocs, why?!) compared to short counter-examples from Clojure. IMHO quite terrible way to compare the two…

ivan_gammel 8y ago
Exactly. Java code looks artificially bloated (who uses 8 spaces for tabulation anyway?!). Class CookieMap is completely unnecessary, for example - it extends the j.u.Map with couple operations, which could be easily done with Java 8 streams (looks like it's older version of language - diamond operator is not used).
- 3rdAccount 8y ago
  There could be a counterpart here that Java as a language is so complicated that people often come up with these design patterns because they THINK they are necessary.
  - dnomad 8y ago
    Except nobody actually writes Java code like this. Nobody implements the Map interface. It's just stupid code. The myth of Java bloat only serves people writing silly blog entries and others hung up on "best practices" from 15 years ago. It doesn't seem to have any practical basis.
    - emidln 8y ago
      I've implemented the Map interface maybe a half a dozen times in my career in Java and many more in Clojure (using reify and friends). It's often very convient to offer a map interface to some remote service or data store as well as situations where I needed very custom caching or a specialized algorithm. The harder the thing I'm working on, the more motivated I am to present its API as something standardized if possible. This lets my users spend their complexity budget on what feature I'm offering and not on some random API I threw together.
      - dionian 8y ago
        Generally at least in Java or similar languages it's better to compose rather than implement or extend, i.e. HashMap works fine for most cases, and you may not really need to implement java.util.Map if you're building something "special" anyway. For frameworks and library authors, I can see more of an argument for it, I just generally have never subclassed collections except in certain cases such as building an LRU map which Java doesn't have.
    - TeMPOraL 8y ago
      There are places stuck with Java 6 or 7. Java 8 is still relatively recent for the Enterprise world. Java 8 was a special version. Lambdas, stream API, diamond operator and new exception catching syntax together eliminated 50-80% of noise in Java code. The language is still verbose, but much less than pre-8. (Still, I prefer reading Clojure. The form of Java language still causes too much structural noise in the codebase.)
      - dnomad 8y ago
        > Java 8 is still relatively recent for the Enterprise world. Most actual surveys put Java 8 penetration at 70 - 80%. Dig deeper and the <20% of projects not on Java 8 aren't under active development and are purely in maintenance mode. This is what makes the entire exercise a myth. People may want to believe this stuff but again it has no practical basis.
        pjmlp 8y ago
        Yep, like Java 1.4 running on Red-Hat Linux 5 deployments, where no one is allowed to touch beyond bug fixes and security updates.
        3rdAccount 8y ago
        I thought RHEL5 security updates were over right?
        pjmlp 8y ago
        Yep, but I know of a few servers still running it.
        TeMPOraL 8y ago
        How are those surveys done? I'm not sure if the type of companies I'm thinking about are answering surveys, or otherwise participate in broader developer community. I was pretty much spearheading the use of Java 8 in one company ~2.5 years ago, but I know some teams actively developing there only upgraded a year ago, and I'm willing to bet the main customer still didn't...
    - lostcolony 8y ago
      Sure they do. Every Java code base I've seen, including stuff written in the past year, using Java 8, with a mix of senior and junior developers (i.e., both those who cut their teeth on Java < 8, and those who learned > 8) was bloated. I'm thinking of one thing I'm dealing with now; 30 classes, 1800 lines (admittedly, using wc -l, so variable declarations and getters/setters are counted, but that is still visual space I had to skim through to figure out what it was doing. Oh, and that was -after- I removed some of the more obvious cruft), all of it proper OO...or I could have gotten it done in < 200 lines of Node in 1-3 files. All it does is accept a REST call, validate a bunch of parameters, check to see if the result is cached, if not, makes a request elsewhere and cache the result. The myth of the myth of Java code only serves people defending Java academically, and those hung up on defending a language that enourages and defaults to bloat in any sort of shared coding environment. It doesn't seem to have any practical basis.
  - ivan_gammel 8y ago
    The comparison of programming languages must be done on equal levels of competence: it simply doesn't make sense to compare a code written by a junior after completing some online course with a code written by an experienced and well-educated engineer, because no conclusions can be made of that. The fact, that people come up with such code very often is the general characteristic of modern IT job market, where demand is so high, that it eliminates all possible qualification barriers. This particular code is written so not because Java is too complicated, but because the author did not know the minimum required for professional software development on this language or have written it this way on purpose.
akx 8y ago
And the Clojure cookie (de)serializer doesn't even deal with all the fields the original does?
deleted 8y ago
[deleted]
ahungry 8y ago
Ah, ill will or using Java as a punching bag was not my intent at all. I was working on this task, and the Java code I referenced was based on a popular Gist to accomplish the same task that I needed to accomplish, with many comments of users adapting (copy/paste programming) the same code for their usage. I felt an 'in the wild' solution was comparable to my novice-level Clojure solution (those more well versed in Clojure would likely write a much better implementation of what I did). This was meant to be a real world use case where I found my problem solved in Clojure turned out much better than it would have been solved in another language running my choice environment (JavaFX), instead of some arbitrary contrived examples (see Rosetta Code for tons of that).

ivan_gammel 8y ago

Exactly. Java code looks artificially bloated (who uses 8 spaces for tabulation anyway?!). Class CookieMap is completely unnecessary, for example - it extends the j.u.Map with couple operations, which could be easily done with Java 8 streams (looks like it's older version of language - diamond operator is not used).

3rdAccount 8y ago
There could be a counterpart here that Java as a language is so complicated that people often come up with these design patterns because they THINK they are necessary.
- dnomad 8y ago
  Except nobody actually writes Java code like this. Nobody implements the Map interface. It's just stupid code. The myth of Java bloat only serves people writing silly blog entries and others hung up on "best practices" from 15 years ago. It doesn't seem to have any practical basis.
  - emidln 8y ago
    I've implemented the Map interface maybe a half a dozen times in my career in Java and many more in Clojure (using reify and friends). It's often very convient to offer a map interface to some remote service or data store as well as situations where I needed very custom caching or a specialized algorithm. The harder the thing I'm working on, the more motivated I am to present its API as something standardized if possible. This lets my users spend their complexity budget on what feature I'm offering and not on some random API I threw together.
    - dionian 8y ago
      Generally at least in Java or similar languages it's better to compose rather than implement or extend, i.e. HashMap works fine for most cases, and you may not really need to implement java.util.Map if you're building something "special" anyway. For frameworks and library authors, I can see more of an argument for it, I just generally have never subclassed collections except in certain cases such as building an LRU map which Java doesn't have.
  - TeMPOraL 8y ago
    There are places stuck with Java 6 or 7. Java 8 is still relatively recent for the Enterprise world. Java 8 was a special version. Lambdas, stream API, diamond operator and new exception catching syntax together eliminated 50-80% of noise in Java code. The language is still verbose, but much less than pre-8. (Still, I prefer reading Clojure. The form of Java language still causes too much structural noise in the codebase.)
    - dnomad 8y ago
      > Java 8 is still relatively recent for the Enterprise world. Most actual surveys put Java 8 penetration at 70 - 80%. Dig deeper and the <20% of projects not on Java 8 aren't under active development and are purely in maintenance mode. This is what makes the entire exercise a myth. People may want to believe this stuff but again it has no practical basis.
      - pjmlp 8y ago
        Yep, like Java 1.4 running on Red-Hat Linux 5 deployments, where no one is allowed to touch beyond bug fixes and security updates.
        3rdAccount 8y ago
        I thought RHEL5 security updates were over right?
        pjmlp 8y ago
        Yep, but I know of a few servers still running it.
      - TeMPOraL 8y ago
        How are those surveys done? I'm not sure if the type of companies I'm thinking about are answering surveys, or otherwise participate in broader developer community. I was pretty much spearheading the use of Java 8 in one company ~2.5 years ago, but I know some teams actively developing there only upgraded a year ago, and I'm willing to bet the main customer still didn't...
  - lostcolony 8y ago
    Sure they do. Every Java code base I've seen, including stuff written in the past year, using Java 8, with a mix of senior and junior developers (i.e., both those who cut their teeth on Java < 8, and those who learned > 8) was bloated. I'm thinking of one thing I'm dealing with now; 30 classes, 1800 lines (admittedly, using wc -l, so variable declarations and getters/setters are counted, but that is still visual space I had to skim through to figure out what it was doing. Oh, and that was -after- I removed some of the more obvious cruft), all of it proper OO...or I could have gotten it done in < 200 lines of Node in 1-3 files. All it does is accept a REST call, validate a bunch of parameters, check to see if the result is cached, if not, makes a request elsewhere and cache the result. The myth of the myth of Java code only serves people defending Java academically, and those hung up on defending a language that enourages and defaults to bloat in any sort of shared coding environment. It doesn't seem to have any practical basis.
- ivan_gammel 8y ago
  The comparison of programming languages must be done on equal levels of competence: it simply doesn't make sense to compare a code written by a junior after completing some online course with a code written by an experienced and well-educated engineer, because no conclusions can be made of that. The fact, that people come up with such code very often is the general characteristic of modern IT job market, where demand is so high, that it eliminates all possible qualification barriers. This particular code is written so not because Java is too complicated, but because the author did not know the minimum required for professional software development on this language or have written it this way on purpose.

akx 8y ago

And the Clojure cookie (de)serializer doesn't even deal with all the fields the original does?

deleted 8y ago

[deleted]

ahungry 8y ago

Ah, ill will or using Java as a punching bag was not my intent at all. I was working on this task, and the Java code I referenced was based on a popular Gist to accomplish the same task that I needed to accomplish, with many comments of users adapting (copy/paste programming) the same code for their usage. I felt an 'in the wild' solution was comparable to my novice-level Clojure solution (those more well versed in Clojure would likely write a much better implementation of what I did). This was meant to be a real world use case where I found my problem solved in Clojure turned out much better than it would have been solved in another language running my choice environment (JavaFX), instead of some arbitrary contrived examples (see Rosetta Code for tons of that).