I’m extremely pleased to see how many of you persevered through the long Code Reads drought and returned for the Backus discussion. Thank you all for sticking around. I am learning a lot from the comments, and you’ve renewed my determination to get Code Reads back on a reasonable schedule.
For the next installment, I’m going to suggest that we read (or re-read!) Guy Steele’s paper, “Growing a Language.” It’s a famous piece of writing that I skimmed ages ago but always wanted to take a closer look at. It is also, I think, considerably more accessible than the Backus. Here’s a PDF link to the Steele paper. And here’s an interview with Steele from Sun.
Post Revisions:
There are no revisions for this post.
Hmm, I wonder what a language would look like if if/for/while/etc could be defined as functions taking (in the case of if) a boolean and a block/closure. Would that help to grow a language at all?
Love the Code Reads, by the way.
Daniel, I might be misunderstanding you (haven’t looked at the Steele paper yet, so there’s a good chance of that), but I think Lisp (explicitly) and most functional languages (through sugared constructs) define control-flow structures this way.
I think this search for the Holy Grail of programming languages is funny. Before, it was about features. That was no good, so now it’s about patterns. I could link several sites that explain far better than I can the problems with patterns. In short, people can use patterns, but most do not understand how or why you should create one.
In any case, the search goes on and that’s good to see. However, for a field that is forced to be precise, the definitions used are rather ad-hoc. When the author says that it adds to the vocabulary, whose vocabulary is that? It’s not ours. It’s not other programmers. It isn’t the language’s vocabulary. There is no learning of new vocabulary at all. That’s the most troubling part that language designers do not understand. Once a program terminates, anything that software used to understand is gone and cannot be used by other software. If something has to be relearned every single time, then it’s NOT vocabulary.
So if someone learns a vocabulary, it means you no longer need to define it to any amount of detail when you communicate with that someone. In our case, that someone should be the computer. NOT THE LANGUAGE. Getting away from the language is something that is not possible in the commercial world for obvious reasons.
Real vocabulary would be as if I used, say, a certain compression algorithm. Instead of writing my own or using a library, the computer itself should know how to do it. The computer should have this vocabulary. This is a radical departure from the current way we write software and I’ve yet to see anything remotely close to it.
Daniel, indeed, most or all “functional programming languages” allow you to define functions that can be used instead of if / while / cond / etc.
An example in Haskell, where the lazy evaluation allows you to do:
myownif test block_else block_then =
if test then
block_then
else
block_else
main = do
let x = 3
myownif (x == 0) (print “Not zero”) (print “Zero”)
What Lisp and its friends bring you is that these functions are indistinguishable from the “normal” ones, even in their syntax.
I thought this paper was a remarkable rhetorical achievement without much substance WRT its purported topic. Compared to say, the Backus paper it had few specifics. The starting point — drawing parallels between natural languages and computer languages is, erm, a disputed tactic.
Larry Wall thinks the two phenomena are so strongly related that principles derived from the study of natural languages should guide the design of computer languages, as they did guide his design of Perl. Others, myself included, fail to see any evidence for this line of thinking.
I surely believe that extensibility and scalability isn’t the property of good written architectural design or program only, but also the language itself. It seams like every possible computer related artifact must be “extensible and scalable”. It is the mandatory characteristic of good design. Language, hardware, programs – everything.
It was pointed out by Alan Kay in his OOPSLA speach (http://video.google.com/videoplay?docid=-2950949730059754521), that when you design things you “must play grand”. When you design language you play it “grand” also . Which certainly means easy extensibility of the language in the future.
It could look like a lot of things, but one thing it might look like is Smalltalk. And, if it looked like Smalltalk, it would help grow the language (as long as you weren’t syntactically fixated), but control-as-function would be a small part of what helps the language grow.