This idea is often repeated in programmer's forums, yet I think it's simply not true. Abstraction is not there to make things easier to understand, it is there to empower you _after_ you understand the abstraction. It is there to pack the knowledge you _already have_ after working with some system, and being able to port it to similar systems.

Let's take math as an example. Understanding the "+" operator is much harder than understanding that if you have two apples and you get another one, then you have three apples. However, once you grasp the "+" operator, you can quickly solve a bunch of related problems where the "+" operator applies.

This does not mean that I disagree with the rest of your comment though. Java's (classical) means of expressing abstractions are fairly limited - basically, you need _interfaces_ for everything. In most cases, this leads to a lot of cognitive overhead that obscures the essence of the abstraction being used.

A simple example of this problem is the lack of function values and lambda types (pre jdk8). Due to these missing features, people expressed the same abstractions by defining interfaces that define some method, and then providing implementations as anonymous classes. That is, instead of defining a function type and then just implementing it, you now have an interface and weird class declarations in your code. To the untrained eye, this is much harder to understand. As a result, some of the programmer's cognitive effort is now spent on this, and hence it becomes harder to understand the more useful part of the code (which is likely some kind of abstraction).

Just to shed some more light into this, consider Haskell's _monads_. Monads are very hard abstractions to grasp. They are much harder to understand than just "doing whatever you want to do and call it a day". However, they become extremely useful once you understand the abstraction and become available to use it without the cognitive overhead.

I think some abstractions exist for either reason, and some for both reasons, but either way thanks for saying it this way - you definitely put it better than I did.

There are certainly unnecessary parts - there's a hell of a lot of bloat in spring - but just doing without frameworks entirely is not the answer.

Sure there are. There's even a version of Spring for Python. It's just that nobody uses them. You're free to guess why.

Which only confirms what parent comment wrote.

There are plenty available, just not one dominant one.

> I'm tempted to suggest that Python doesn't have these frameworks because it doesn't bother to support writing large programs.

That probably approximate the truth, in that the brittle "large program" architectural style that IoC/DI approaches seek to mitigate the harms of is probably less popular for large systems where Python is used (or at least the Python parts) which favor smaller programs interacting through standardized communication protocols for constructing large systems.

> Likewise with testing, there's the unittest module but it's not really integrated with a build system or anything else.

Since there is no "build" with python, the fact that its unittest module is not integrated with a build system isn't surprising. There are plenty of tools that support integrating unittest (or other python testing frameworks) in workflows, including utilities that do testing on every file save (similar to autotest in Ruby). Obviously, in the absence of a build step, they aren't integrated into a build system, but the workflows are often better because of the absence of a build step.

Well, last time I needed something similar on Python, I just loaded the settings from the database, included the wanted code at runtime, and inserted the desired symbols at the local context. Took a bit more than a day to write, and was very appliction specific, but saved a lot of trouble with those crazy constructors that appear on Java.

(I am from a Perl environment which have a bit emphasis on tools/libraries and language extensions, because it is easy to do with automatical tests on most every platform/Perl version.)

Well, it is quite natural that the tools for large code bases are more common in Java. Not only because Java is traditionally used on conceptually larger projects... :-)

Anyway, as a Perl guy I can tell you that DI is commonly used in Perl, if nothing so because of the testing culture.

Modern PHP has cloned that. See for instance the Symfony 2 framework.

So what are you proposing? That everything has to be built in into the platform itself, hidden away from me? In fact, Java not doing so is a big advantage, because it allows me to change the implementation. Otherwise, everything has to be done by the platform developers. I would depend on their resources.

In the Java world, if something is worth to become part of the platform (either a new language feature such as try-with or a new core API or runtime library like Joda Time), it is discussed within the JCP. This created an ecosystem, where I can plan for the next 10 years and not just for the next it-does-everything-dynamic-language cycle-jerk.

BTW. If you want to reduce repetitve tasks, you should use code generation. That's the best abstraction and Java is a nice simple language to generate.

> 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.