> 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.

> 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.

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.

> 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.

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.

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".

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”.

What is wrong with Optionals?

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

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.

I think you’ve read me out of context. Of course I understand why Optionals can be null, I was just pointing out - literally in defence of Java - something I don’t like.

I don’t really get your other arguments. I think the problem has been solved better in other languages including Swift, Kotlin and Rust, and Java could have learned from them, but didn’t. I can’t see why direct language support couldn’t have been added to solve this “billion dollar problem”. Even the Elvis operator would have helped.

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.

I have a saying for that: design patterns are a language smell.

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.

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.

> 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.

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.

> 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.

There's a big difference between "OOP is cool" (which Java didn't invent) and "OOP ALL of the things".

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.

> 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.

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.

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.

> You know the joke: a dev has a problem, uses Java, and now has a ProblemFactory :)

I think this joke is probably about as dated as the versions of java it was made about.

Unfortunatly, I know a lot of devs that don't even know it's a joke.

Singleton is still a design pattern used in the wild.

I'm not going to argue there are lots of ridiculous patterns out there, which seem to be embraced and encouraged by the various frameworks that a lot of developers seem to rely on.

Why bother setting things up explicitly in the way you want when you can declare things as injected, other things as singletons, and then have no real idea why it all went horribly wrong?

It's starting to be the same in Python though.

Inertia is huge in our industry, and the HN bubble doesn't gives a good picture of it.

Behind corporate firewalls I now see things done the way they were 10 years ago: packaging, string handling, concurrency...

I assume it's the curse of being popular and old.

And java has been popular for longer than Python, so inertia is even stronger. It doesn't matter if it has lambda since V8 if people still believe the best practice is to pass fat objects around.

The cool devs don't use the Singleton pattern anymore, we use @ApplicationScoped.

(Poe's Law disclaimer: yes, that was light sarcasm.)

Generally the Python codebases I've looked at have been more straightforward and therefore more immediately readable than Java codebases. You could write a simple codebase in Java, but if so many people use it to write complex monoliths, maybe the language does have some (in my view negative) influence.

> You know the joke: a dev has a problem, uses Java, and now has a ProblemFactory :)

It's a funny joke, but it maligns a harmless pattern identical in FP to a function returning a function.

While FP coders would brag about how awesome high-order functions are, we just keep mocking our own style for some reason. Factories are very powerful when used right.

The problem with Python today is that it only plays nice with C... which is a problem, since it's integration with JVM is probably more important today than 10 years ago.(Spark, Hadoop, etc)