Have modern programming languages failed? From the point of view of learnability and maintainability, yes! What would a truly maintainable and learnable programming language look like? This is the first of a six-part series exploring the future of programming languages (read The World’s Most Maintainable Programming Language: Part 2, The World’s Most Maintainable Programming Language: Part 3, The World’s Most Maintainable Programming Language: Part 4, The World’s Most Maintainable Programming Language: Part 5, and The World’s Mode Maintainable Programing Language: Conclusion).
Modern programming languages have failed. Some run poorly on the wide range of modern machines and platforms. Others make it too difficult to produce correct programs. Still more are too cumbersome, clunky, and quirky for average people to use and to maintain their programs.
Analyzing the failure of all languages over the past fifty years of programming should make it possible to design a language and platform far more suited to the next fifty years of programming and beyond. Here are some of the features and design principles of the world’s most maintainable programming language.
What features of a language affect its maintainability? Unquestionably they are learnability, consistency, simplicity, comprehensiveness, power, and its enforcement of good programming practices. Note that some of these attributes overlap. That’s fine; they all approach the same goal from different directions.
Note that, in this context, the maintainability of a language refers not to its design or implementation but the design and implementation of programs written in the language. (Of course, the implementation of the language should also follow these goals….)
There is nothing more important that you can do with a language than to learn it.
The most important gauge of any programming language is how easily a novice programmer can maintain a significant program in any problem domain. This is perhaps the greatest failing of today’s popular programming languages. It is nearly impossible for a new programmer to join an organization and take on a productive role on an existing project.
The contrast to non-programming projects is obvious. A new employee in any other environment does not have to learn an entirely new spoken language to communicate with his or her co-workers. Yet all programming languages rely on subtleties of syntax and notation — and these idoms vary across languages. Though such a worker could easily take a random paragraph from sources as varied as the New York Times Book Review or The Day I Swapped My Dad For Two Goldfish and understand both, it is nearly impossible for even an experienced programmer to read and immediately comprehend the intent of a random piece of source code — let alone find a bug and maintain that section of code.
Fortunately, some language designers have found this situation likewise intolerable. Among them are John McCarthy and Guido van Rossum. Of course, there was only so far they could push the evolution of their languages, but they have perhaps come closest to the goal thus far. I would count Alan Kay in this group, but my impression is that Smalltalk failed as a teaching language primarily because the world is not object-oriented.
Some readers may argue that programming should be a discipline restricted to the high priests of software (and here I satirize their position, though I hope not too unfairly). Like the growth of the amount of written material in the world after the invention and dispersal of the printing press, the amount of software existing and necessary in the world is likely to grow. This counts software for both business and personal purposes. Add to that the likelihood that more of this software will be freely available (free and open source) and you have the situation where gaining more developers and maintainers — even hobbyists — is tremendously important to making all of this software work.
To enforce learnability, the language must resemble human language as
far as possible. This means refusing to add the jargons and idioms of
existing programming contexts for two reasons. First, they are unfamiliar
to people unfamiliar to programming, and thus barriers to learning. Second,
they may be unhelpful in the context of people already familiar with
another programming language. That is, an
if statement may
look familiar to a construct in another language that uses
then pairs — such false cognates are
confusing and distracting!
It might be worth considering banning the use of mathematic and typographic symbols altogether. There may be objections, citing linguistic support for punctuation symbols in English, for example. Consider how often writer’s abuse the apostrophe; not to mention the semicolon.
The ultimate goal, of course, is to produce a language in which it is impossible to write a program that a novice will not understand. By making this the primary language design goal, all other design goals are subservient and reinforce this language attribute.