Programming languages have always been a topic close to the heart of developers. Heated debates, even quasi-religious (flame) wars, have raged over which language is ‘better’. There are arguments a plenty, for example, on which language to use for teaching computer science. How many languages should a ‘good’ developer know, and which ones, are other difficult issues.
The learning of natural languages does not generate such debates, but it still raises some issues. Obviously, kids learn the language of the country in which they live. But what should be the rule when one or both parents are foreign? Should the local language be the only one spoken? Should parents speak to their kids only in their own mother tongue and, if so, what language should the parents use between themselves? And what criterion should be used to select the foreign languages taught at school; other European languages because the countries are close by? Chinese or Spanish or Russian because they're spoken by so many people in the world? Japanese because it might make sense for future business opportunities?
There are several important differences between programming and natural languages. The latter have evolved over long periods of time and their foremost goal is to facilitate communication between humans. Trying to create a natural language from scratch, as with Esperanto, has resulted in failure. Programming languages, designed to communicate with machines, have a history of, at most, fifty years. A lot of code has been written in most of these languages but can that, of itself, be considered something of a success? Especially when you consider that most of the code can no longer even be read. There's a rumour that the data of the first space missions is no longer accessible, but we can still read old parchments. Another difference is that programming languages tend to be learnt when older. (Alex Telford has covered some other difficulties with languages in his EXE article in July 1999, Self-selection of the species?.)
Based on the short history of programming languages and what can be drawn from the history of natural languages, there's a strong argument for languages to be able to grow over time. This means that languages should allow for user-extensions, such as new vocabulary and new rules, to be added in a way that makes them indistinguishable from the primitives implemented by the language's creators. Guy L. Steele Jr. wrote a quite funny and convincing paper on how this applies to Java (Growing a language, http://research.sun.com/research/jtech/pubs/98-oopsla-growing.ps or http://www.brics.dk/~hosc/local/HOSC-12-3-pp221-236.pdf).
The reasoning is that to express all the needs that all the developers may have today, a small language is no longer adequate. On the other hand learning a large language can take a very long time. Ideally, the core should be relatively small but there should be a mechanism for extension via some form of libraries that should be accessible in a transparent manner, as if the concepts implemented were in the core. (One trend among language specialists I have noticed at recent conferences, which was very clear at the JaCC conference in April, is a change of focus from the direct comparisons of language features to the comparisons of idioms. The discussion has moved to a meta-level.)
This brings me to the central issue of how to teach programming and the importance of the choice of language(s) for this task. For instance, the very simple concept of recursion is trivial to explain in Lisp (it was very well taught to me at University). Once this concept is understood, iteration is viewed as a simple case of tail recursion. If you start with Basic (as I did before University) then the language forces you to have a very iterative view of all algorithms. To shoehorn these algorithms into languages such as Basic or Pascal adds unnecessary complexity. What should be taught are the basic concepts and idioms not the limitations of one language.
Up until now, humans have always had to adapt to computers. If all the work done on information appliances, wireless information devices, or whatever you want to call them, manages to increase computer penetration several fold, both languages and the teaching of them will have to change pretty soon. The need for complex system software will always be there but ‘users’ will increasingly want to customise their own devices. For this they will need to understand how the whole software works, to at least some degree. Programming will have to be much more forgiving. Also software upgrades will have to get better at preserving user enhancements.
It would help if there was some common ground of discussion for both experts and novices. One way could be a language that is simple enough to learn (for novices) but expressive enough (for experts), providing a common communication medium. Guido van Rossum has written a funding proposal along these lines using Python as a starting base (www.python.org/doc/essays/cp4e.html). His proposal is targeted at teaching programming to non-Computer Science undergraduates. As Rossum points out, more work needs to be done, not only on the language but also on the development environment, and on program analysis, comprehension, and visualisation.
Computer languages have flourished in the past fifty years. Many different paths have been explored. With the likely forthcoming dramatic increase in the number of people using programmable devices (can we even call all of them computers?), it is time to devise programming languages better suited to humans and good teaching programmes.
David Mery
P.S. A related point on which we should focus is program understanding. Not to reinvent the wheel every time, we should have tools that allow us to understand quickly and easily how what a piece of code does and how it works. A decade or so ago I saw a fascinating presentation by Henry Lieberman about his work on reversible interpreters where you could go forward (as in any debugger) but also backward in time. (This seems to have evolved in ZStep, more can be found at http://web.media.mit.edu/~lieber/Lieberary/Lieberary.html). To have a generalised undo/redo pattern applicable at all level of interactions when programming would be a huge step.
(C)1999, Centaur Communications Ltd. Reproduced with the kind permission of EXE Magazine.