Your argument is a common one, but it’s founded on a flawed premise: that Algol-language users know what they’re doing. Sure, they can read and write code written in that language, but how many of them actually understand the problem domain in which that software ostensibly solves problems. Truth is, a lot of programmers today are simply faking it: they don’t understand the business; what it does, why it does it, why it does it the way it does, and what the problems are that it has doing it. They know how to write code, and that’s all they know; or are interested in knowing.
For that type of programmer, rolling language constructs for the sake of rolling language constructs is simply a way to make themselves appear busy and productive without actually having to produce anything of value. Because to write useful code they’d have to learn the user’s business first—and that’s exactly what they want to avoid, because they hate having to learn stuff they’re not interested in and really don’t want to do it.
Take away the Lisp and give them an Algol; won’t make a blind bit of difference. They’ll still churn out the same endless makework, only this time it’ll be expressed as vast convoluted pointless class hierarchies and reams of autogenerated boilerplate. (You mention Rails: Worst Offender Ever.) Idiots will write useless code in any language.
Business accepts that type only because it doesn’t realize how bad it’s being scammed by them; which often as not is because the managers responsible for running that business are an absolute bunch of know-nothing bullshitters themselves.
..
The only people who will benefit from Lisp expressiveness are those who appreciate that the language itself and the code written in it is the least important part of the whole process. Because what they’re interested in is understanding and solving the users’ problems, and if they have in their toolkit the ability to construct a language that talks in the language of the business itself then so much the better for solving it.
You don’t have to be a great programmer to do this, and do it successfully too. (I’ve done it, and I’m a bear of very little brain.) You just need to understand the business itself; to get in the shoes of the folk who do those jobs day-in day-out and walk around in them till you see their world as they do. Once you can speak the language of that business well enough to “pass”, making a machine speak that language too is NBD. And once the machine speaks it, well, there you go. Cos that’s not a language that bangs two rocks together. That’s a language that lays a six-lane freeway in fresh-baked tarmacadam, all painted and ready to roll.
Code is not the product. Code is just tedious crap you have to wade through on your way to the product. As a developer, nothing pleases me more than not having to write code; or at least no more code than is absolutely unavoidable.
..
Those Nile links are good ones, I do recommend following them up. How to write a graphics pipeline in a hundred lines of code. Imagine if every program we wrote was like that, even programs that currently run to tens or hundreds of thousands of lines in those familiar “safe” Algol languages.
That’s what we should be shooting for in this profession, cos I dunno about you but I’d rather learn to read a hundred lines of code written in a custom language that’s tailored to that domain than 10,000 lines in a lowest-common-denominator crapfest like C++.