Fork me on GitHub

I'll probably have to build my next service in Java 😭 Has anyone felt it hard to go back to Java after Clojure, everything feels like such a chore. I'm opening services and there's 200 classes in them, factory, provider, processor, connector, why you need so many classes 😭


Yeah, I had to go grubbing around in a widely-used open-source project written in Java the other day to determine whether a behavior I was seeing was a bug or just something confusing in the documentation (it turned out to be the latter) but -- OMG! -- the amount of back and forth I had to do with class definitions and long inheritance chains to figure out the exact behavior of this small feature was unbelievable... And then I thought back to what my life was like when I did Java for a living and realized that was "normal" and I'd just gotten out of the daily habit of doing it all the time, having spent over a decade now working with Clojure! We're very spoiled by the simplicity and the data-focused aspects of Clojure and just how little code we really have to write to get things done.

💯 4

Let me know if you need library suggestions. There are painful and less painful ways to write java

Martynas M17:06:14

Boundary is a thing. In Java you code based on countless boundaries. House is a boundary, garbage bag is also a boundary. If you want your world to have countless amount of boundaries then you use OOP. Maybe we should call it BOP as in "Boundary Oriented Programming". :thinking_face:


As I glanced at the notification of that response on my phone I read "Bondage Oriented Programming" so I had to open up Slack to see what you really wrote...


Bondage Oriented Programming seems apt for the style that's proficient in Java haha


It's not just boundaries, it's just how heavy handed objects are for simple things. Objects are so hard to create you need a factory, but then you can't just have some simple function for it, so the Factory itself has to be a whole class, and now the factory is hard to create so you need a Factory for the factory 😝:man-facepalming:

respatialized18:06:17 maybe one day my brain will be SOLID enough to understand this in all its majesty

💯 2

I've been working with the Apache OLTU source code recently (we rely on parts of it as a library at work but it has a number of long-standing CVEs and it's essentially abandoned at this point, so I'm reimplementing the few pieces we actually need -- as plain hash maps and simple, pure functions). It has so many classes and deep inheritance chains, where every method is just a few lines of code that delegates almost everything to other classes, but what really made my jaw drop was that it has a variety of <Something>ParameterApplier classes that exist just to bash strings together to build parts of URLs, and lots of methods in the main code create transient instances of these, just to call the apply method on them and there's stuff like:

this.applier = new QueryParameterApplier();
if (parameters.containsKey(OAuth.OAUTH_ACCESS_TOKEN)) {
  this.applier = new FragmentParametersApplier();
  this.applier = new QueryParameterApplier();
return (OAuthResponse)applier.applyOAuthParameters(msg, parameters);
(and this is the only place in the entire codebase where that FragmentParametersApplier class is created and used -- and it modifies the parameters object passed into it, whereas QueryParameterApplier does not -- and why is one plural and the other singular?). And every class has at least one builder as well as all the usual setters -- so there's no consistency and you mix'n'match multiple styles of usage. It's just awful!

💯 1