Well. That escalated quickly.
At the risk of getting what's left of my hair singed off:
1. I've been a working programmer for half my career and a project manager the other half. I've written real code that does real stuff in a minimum of three languages (including a game my wife plays every day, and she's a perfectionist) and I've written useful working programs in at least half a dozen more languages. I've worked "lone wolf" and in teams with Much Process. So I feel like I've got a reasonable set of experience with seeing programming from different angles, primarily as a down-in-the-trenches, I-will-not-let-the-language-beat-me coder and as someone responsible for the scheduled development and long-term maintenance of high-criticality software systems. So there are some bona fides. The rest of what follows is based on this experience, and on reading the thoughts of others (e.g.,
Gerald Weinberg and
Fred Brooks) about this stuff both for fun and for professional development, and on trying to think carefully about it.
2. Natural programming ability is probably on a bell curve. A few are really bad; a few are superstars; some are incompetent; some are excellent; by far the majority of programmers who span the full range of what programmers do are simply competent.
3. Context matters. Not all coding requirements are equal; some products are harder to code than others. Programmer skill is not irrelevant to context.
4. It is entirely a Good Thing that lots of new programming languages are created! I strongly endorse lots of creative effort in imagining new ways of expressing functional requirements as software.
5. A well-designed programming language takes into account both the intended operational context and the typical skill level of its likely practitioners. A language for writing single-function programs on which human lives depend (think the
Apollo Guidance Computer software or the HUD of a jet fighter) has different design characteristics, and will typically be used by highly-skilled programmers, than a language whose primary value characteristic is that programs written in it are easy to understand and maintain over several decades by junior and average-skill programmers.
So adding all this up, when we talk about designing a new computer language, I don't believe there's a single metric for deciding the quality of that language. I think you have to take into account the context in which that language will be used (specific or general-purpose) and -- connected to context -- the typical skill level of the people you want to be able to productively use that language.
If it's a special-purpose language that's meant to allow superstar coders to blast out massive amounts of working code quickly, that's 100% fine. We can discuss what kinds of features a language like that ought to have. It's important to understand that a language like this will never be popular enough to be self-sustaining -- the developer(s) will have to actively support it in some way, either personally or by making a deal with some institution. That's the price for targeted performance.
If it's a general-purpose language that's meant to be easily comprehensible by the average coder, then that calls for a different set of evaluation criteria. We can also discuss what kinds of features a language like this ought to have... but it's equally important to understand that the tradeoff for comprehensibility is usually performance. There is also nothing inherently wrong with this.
To sum up, then, I'm saying that a general-purpose language is probably better if it has features that protect average-skilled coders from themselves. Absolutely you pay a performance price for things like static typing and garbage collection... but if your intended context is business software, then that cost is almost certainly paid for in the value of fewer hours wasted hunting down conversion bugs and null pointers. Conversely, if your intended context is more specific -- such as, oh, I don't know, a game engine, maybe?
-- then there may be more value in removing the safeguards and depending on the greater skill level of the language's likely coders to avoid errors.
To put it another way, if all the developers supporting my long-term software projects were as good as the Procedural Reality team members, I'd support a high-performance, low-controls language as a general programming language.
But they aren't. So I don't.