The most difficult part of language design and development is motivation. To wit, what does it do? Some tangible action is necessary, else you have a pretty useless system. To get off the ground, a language needs a killer application.

For Pascal, the killer application was apparently an educational environment. Students learned Pascal first (or early) because it made a good teaching language, but then they wanted to use it in their later persuits because it was somehow easy on the brain. However, the core standard Pascal language doesn't mesh with hardware or operating systems, and its type system leaves much to be desired, so vendors (notably Borland) produced enhanced Pascal derivatives which were mutually incompatible. Some of those products were flat-out amazing. Then, there was a language war, and Pascal is now a rare appearance in the modern world.

For C, the killer application was Unix. This was convenient, because it meant that C came standard with a fairly capable IO system and a fine ability to bash bits. It was conceived in an era when computers occasionally had funny word sizes like 36 or 40 bits, so the standard is flexible, but broad. You can learn C and use it anywhere without having to learn much. And if you port Unix to a new system, you automatically get C without any extra work. That was a tactical advantage. But when Microsoft ordained C (and later, C++) as the official language of Windows, Pascal didn't have the mindshare to make a serious response. These days, it's a dead language in the same category as Cobol. The only people that use it regularly are maintaining legacy systems.

Now, we are in a new era of computer language history: the age of scripting languages. Their "killer" problem domain is to glue lots of existing systems together at a very high level. In the process, creators produce a Turing-complete language that also happens to have a metric boatload of interfaces to external sources and sinks for data. They talk to databases, files, web servers, and graphical terminals. They understand all manner of internet protocols. They are like a data-processing toolbox the size of Geneva strung together on a bicycle chain. When you deploy Perl, or PHP, or Python, or Ruby, then chances are pretty good that someone else has already solved the hard parts of your problem and most of your job is to write the glue to connect various subsystems. However, the languages are Turing-complete, so you can also write any amount of logic that you need. It might not be very efficient, but you probably don't care because hardware is cheap, problems are plentiful, and programmers with half-decent kung-fu are scarce.

The biggest issue that scripting languages face today is the profusion of unharmonious, inconsistent interfaces. To take a recent version of PHP as an example, it talked to scores of database servers from Oracle to SQLite, but each had a unique set of function names and interaction styles. PHP has always been bad about that sort of thing mainly because it has only recently gotten serious about object-oriented module interfaces. Perl actually did a pretty good job standardizing its database interface, but Perl's parameter passing mechanisms are surprising, unusual, Baroque, and verbose. Its support for object-oriented programming is a Rococo mixture of preexisting features, clever hacks, and spurious abbreviations. Python has a pretty consistent set of ideas about what classes and objects are, but it gets lost in a maze of twisty little magical method names with double-underscore prefixes whenever you try to integrate your code with the hooks in the 3GL-style control structures. Ruby is actually pretty smart with its use of scoped code-blocks as parameters to methods, but it's slow and it also fails at the most important interface: accurate English documentation of the latest version of the language. Lisp, for all its wonders, will not take over the world until its proponents can humble themselves. And oh, by the way, tail-recursive thinking is not generally natural, so that's an unharmonious interface to the (mere mortal) programmer.

For a new language to take root, it needs a killer application, but it will only flourish if it concurrently relieves programmers of more burdens than it imposes. I'm curious if anyone has ever done usability studies on different programming language features and patterns. And I'm curious if anyone has any killer application ideas in mind.