Lately I’m writing C++. I have code that needs to deploy across different mobile ecosystems. Java doesn’t cut it, Kotlin has a cross language offering but it’s not prod ready, and Rust... well, the team doesn’t know Rust and we won’t hit our dates if we have to learn idiomatic Rust, and once we ship the code, it won’t be as simple getting some customers updates as we have customers in the wilderness and these aren’t iOS or Android devices that we can just release to using app stores.
Despite Java’s verboseness and all the factory hell, with recent tooling and the massive library of great open source libraries, I do enjoy writing it. I prefer strong typing personally. But I don’t agree with Java for everything. Recently I did some data processing work on Spark. I wrote everything in Scala. The whole “trait” functionality was very nice and elegant, and it allowed me to incrementally build some nice abstractions that my team can use to quickly build and deploy spark jobs.
This gets repeated so often, but it's mostly never been true in the general use case (it was mostly a J2EE/EJB thing). It's a silly Java meme that I wish would just die. If you don't like the factory pattern, don't use it.
Saying it has “mostly never been true” and dismissing this as a “Meme” couldn’t be more off.
A lot of programmer effort in any organization goes towards supporting existing software, which in the Java ecosystem tends to full of all the factory non sense. I’m sure these concepts started off in the J2EE space, but it’s infected a lot of different types of projects because people assumed these patterns were “good” or inherently part of Java. And here we are now dealing with the mess.
I've been working on enterprisey Java software for nearly two decades, and I've never come across anything that's full of "factory non sense" in the wild. Sure, I'm just one person, but I've worked on more projects than I can count. With good teams and bad teams alike.
I'm sure there are shitty programmers in every language community, who will write things using concepts they understand only marginally, and I'm sure it has lead to a couple of FactoryFactoryFactories here and there. But the ecosystem is not "full" of this at all.
Java isn't the same as it was 20 years ago. It grew up.
Colleagues, from my experience, tend to be human beings you can talk to. If this were a deeply systemic language issue, that would be a different matter. But this is something that's solvable by educating the rest of your team.
We checked Kotlins website and they explicitly said the cross platform offering was in alpha Is it now out of beta? I’m on the website now and it shows alpha still
I mean following 100% seriously: there is no such thing as factory hell. Even in the few places who do actually overuse factory pattern, it is braindead easy to figure factories out. It is not like would be something difficult to understand.
Using factory someone else made is tedious? In what way it is more tedious then using constructor?
It is just that thing ... there are patterns that are tedious. The object mapping before hibernate was extremely tedious for example. But factory pattern ... seriously?
If this "adding hours to your bill" you need to speed up. And learn IDE of learn type or just watcy other programmers a bit. Cause no one I know spends hours on this.
Second, factory methods today have arguments combinations too. fd.create(a, b, c) is the most normal thing in the world.
Despite Java’s verboseness and all the factory hell, with recent tooling and the massive library of great open source libraries, I do enjoy writing it. I prefer strong typing personally. But I don’t agree with Java for everything. Recently I did some data processing work on Spark. I wrote everything in Scala. The whole “trait” functionality was very nice and elegant, and it allowed me to incrementally build some nice abstractions that my team can use to quickly build and deploy spark jobs.