> See, this is a mistake. Abstraction is not an end in itself; it's there to make life easier and to make things easier to undestand. > Bloat is one of the man

> See, this is a mistake. Abstraction is not an end in itself; it's there to make life easier and to make things easier to undestand. > Bloat is one of the many things abstraction is supposed to reduce; if an abstraction is increasing cognitive overhead and reducing the signal-to-noise ratio, then we've got ourselves a problem. I whole-heartedly agree, but I'd caution readers not to conflate abstraction with bloat. If it's bloat, chances are you're abstracting the wrong details, and working on a system suffering from poor cohesion. > For reasons that I cannot comprehend, Java seems to be the only language that seems to have excessive abstraction as a requirement. Not as a convenience, not as a nicety, but as a requirement to do things like Dependency Injection, Inversion of Control, Unit Testing, Mocks, logging, etc. The fact that you need to use entire frameworks to accomplish the functionality that in many languages is covered by a couple functions in a built-in module is a mystery to me. I'm not sure I follow. Are you saying that you think it's wrong or inconvenient that these features aren't somehow natively supported by the language? That is, that you'd like to have a grammar/syntax around each one of these things which ultimately boils down to a bunch of hidden runtime anyway? Maybe it might help to clarify that I'm defending Java the language, not Java the runtime library. > Java ... seems to be the only technology that requires me to grok a dozen files to understand basic workings of MVC systems with the most elementary of logic I do agree that web frameworks in Java are one area where there's just tons of bloat, but I still don't think that has anything to do with how the language is designed. My advice: get a better MVC. There's nothing about MVC that says you must use a framework. (Edit: if it's the container that you're fighting with, there are tons of other options out there aside from the mainstream few). Also, check out the network code in the Linux kernel sometime. Beautiful code, but holy shit do you need to shave a whole heard of yaks the first time you go to read it. The cognitive overhead is high, but each one of those abstractions is there for a reason. > This points to me towards the idea that Java abstractions have simply been poorly chosen. Again, given that I'm talking about the language alone, not the runtime library, if you still uphold your response I'd ask you to consider who's fault it might be that the abstractions used in your program(s) are poorly chosen. It's quite rare that it's the fault of the language.