Interesting claim that "language designer" == "mastermind." Being great at designing notation for algorithms (which is what languages really are) is conceptuall

Interesting claim that "language designer" == "mastermind." Being great at designing notation for algorithms (which is what languages really are) is conceptually distinct from what most people think of as being a good programmer. It so happens that some language designers have found themselves in that place by virtue of being great programmers (the example that jumps to mind is Dennis Ritchie), but the two coincide less and less often as the field matures, and languages become less of a "systems" problem. At least in academia, the programming language people are perhaps the least likely to ever have to write a line of code in anger. This gap between coming up with neat notation and the resources need for a world-beating implementation of a language is one of the tragedies of the "dictator-for-life" that has arisen for the "developer productivity" languages (perl, python, ruby...) The language equates in practice with the particular implementation that the designer banged out and maintains. The presence of this reference implementation strangles other implementations in the crib, because users know that libraries, .deb's, new language features, etc., will appear first in the dictator's implementation. Thus, we have datacenters full of nice fast CPUs that spend their lives executing Joe's-favorite-language's switch-on-bytecode VM loop, when they could be running a compiled implementation with more sensible resource usage.