I always figured that Java folks were

- paid per class

- sought to reduce the number of executable lines per class to 1.

I actually knew a guy that argued that one method per class is ideal. He never quite got that at that point you're really just writing a function with a manual closure (the constructor).

Tbh that was Alan Kay's vision of object oriented programming. Lots of tiny objects collaborating via messages.

Was it tiny objects or tiny messages, or both? And I wonder how much of the Smalltalk system was made that way. I think at some point your class needs to handle some complexity that isn't easily broken into smaller classes.

But that’s just OOP in general. You can choose a language that defaults to not using OOP-style abstractions, but then people will question why you choose python/node/ruby over a proper language like Go (or whatever else)

> But that’s just OOP in general.

Nope, that's OOP taken to extremes rather. Java does that with enforcing things to be classes.

The OOP paradigm itself requires rather heavy use of abstraction. You can deviate from those patterns to an extent, you can add more polymorphism if you want to, you can be selective in using some design patterns like DTOs. But most of the complaints I hear about Java would apply equally to most of the C# projects I’ve worked on, because those are just the annoying bits of OOP. I’d agree the Java is a bit more inflexible, but it’s not like the other OOP languages aren’t also full of boilerplate and layer upon layer of abstractions.

I will be honest and tell them it is because these are more productive and I enjoy being productive

How productive you are with any particular tool really depends on what you’re trying to do with it.

Exactly! Almost nothing in the naming based on something with a very precise definition.

It's the unruly mind coming up with generalised words.