Programming language design philosophy


Guido van Rossum has started a series of articles on the history of Python with the first post being on the Python design philosophy. Guido’s guiding principles read like design patterns… you know, pattern language style, before it was all implementation patterns and UML diagrams.

Most languages come from one person and their specific design patterns reflect heavily on the language forever. We can look at Larry on Perl as a post-modern language, Matsumoto on Ruby, Paul Graham on Arc, Richard Gabriel on Lisp, C and worse-is-better and of course, the Guy Steele ‘98 OOPSLA classic “Growing a Language (video).

Interestingly, most of the language creators still seem to enjoy their creations. Eich seems to be in a minority. Is JavaScript the only language where the creator openly derides it?

All designers have to be careful not to simply create a monument (statue, pyramid etc) to themselves. Taking a lesson from Dewey’s “Art as Experience” - that the value of art is in the experience for the user - the artistic value of a programming language is the value for the people programming in that language.

There’s (at least) two particular design difficulties with programming language design:

1. The extent to which the language designer influences the entire set of universes created with it
2. A programming language is an expert environment which makes is very difficult to figure out how it will be used...

Design by an amateur would be many times more disastrous in the case of a programming language. For good reason, language designers are typically both expert programmers and experts in compiler implementation. Even then, the whole affair seems to be fairly hit-and-miss even for people who’ve already designed great languages… by pure luck we seem to have gotten some languages created by people who were also talented language designers. Still, I think Alan Kay is right when he says in an interview in Queue that “nobody really knows how to design a good language, including me.”

Going back to JavaScript though, what of its design philosophy? (apart from the ones dictated by timelines) I’m paraphrasing from memory here but Eich essentially said source code sharing and simple powerful primitive mechanisms were ideas for JavaScript. I’m leaving out some really good (lambda and prototypal inheritance) and some bad (which I won’t bother hashing over) ideas because they don’t really feel like ideas behind JavaScript but more just things that happened to be there.

Powerful primitive mechanisms was also design goal for Lua. I don’t know if Lua’s success is due to that or simply, because like JavaScript, it seems quite familiar. Still, can we say for sure that powerful primitives is a worthy design goal for any programming language?

Over on LTU there’s a post asking if there are any resolved debates in programming language design. Nothing much has been resolved enough to be even considered resolved in that thread.

In some sense you could distil most programming languages down to some basic quiddity. Perl - post modern, smalltalk - message passing… Quiddity is probably a fitting word, I like both uses of the word quiddity for this because whilst we can say something about the fundamental nature of a particular programming language with such distillations, what we end up saying can, in effect, often be a trifle. That’s kinda where the LTU thread seemed to go.

Anyway…

I wonder if we could create a language based on some fundamental principles from semantic primitives?



CoffeeScript in Action


CoffeeScript in Action book cover

I'm the author. Get it from Manning.