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 fourth of a six-part series exploring the future of programming languages (read The World’s Most Maintainable Programming Language: Part 1, 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 5, and The World’s Mode Maintainable Programing Language: Conclusion).
Programmers should be able to accomplish anything they envision with ease.
It should be possible for a novice programmer to write a program to accomplish a complex task in a reasonably short period of time. Many of the other design goals attempt to address this point. For an obvious example, if the language did not include an XML parser (with namespace and schema support, of course), a novice programmer should be able to learn the language and write the parser within a few hours or perhaps an afternoon.
The true definition of power and expressivity in a programming language is how little it gets in the way of a programmer when he or she is programming well and how much it gets in the way when the programmer is programming poorly. Power should flow towards maintainability and against bad practices.
To some extent, this is the responsibility of the tools used to program. For example, though a language can enforce the use of object orientation and forbid the use of overloading (two of the most important design principles for maintainability), only a compiler or similar static analysis tool can verify that there are sufficient comments of sufficient semantic applicability to make the written code sufficiently clear to a novice to the language and problem domain.
Like languages, however, different tools have different levels of power and usability. Using the Eclipse IDE improves the Perl programming language by use of garbage collection, freeing programmers from manual memory management. To some extent, Boost does the same for standard C++, but few novices would claim that they are equivalent, as Boost is text-mode only and relies on manual integration. (Though the explicit use of design patterns is often a sign of insufficient expressibility of the core language calculus, the fact that Eclipse can add design patterns to programs in several languages at the mere click of a mouse button without requiring novices to know the name of the pattern gives a clue as to its power over Boost or other text-mode packages.)
There are two important points remaining about the power of a language. The first is that making power available does not make it usable. For example, the Lisp family of languages allow programmers to redefine the language in terms of itself. However, the lack of syntax for most Lisp variants (excluding the excellent Dylan) makes this exceedingly difficult for novices to accomplish. Imagine if you could not tell where a sentence began or ended. Natural languages have punctuation marks and spacing and capitalization rules for good reasons. Likewise classical poetry mandates fixed meter and rhyme schemes as condign infrastructural delimiters and semantic cues.
Of course (second point), a language that requires users to extend it to be productive has already failed, unless it can enforce that there is one obvious solution to any problem and autonomously subsume the first working solution into the core language or library. Python is a good example of this practice. There is a strong polycultural subcommunity in the world of free and open source, and the members of this group consider the lack of competing projects in Python (one XML parser, one logging library, one networking toolkit) to be counterintuitive and even counter to the goal of language progress. They’re wrong; this is actually a strong force for cohesion in the language and community, where the correct answer to a novice’s question of “How can I parse XML?”, “How can I publish a database-driven web site?”, or even “How can I integrate the legacy system of an acquired company from a different industry with our existing legacy system?” (to prove that this principle does not only apply to small or toy problems) is usually “Someone else has already implemented the correct solution to that problem — it is part of the standard library.”
This does not necessarily imply that all programs written in the language must be open source or free software. It only implies that they must be reusable and extensible by the community — without enforcing any sort of redistribution practices.