Of syllables and syllabi

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.