3 ms·

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 nec

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.

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.