This is the tenth edition of Code Reads, a series of discussions of some of the central essays, documents and texts in the history of software. You can go straight to the comments and post something if you like. Here’s the full Code Reads archive.
You don’t have to read too far into Guy Steele’s “Growing a Language” to figure out what he’s up to. In this 1998 talk on the nature of programming-language design, Steele writes under a set of constraints: he may use any word of one syllable, but if he wishes to use longer words, he must define them first — using only words of one syllable.
Steele aimed to illustrate how awkward and confining it can be to try to express yourself when you don’t have access to an extensive vocabulary: “I wanted to show you want it is like to use a language that is much too small.” (By this point in the talk, he has already defined “language.”) His larger purpose is to advocate a philosophy of programming-language development that aims for neither a small nor a large language, but rather for one that is “designed to grow.”
Such growth is to be propelled not by a closed cadre of gurus but by the language’s users, who have been given an appropriate set of tools to extend the language. The shape of the language is such that these user-generated additions do not look or behave any differently from the “original” elements of the language provided by its initial creators. Nearly a decade later, this argument — which parallels similar ideas that have become popular in the open-source software community as well as in the “user-generated” enthusiasms of Web 2.0 — sounds neither arcane nor controversial.
Steele is a storied figure in the programming-language world: a Lisp luminary, co-creator of the Scheme language, and a key figure in the development of Java at Sun, where he is now working on a new programming language called Fortress (he talks about it in this interview). So he has a long perspective on the rise and fall of languages.
At the time of “Growing a Language,” he’d written the specification for Java, and wanted to see Java evolve in ways that would allow its users to extend it more easily. I don’t know enough about the subsequent history of Java to know whether Steele won that argument; Java has certainly achieved great success and wide adoption (though I’ve heard as many programmers curse it as praise it over the years).
But “Growing a Language” is worth reading regardless of the specific controversies that inspired it. With a playful spirit, the paper recursively embodies its themes and arguments. It’s a grand stunt that I, at least, found great fun to read.
Plainly, Steele started out intending to show just how painful the words-of-one-syllable limit is — and, by extension, how desperately programmers need the ability to expand the vocabularies of languages that feel impoverished (“a thought that seems like a primitive in our minds turns out not to be a primitive in a programming language, and in each new program we must define it once more”). Yet what’s fascinating about “Growing a Language” is that the limits Steele imposed on his expression make the paper far more accessible, precise and clear than most computer-science writing.
Watching a writer play inside a set of rules, the way a poet might explore a particularly strict form, is part of the pleasure. (Here’s one funny sentence: “I have to say the full phrase ‘Java programming language,’ for there is a guy who works where I do who deals with the laws of marks of trade, and he tolf me I have to say it that way.”) But the rules also force a kind of elegant simplicity on the prose. Here, for instance, is as good a definition of “meta” as you’ll find anywhere: “Meta means that you step back from your own place. What you used to do is now what you see. What you were is now what you act on.”
Obviously, the virtue of simple language is hardly literary news; near the end of his paper, Steele acknowledges the familiar Strunk-and-White admonition to use short words. He notes that, when writing under his self-imposed limit, “I have found that this mode of speech makes it hard to hedge…you seem to have no choice but to talk straight.” Here he has landed on Orwell’s insight into the dangers of fuzzy writing composed of big, general words: either the speaker has nothing to say and is wasting our time, or, worse, he is trying to hide an atrocity or cover up a crime.
We may know these principles, but it’s still delightful to see them embodied in a text. When Steele writes the phrase “numbers whose points float,” on the one hand, he’s just finding a deft way to avoid having to define a more common polysyllabic term; on the other, he’s also causing us to stop and think about what the phrase actually means.
One of the functions of art is to make the familiar strange so that we can see the world with fresh eyes. “Growing a Language” accomplishes just such a transformation, in its own methodically monosyllabic way.
[tags]code reads, guy steele, growing a language, programming languages, java[/tags]
Post Revisions:
There are no revisions for this post.
The discussion on “Growing a Language” already started back here on the post announcing this reading. And on his blog, Andrew Sacamano offered his own notes and provided some more background on Java history.
I hadn’t encountered Steele’s paper before, so thank you for bringing it to my attention. It deserves to be more widely read outside the field of computer science – not for the content, but for the execution. It’s a great example of how you can meaningfully convey information without resorting to long strings of poly-syllabic words. Definitely one to add to the reading list of our environmental science students :-)
Some of the things Steele advocated did make it into Java, such as generic types. Others made it into C#, but not into Java yet.
I think it’s still an open question whether libraries should be allowed everything that can be done in the language itself. It’s useful to be able to reason about a program in which some terms are unfamiliar. Java does a much better job of this than most mainstream languages.
As I said in the earlier thread, I agree with Scott that the paper is a remarkable rhetorical achievment and brain candy of the highest order.
That said, as a working programmer what I tend to miss most in all the C-based languages I am familiar with is not new words but more flexibility and clarity in making higher level structures. We have, (speaking loosely):
– functions
– classes-qua-data-structure
– classes-qua-object (state-behavior bundles)
– class hierarchies
– “modules” / headers which group previous
– packages (i.e. abstracted file system directories) which group modules
– libraries which group packages
– some patterns for creating structure across those boundaries
When it comes to structuring medium and large works of software, we have no real equivalent to the many mature forms that written language can take: forms which constrain and clarify intention the way the research paper, the polemic, the survey-of-current-literature do for their writers and readers. We all know how to pick out the most important sentences and paragraphs from an unfamiliar piece of writing in moments; picking out the most important functions and modules from an unfamiliar piece of code is a treasure hunt. New operators and keywords — statement-level syntax — are useful for a small fraction of working programmers most of the time. Better ways to communicate program structure would be useful for all of us every day.
I read the article when it was first posted, but when I reached the end, I felt like I missed the punch line. I found the mono syllable excercise interesting, but I thought the point was to say that it was more difficult this way. Maybe for him, and some sentences did read strangely, but it was always clear. This goes hand in hand with the notion that when people have constraints to work around or with, you always get a better end result than if you could do anything you wished. At the end, I got the feeling that he trumped himself, but like I said, I didn’t get the punch line. Nice article though I thought it made a different point than the author intended. Still, I liked it and am happy it was brought to my attention.
Reading’s Sam’s comments reminds me of my reaction upon learning about design patterns. I immediately wanted a way to formalize the usage of these patterns, so that the larger structure of a program was explicit. I’m not sure such a thing is possible. Would the vocabulary of the larger structure soon become so large and cumbersome that it would create confusion instead of clarity, being the largest of the large languages? Or is is possible to find a set that is “good enough”?
There seems to be a standard process for many technological developments – first everyone does everything their own way, motivated by fulfilling exactly their own needs. As user communities develop, people begin finding ways to standardize, trading flexibility for simplicity until a balance is achieved. As times goes on, particularly around computers, more and more standardization is achieved. So maybe this is where programming languages can evolve – finding larger and larger abstractions which are “good enough”.
I posit that there are, at the bottom of any linear-sequential “language,” only three words: AND, NOT, and STORE. AND and NOT are in the space-domain as well, which further restricts the language. This is a poor vocabulary with which to write any significant program. It is the reason that software production for any dynamic controller is about 50% efficient, with half the time fixing that which was produced in the first half.
thank you Scott — I hadn’t seen this essay before.
i’ve just returned from a holiday during which i toyed a lot with the idea of putting out a book that collects remarkable (and classic and humorous) essays on programming.
it turns out your Code Reads series has covered many of the articles i’d like to get my permissive hands on.
nice work
lb
There is also a video lecture available of his talk.
I wrote about it here: Growing a Language by Guy Steele
Peter
The topic is still relevant, even after ~22 years. Thank you