Growing a Language

["Mark Meijer" <meijer78@...>]

Hi all,

Someone recently made an off-hand mention of Guy Steele, which has
indirectly lead me to discover the following ten-year-old talk:

http://video.google.nl/videoplay?docid=-8860158196198824415&ei=7iTOSOHzDo2wiAK0s9W1Ag

Why post this here? Well, not just because it's quite interesting as
well as funny. Although the talk is ultimately about the state and
direction of Java one decade ago, most of the talk is a very general
and still relevant one, about designing programming languages.


* Steele argues that designing a small language has the advantage of
being easier to design, faster to finish a working implementation, and
easier to learn. But it has the disadvantage of requiring any
application written in it, to use those (small) set of features for
first building the larger vocabulary that is needed to express the
application in the language. Conversely, designing a large language
has the advantage of being more thorough and should require
application developers to write less boilerplate stuff to get started,
but has the disadvantage of being harder to design, implement, as well
as learn. Also its users will feel less connected to a language if
they feel they have no say at all as to what goes into it. What works
better, Steele continues, is to design a small language that is meant
to be grown into a larger one through user contributions. This may
seem obvious but I think it's still an insightful observation, worth
stopping to consider.

It probably goes without saying that this reminded me of Lua, being a
small language but providing (meta) facilities to "grow" it as needed.


* Steele further argues that there are two obvious ways for having a
language grow. One is to have someone (or a small group) in charge of
everything, which is good for safeguarding quality, orthogonality, etc
but can cause progress to be slow. The other is to have nobody in
charge, instead letting users do whatever they want with it, which can
speed up progress but lacks that quality control and makes it harder
to use different contributions peacefully together. Again, the best
option seems to be a third one in the middle, namely to have users do
what they want with the language, but have someone in charge of
judging the value and quality of other people's work, and mix/match
those contributions accordingly. Everybody remains free to use other
contributions, and nobody is obliged to use the provided selection at
all, but it's there for those who want quick and easy access to a
decent set of extensions that work well together.

This is in many ways analogous to what is being done for Lua
distributions, such as LfW. And in light of the discussions in our
recent essay week here on this list, I just thought this might be an
interesting view to point out.

(on a related note, it also could potentially be regarded as an
argument for having something like token filters :P)

Cheers