5 ms·

> You know the joke: a dev has a problem, uses Java, and now has a ProblemFactory :) I LOL’d at this joke (again) because it’s true, but if we’re honest, it’s

> You know the joke: a dev has a problem, uses Java, and now has a ProblemFactory :) I LOL’d at this joke (again) because it’s true, but if we’re honest, it’s also unfair. ProblemFactory is a bad idiom, rather than anything to do with Java The Language. You could (and IMO, probably should) just use a new Problem(). Java The Language was very stable for a very long time, so IMO the hype and fads got built on top. First we have a constructor - no, now we need a factory, but how to construct a factory? I know, let’s use another factory! All in the same unmodified language. Likewise, how do we configure an object? First we have methods, but languages are cooler, so let’s build a DSL, no wait let’s use a fluent API so it just looks like a DSL! I one had a dev replace a constructor call with a fluent builder, so now in the single use case where the object was ever created, we got five LOC where previously we had one. His code was idiomatic, it was bad engineering, but it wasn’t Java the language. Java is a pretty great language, but some of the crap people stuck on top of it was (and still is) a nightmare for readability and reusability. I use Go these days, and prefer their more basic approach to engineering, but there is much I miss from Java-the-language.

pydry 6y ago
The crap people created on top was typically responses to deficiencies in the language, whether they knew it or not. Stuff like "everything is a class".
- BiteCode_dev 6y ago
  Design design does lead community culture. Java also had the unfortunate destiny of becoming popular at the time where "OOP all the thing" was a mantra in tech circles. Also design pattern were all the rage. Those things have a huge inertia, and while Java is not a much more flexible language, the image stuck, to the point that new comers still implement singletons in the wild.
  - pydry 6y ago
    Java created that hype to market itself. OOP all the things probably wouldn't have been a thing without it, for instance. It was very much a marketed language and a language designed to be sold to top heavy corporations. This fueled a lot of the crappy design decisions, the hype and the culture.
    - dragonwriter 6y ago
      > Java created that hype to market itself. OOP all the things probably wouldn't have been a thing without it, for instance “OOP all the things” predated (and led to) Java, it wasn’t a product of Java (C++, Objective-C, Object Pascal and, well, a bunch of other things from the late 1980s and early 1990s were where it got started.) Java was about a decade into it.
      - pydry 6y ago
        There's a big difference between "OOP is cool" (which Java didn't invent) and "OOP ALL of the things".
        doctor_eval 6y ago
        But Java clearly didn’t “OOP all the things”, unlike earlier languages like Smalltalk. Java primitives are not objects (despite the fact that I often found myself wishing they were), and static methods are actually just functions. These days Java even supports first-class functions. I know not everyone will agree with me, and that’s fine, but I always found Java to be far more pragmatic than, for example, C++, which well and truely predated Java.
  - dragonwriter 6y ago
    > Java also had the unfortunate destiny of becoming popular at the time where "OOP all the thing" was a mantra in tech circles. Java was a product of “OOP all the things”, it wouldn’t have existed without it.
- doctor_eval 6y ago
  I don’t think that’s true at all. Like most languages, Java has its share of deficiencies - I’d personally put null handling, type erasure and brain dead Optionals near the top of my list of things I’d change if I was King of Java - but fluent APIs and factory methods didn’t even start with Java, and have nothing to do with “everything is a class”.
  - Pet_Ant 6y ago
    What is wrong with Optionals?
    - doctor_eval 6y ago
      Optionals can be null, so dereferencing them can still cause an NPE. Also the syntax is horrible. I know the excuse that they are just meant to be used to wrap the return value of a function that might be null, rather than as a guard against NPEs, but that just means we’ve got a crappy, verbose Optional class ... and NPEs. It was the most half assed attempt to fix the billion dollar mistake [0] anyone could have come up with. It needed syntax and compiler support, not a stupid wrapper class. [0] https://en.m.wikipedia.org/wiki/Tony_Hoare https://en.m.wikipedia.org/wiki/Tony_Hoare
      - sk5t 6y ago
        Likely to be addressed with the ongoing effort for value types. Optional + prudent use of @NotNull annotations can get you most of the way there already in practical terms.
      - Pet_Ant 6y ago
        Sorry but of course Optional can be null because of Java’s type system. Objects can be null, Optionals are objects. I’d rather it have been different from the beginning but now that it’s here it’s really not something that should change. Just never let anyone get away with returning a null for an optional... though I can imagine the scenario where in. A framework that might cause it to happen. To have special rules for Optional in Java is the wrong answer for a blue collar language at this level of adoption and age. They said they never want to make a change as big as generics again.
- blacktriangle 6y ago
  I have a saying for that: design patterns are a language smell.
  - pydry 6y ago
    Ha. Good one. I'm absolutely convinced that's true for some of them. I was never 100% convinced it was true for all of them.
BiteCode_dev 6y ago
Yeah I was teasing a bit. Same goes for Python. Reading the hacky code of a geographer for his SIG system is rarely a fun day.
- doctor_eval 6y ago
  Yeah - look it’s a really valid criticism about idiomatic Java, and is one of a (fairly small) number of reasons I prefer Go these days. I ended up writing a heap of non idiomatic Java and enjoyed it immensely. But you do get a bit tired of going against the grain.
dragonwriter 6y ago
> I LOL’d at this joke (again) because it’s true, but if we’re honest, it’s also unfair. ProblemFactory is a bad idiom, rather than anything to do with Java The Language. The Factory pattern’s pervasive use in Java was in large part a fairly direct consequence of JavaBeans requiring nullary constructors, so that the normal constructor work for a Bean had to be done elsewhere, i.e., by a Factory. Now, Beans was just a core part of the first-party enterprise framework that was central to the ecosystem and not strictly part of the language, but its not completely unrelated, either.
- doctor_eval 6y ago
  I’m not going to say you’re wrong because you are probably right :) but I don’t remember things happening in that order. JavaBeans was a super early Java spec and it introduced some (IMO) poor idioms, such as the mandate to use getters/setters. And I certainly agree that JavaBeans had a huge influence over the rest of Java culture (for the worse IMO). But my memory is that pervasive use of Factories came along many years later, and seemed to be driven by the perceived needs of TDD, for example to provide instances of mock classes in unit tests. And I thought the factory pattern itself came from the GoF, but I might be misremembering. That said, I’m not trying to contradict you. It’s likely that there was more than one driver for the pervasive adoption of factories. In any case it was a bit of a nightmare for a while, hopefully things are improving there now.
  - cbm-vic-20 6y ago
    On the other hand, JavaBeans was a simple pattern to understand and use, and the old OO dream of "software components that can be plugged together" actually worked: it was not uncommon for JavaBeans-compliant classes to work well together, even if the development teams never even heard of each other.
  - dragonwriter 6y ago
    > And I thought the factory pattern itself came from the GoF, but I might be misremembering. It did, and GoF certainly influenced OOP outside of Java, too. But EJB created a need into which the Factory pattern was really the only solution. (GoF precedes EJB and even Java.) But certainly its not the only thing; Java hit popularity right around the time GoF was most influential; OOP languages whose ecosystems developed earlier (e.g., C++) or later (e.g., C#, though GoF-heavy code isn’t unheard of there) wouldn’t be as influenced by it, all things being equal. Java just had the perfect combination of language features, early specs like JEE (which included Beans), and timing to be naturally inclined for maximum naive GoFism.
toomanybeersies 6y ago
> Java is a pretty great language, but some of the crap people stuck on top of it was (and still is) a nightmare for readability and reusability I think that applies to literally every language. Bad programmers write bad code, regardless of whether it's Go, Java, Python, Bash, or Assembly.

pydry 6y ago

The crap people created on top was typically responses to deficiencies in the language, whether they knew it or not. Stuff like "everything is a class".

BiteCode_dev 6y ago
Design design does lead community culture. Java also had the unfortunate destiny of becoming popular at the time where "OOP all the thing" was a mantra in tech circles. Also design pattern were all the rage. Those things have a huge inertia, and while Java is not a much more flexible language, the image stuck, to the point that new comers still implement singletons in the wild.
- pydry 6y ago
  Java created that hype to market itself. OOP all the things probably wouldn't have been a thing without it, for instance. It was very much a marketed language and a language designed to be sold to top heavy corporations. This fueled a lot of the crappy design decisions, the hype and the culture.
  - dragonwriter 6y ago
    > Java created that hype to market itself. OOP all the things probably wouldn't have been a thing without it, for instance “OOP all the things” predated (and led to) Java, it wasn’t a product of Java (C++, Objective-C, Object Pascal and, well, a bunch of other things from the late 1980s and early 1990s were where it got started.) Java was about a decade into it.
    - pydry 6y ago
      There's a big difference between "OOP is cool" (which Java didn't invent) and "OOP ALL of the things".
      - doctor_eval 6y ago
        But Java clearly didn’t “OOP all the things”, unlike earlier languages like Smalltalk. Java primitives are not objects (despite the fact that I often found myself wishing they were), and static methods are actually just functions. These days Java even supports first-class functions. I know not everyone will agree with me, and that’s fine, but I always found Java to be far more pragmatic than, for example, C++, which well and truely predated Java.
- dragonwriter 6y ago
  > Java also had the unfortunate destiny of becoming popular at the time where "OOP all the thing" was a mantra in tech circles. Java was a product of “OOP all the things”, it wouldn’t have existed without it.
doctor_eval 6y ago
I don’t think that’s true at all. Like most languages, Java has its share of deficiencies - I’d personally put null handling, type erasure and brain dead Optionals near the top of my list of things I’d change if I was King of Java - but fluent APIs and factory methods didn’t even start with Java, and have nothing to do with “everything is a class”.
- Pet_Ant 6y ago
  What is wrong with Optionals?
  - doctor_eval 6y ago
    Optionals can be null, so dereferencing them can still cause an NPE. Also the syntax is horrible. I know the excuse that they are just meant to be used to wrap the return value of a function that might be null, rather than as a guard against NPEs, but that just means we’ve got a crappy, verbose Optional class ... and NPEs. It was the most half assed attempt to fix the billion dollar mistake [0] anyone could have come up with. It needed syntax and compiler support, not a stupid wrapper class. [0] https://en.m.wikipedia.org/wiki/Tony_Hoare https://en.m.wikipedia.org/wiki/Tony_Hoare
    - sk5t 6y ago
      Likely to be addressed with the ongoing effort for value types. Optional + prudent use of @NotNull annotations can get you most of the way there already in practical terms.
    - Pet_Ant 6y ago
      Sorry but of course Optional can be null because of Java’s type system. Objects can be null, Optionals are objects. I’d rather it have been different from the beginning but now that it’s here it’s really not something that should change. Just never let anyone get away with returning a null for an optional... though I can imagine the scenario where in. A framework that might cause it to happen. To have special rules for Optional in Java is the wrong answer for a blue collar language at this level of adoption and age. They said they never want to make a change as big as generics again.
blacktriangle 6y ago
I have a saying for that: design patterns are a language smell.
- pydry 6y ago
  Ha. Good one. I'm absolutely convinced that's true for some of them. I was never 100% convinced it was true for all of them.

BiteCode_dev 6y ago

Yeah I was teasing a bit. Same goes for Python. Reading the hacky code of a geographer for his SIG system is rarely a fun day.

doctor_eval 6y ago
Yeah - look it’s a really valid criticism about idiomatic Java, and is one of a (fairly small) number of reasons I prefer Go these days. I ended up writing a heap of non idiomatic Java and enjoyed it immensely. But you do get a bit tired of going against the grain.

dragonwriter 6y ago

> I LOL’d at this joke (again) because it’s true, but if we’re honest, it’s also unfair. ProblemFactory is a bad idiom, rather than anything to do with Java The Language. The Factory pattern’s pervasive use in Java was in large part a fairly direct consequence of JavaBeans requiring nullary constructors, so that the normal constructor work for a Bean had to be done elsewhere, i.e., by a Factory. Now, Beans was just a core part of the first-party enterprise framework that was central to the ecosystem and not strictly part of the language, but its not completely unrelated, either.

doctor_eval 6y ago
I’m not going to say you’re wrong because you are probably right :) but I don’t remember things happening in that order. JavaBeans was a super early Java spec and it introduced some (IMO) poor idioms, such as the mandate to use getters/setters. And I certainly agree that JavaBeans had a huge influence over the rest of Java culture (for the worse IMO). But my memory is that pervasive use of Factories came along many years later, and seemed to be driven by the perceived needs of TDD, for example to provide instances of mock classes in unit tests. And I thought the factory pattern itself came from the GoF, but I might be misremembering. That said, I’m not trying to contradict you. It’s likely that there was more than one driver for the pervasive adoption of factories. In any case it was a bit of a nightmare for a while, hopefully things are improving there now.
- cbm-vic-20 6y ago
  On the other hand, JavaBeans was a simple pattern to understand and use, and the old OO dream of "software components that can be plugged together" actually worked: it was not uncommon for JavaBeans-compliant classes to work well together, even if the development teams never even heard of each other.
- dragonwriter 6y ago
  > And I thought the factory pattern itself came from the GoF, but I might be misremembering. It did, and GoF certainly influenced OOP outside of Java, too. But EJB created a need into which the Factory pattern was really the only solution. (GoF precedes EJB and even Java.) But certainly its not the only thing; Java hit popularity right around the time GoF was most influential; OOP languages whose ecosystems developed earlier (e.g., C++) or later (e.g., C#, though GoF-heavy code isn’t unheard of there) wouldn’t be as influenced by it, all things being equal. Java just had the perfect combination of language features, early specs like JEE (which included Beans), and timing to be naturally inclined for maximum naive GoFism.

toomanybeersies 6y ago

> Java is a pretty great language, but some of the crap people stuck on top of it was (and still is) a nightmare for readability and reusability I think that applies to literally every language. Bad programmers write bad code, regardless of whether it's Go, Java, Python, Bash, or Assembly.