I love Java in the same way.

But that free-thinking definition of Java clashes with the mainstream beliefs in the Java ecosystem, and you'll get a lot opposition at workplaces.

So I gave up on Java, not because of the language, but because of the people, and the forced culture around it.

The over engineering creeps in anywhere there is collaboration. It’s not a Java thing, it’s a corporate thing. The new teammate who refactors the perfectly working sql pipeline; the teammate who makes story points a required field on your trouble ticket system, the teammate who just saw a conference talk on rust and wants to apply it etc. Most engineers are not zen masters seeking out simplicity; they are lost with poor grasp of desired business outcomes so they procrastinate by adding complexity and indirection and focusing on tech as if it were the destination not the journey.

True, but there's also the bored engineers who just can't force themselves to write enterprise code unless they make it fun for themselves. I'm absolutely convinced this is why Clojure even exists and is so widely used in fintech.

> lost with a poor grasp of desired business outcomes so they procrastinate by adding complexity

I have come to see this as a mix of business people and developers not doing their jobs to protect thier paycheck. Business people, if they want to succeed, need to be converging on a strategy that makes money. Developers need to have a strategy for removing technical barriers to realizing that strategy. The lack of a business strategy often makes an overly general technical platform look attractive.

> focusing on the tech as if it were the destination

So common. Complexity should be considered the enemy, not an old friend.

The extreme focus on multiple layers of patterns, where actually a simple function would have sufficed IS a Java ecosystem and culture thing. Just way too many people doing Java, who have never learned another language or ecosystem, let alone paradigm, thinking "I learned Java, Java can do everything, I don't need to learn anything else!" and now feeling they need to solve every problem by applying design patterns mindlessly.

So how do you explain.. every other piece of software written by 5+ people?

Well, not by talking about AbstractFactoryProxy, that much is for sure. Rather by talking about which parts of the system are modular and what kind of flexibility the system allows for, what capabilities it has. Nowhere in that picture does a low level implementation detail like an AbstractBlaBlubFooBar enter the the conversation.

There is more to computer programming than the OOP clutter.

Someone's tweet from about 15 years ago (paraphrased from memory):

"We rewrote 200k line Java codebase in only 50k lines. Guess what language we used?"

The follow-up tweet a day later:

"It was Java."

> No inheritence.

Yup. Prefer composition over inheritance.

Such a hard sell during the heyday of OOAD. UML, Fusion, RUP, blahblahblah.

Having previous experience with LISP, it just seemed obvious, barely worth mentioning. Definitely set me apart from my colleagues.

FWIW: Our local design pattern study group tackled Arthur J. Riel's Object-Oriented Design Heuristics [1996] https://archive.org/details/objectorientedde0000riel https://www.amazon.com/Object-Oriented-Design-Heuristics-Art... Which might be the earliest published pushback against all that overwrought enterprisey ThoughtWorks-style brainrot.

> No ... dependency injection

Yes and: Mocks (mocking?) is a code stench. Just flip the ownership relationship(s). As Riel, and surely many others, have laboriously explained, to a mostly uncaring world.

Prefer inheritance if the first thing you're gonna have to do under composition is to crank out a bunch of delegate methods from the parent object to the contained child, to make the parent substitutable for the child, and the child won't be replaced at run time.

Probably. I personally haven't done anything like that. Though I'm not sure I follow.

I've mostly done ASTs and (scene) graphs. I prefer dumb objects, stuffing most behavior and logic in an Interpreter (design pattern) implementation. Being a very simple bear, my working memory can't keep track of all the smarts scattered all about.

My current example is processing SQL statements; think expression evaluator (subset) for a very specific use case. I tend to use so called "External" Iterators for walking trees, to keeping all the logic in one place. Versus Visitor, Listeners, or even Active Objects. Which is feasible for this use case, because its bounded and unlikely to change (eg extension points).

YMMV of course. Now I'm just babbling, apologies, and probably went too far off topic.