When Wirth talks about modules and abstraction I believe he was talking about what was known as the software crisis. In particular the observation that as programs size increases the number of possible interactions of program components grows quadratically.

Modules in particular and good abstractions in general make the number of interactions between components tractible.

The N^2 component interaction problem is real and it continues to cause problems.

Even with our best solutions there is room for improvement.

Last I paid attention there was a culture that had developed around the administration of CISCO routers because things that should be unrelated affecting each other is a real world problem for the administrators of those routers.

Any time something changes in siftware and something unrelated is affected this general problem is making it's appearance.

There is also a long term tension between abstractions and entire system simplicity. The wrong abstract or an abstraction poorly implemented can make things worse.

In a well-designed (or "proper") abstraction, we can deal with it in terms of its public interface. Two things that break abstractions are bugs and performance.

If you have either of those, then abstractions can be worse.

Another thing that is bad is the wrong abstractions, or abstraction inversion (https://en.wikipedia.org/wiki/Abstraction_inversion), where a layered system hides abstractions at the bottom from layers at the top, that top layers would nevertheless like to use, and reimplement, poorly. This happens surprisingly often.

But overall, I generally think that well-designed and factored abstractions are better than no abstractions at all.

I disagree as well. Abstractions, or interfaces, define the contract between modules, and then you can reason about the system in terms of those contracts. Without the abstractions, you’d have to reason based on all the details of the whole program, which is obviously much harder. Abstractions are a form of divide and conquer.

Regarding the article’s point about diluting abstractions when new disparate features are required, a third alternative (to the two presented in the article) is often to provide alternative abstractions in parallel, each individually still focused and to-the-point, which prevents both changing and diluting the existing abstraction.

Regrading the article’s point about performance analysis, in principle you can specify performance guarantees for each abstraction. It’s more difficult to check them, but in theory a type system could even encode performance characteristics in an automatically checkable way.

After reading the article I think the point stand. Not always but for example when working doing a RDBMS all the abstractions are active inhibitors and even hostile to do what should be done (easier) without all that.

And then you need to know that "no, all that IO sys call not do what you want, how yow want neither how is documented or even practiced by most" to take the most obvious case.

So, yes, this is a case where this quote is on point.

I agree with this. One way that I will go further is to say that “understanding of the whole system“ is a pretty fraught phrase. One person‘s holistic understanding is another person‘s gnostic gobble-de-gook. Realistically, they are all essentially just abstractions bounded by a different stopping rule. Just because one person‘s view of the whole system does not include what the GOOGLE engineer writing the code had for breakfast does not mean that that can’t be reasonably included.

The issue I think people have is that abstractions do not announce when they are insufficient or porous. This means that an abstraction which is perfectly trustworthy without further inspection for many years can suddenly become hazardous without warning.