On the irony of programmers who don't like abstraction

An inflammatory anti-Rails post has been getting lots of discussion lately. The author's frustrations are legitimate, but his articulation of the problem takes an absurd turn:

The really challenging part in this discussion is being able to explain that it is a problem in the first place. People are attracted by Rails because it gives you a false sense of simplicity, whereas what really happens is that complexity is being hidden by convenient interfaces. [Emphasis added]

That is the definition of abstraction. The author is complaining about abstraction while taking a massive tower of abstractions completely for granted.

How much programming would we all get done each day if we weren't hiding the massive complexity of our hardware beneath a stack of convenient interfaces?

For a Rails developer, it’s not a problem that data coming from a web form are being sent to the depths of ActiveRecord where God knows what will happen.

ActiveRecord is hardly "the depths". After ActiveRecord, your data will probably go through Ruby's I/O system, TCP stacks, IP stacks, low level kernel I/O, firmware on network cards, a database management system (itself comprising multiple layers of semantics), and will ultimately move some electrons around somewhere.

And you don't need to worry about any of that, most of the time. That is the point of abstractions. That is the point of "convenient interfaces that hide complexity."

Bad abstractions exist and they are worth criticizing! But that is a different (and more productive) kind of debate.

When people reject the idea of ambitious, powerful abstractions in favor of "a diverse ecosystem...[of] small, focused, simple and robust libraries" they are confusing implementation with interface. Yes, the implementation of a powerful abstraction should be separated into focused and robust libraries. But if its interface exposes all of those libraries, it will be a poor interface for getting things done.

The name of the game is building the next abstraction layer upward. At every historical stage in computing, there were programmers who thought we were obviously done and shouldn't add another layer. People literally argued that compilers were too much abstraction, and real programming would always be done in assembly. They were wrong.

The same thing happens today when people rhapsodize about "many small libraries". "Many small libraries" is an obvious evolutionary backwater. Eventually somebody gets the next abstraction layer right, and all the application development goes there.

Updated to add: the author of the original post reached out and clarified that he did not intend to criticize all abstraction, merely that he is frustrated with choices in AR, and he isn't "anti-rails" at all. See his comment here. That is the kind of more constructive debate I intended to provoke.