<i>Thus, it is possible to make a language “better” by removing features that are considered harmful, if by doing so it makes programs in the language better programs.</i><p>Pareto and Cost/Benefit! A Type System is just a set of features in the compiler and other programming tools. Does our field have good data on the cost-benefit of features in type systems? Granted, this is quite complicated. Additional type data can enable features, like more kinds of and more reliable automated refactorings, but it can also incur costs, like slowing down the writing of new code and the programming tools.<p>Due to the Pareto principle, I suspect that most of the benefit of both dynamic language environments and type systems come from a minority of the features in each. I also suspect that many of the costs vary with context and time-frame. "Programming in the Large" problems may never, ever apply to certain projects. Long term maintenance issues may not apply to other projects.<p>"Experiments" in programming language design generally seem to be at a ridiculously large granularity with ridiculously poor experimental design. (Let's write a new language!) Is it any wonder then, that our "field" is really "half a field?"
So every "language" basically becomes a "hub" language, with lots of sub-componenent syntaxes, dedicated to a specific task. Functional programming would be the future of all "Hub" programming, if it were not for the performance costs.
The "language" a project is written in, boils down to the percentages one or several of the tools of the swiss-army-knife Hub language are used- or even subverting (as in replacing) another language. You could create a sort of functional-programming-tool in assembler - if your project is performance thirsty.
So i guess the next step is to allow architects to limit certain language features to prevent architectural decay.
Templated Packages that adapt the language percentage of reused Components to the projects needs?