Peter Seibel - Coders at Work - Reflections on the craft of programming

The second reason I like Python is that—and maybe this is just the way my brain has changed over the years—I can’t keep as much stuff in my head as I used to. It’s more important for me to have stuff in front of my face. So the fact that in Smalltalk you effectively cannot put more than one method on the screen at a time drives me nuts. As far as I’m concerned the fact that I edit Python programs with Emacs is an advantage because I can see more than ten lines’ worth at a time.

I’ve talked with the few of my buddies that are still working at VisualWorks about open-sourcing the object engine, the just-in-time code generator, which, even though I wrote it, I still think is better than a lot of what’s out there. Gosh, here we have Smalltalk, which has this really great codegeneration machinery, which is now very mature—it’s about 20 years old and it’s extremely reliable. It’s a relatively simple, relatively retargetable, quite efficient just-in-time code generator that’s designed to work really well with non type-declared languages. On the other hand, here’s Python, which is this wonderful language with these wonderful libraries and a slow-as-mud implementation. Wouldn’t it be nice if we could bring the two together?

Seibel:Wasn’t that sort of the idea behind your pycore project, to reimplement Python in Smalltalk?

Deutsch:It was. I got it to the point where I realized it would be a lot more work than I thought to actually make it work. The mismatches between the Python object model and the Smalltalk object model were bad enough that there were things that could not be simply mapped one-for-one but had to be done through extra levels of method calls and this, that, and the other.

Even at that, Smalltalk with just-in-time code generation was, for code that was just written in Python, still in the same range as the C-coded interpreter. So the idea that I had in mind was that if it had been possible to open-source the Smalltalk code generator, taking that code generator and adapting it to work well with the Python object model and the Python data representation would not have been a huge deal.

But it can’t be done. Eliot Miranda, who’s probably the most radical of my buddies associated with VisualWorks, tried, and Cincom said, “Nope, it’s a strategic asset, we can’t open-source it.”

Seibel:Well, you’re the guy who says software should be treated as a capital asset.

Deutsch:But that doesn’t necessarily mean that it’s always your best strategy to prevent other people from using it.

Seibel:So in addition to being a Smalltalker from way back, you were also an early Lisp hacker. But you’re not using it any more either.

Deutsch:My PhD thesis was a 600-page Lisp program. I’m a very heavyduty Lisp hacker from PDP-1 Lisp, Alto Lisp, Byte Lisp, and Interlisp. The reason I don’t program in Lisp anymore: I can’t stand the syntax. It’s just a fact of life that syntax matters.

Language systems stand on a tripod. There’s the language, there’s the libraries, and there are the tools. And how successful a language is depends on a complex interaction between those three things. Python has a great language, great libraries, and hardly any tools.

Seibel:Where “tools” includes the actual implementation of the language?

Deutsch:Sure, let’s put them there. Lisp as a language has fabulous properties of flexibility but really poor user values in terms of its readability. I don’t know what the status is of Common Lisp libraries is these days, but I think syntax matters a lot.

Seibel:Some people love Lisp syntax and some can’t stand it. Why is that?

Deutsch:Well, I can’t speak for anyone else. But I can tell you why I don’t want to work with Lisp syntax anymore. There are two reasons. Number one, and I alluded to this earlier, is that the older I’ve gotten, the more important it is to me that the density of information per square inch in front of my face is high. The density of information per square inch in infix languages is higher than in Lisp.

Seibel:But almost all languages are, in fact, prefix, except for a small handful of arithmetic operators.

Deutsch:That’s not actually true. In Python, for example, it’s not true for list, tuple, and dictionary construction. That’s done with bracketing. String formatting is done infix.

Seibel:As it is in Common Lisp with FORMAT.

Deutsch:OK, right. But the things that aren’t done infix; the common ones, being loops and conditionals, are not prefix. They’re done by alternating keywords and what it is they apply to. In that respect they are actually more verbose than Lisp. But that brings me to the other half, the other reason why I like Python syntax better, which is that Lisp is lexically pretty monotonous.

Seibel:I think Larry Wall described it as a bowl of oatmeal with fingernail clippings in it.

Deutsch:Well, my description of Perl is something that looks like it came out of the wrong end of a dog. I think Larry Wall has a lot of nerve talking about language design—Perl is an abomination as a language. But let’s not go there.

If you look at a piece of Lisp code, in order to extract its meaning there are two things that you have to do that you don’t have to do in a language like Python.

First you have to filter out all those damn parentheses. It’s not intellectual work but your brain does understanding at multiple levels and I think the first thing it does is symbol recognition. So it’s going to recognize all those parenthesis symbols and then you have to filter them out at a higher level. So you’re making the brain symbol-recognition mechanism do extra work.

These days it may be that the arithmetic functions in Lisp are actually spelled with their common names, I mean, you write plus sign and multiply sign and so forth.

Seibel:Yes.

Deutsch:Alright, so the second thing I was going to say you have to do, you don’t actually have to do anymore, which is understanding those things using token recognition rather than symbol recognition, which also happens at a higher level in your brain.

Then there’s a third thing, which may seem like a small thing but I don’t think it is. Which is that in an infix world, every operator is next to both of its operands. In a prefix world it isn’t. You have to do more work to see the other operand. You know, these all sound like small things. But to me the biggest one is the density of information per square inch.

Seibel:But the fact that Lisp’s basic syntax, the lexical syntax, is pretty close to the abstract syntax tree of the program does permit the language to support macros. And macros allow you to create syntactic abstraction, which is the best way to compress what you’re looking at.

Deutsch:Yes, it is.

Seibel:In my Lisp book I wrote a chapter about parsing binary files, using ID3 tags in MP3 files as an example. And the nice thing about that is you can use this style of programming where you take the specification—in this case the ID3 spec—put parentheses around it, and then make that be the code you want.

Deutsch:Right.

Seibel:So my description of how to parse an ID3 header is essentially exactly as many tokens as the specification for an ID3 header.

Deutsch:Well, the interesting thing is I did almost exactly the same thing in Python. I had a situation where I had to parse really quite a complex file format. It was one of the more complex music file formats. So in Python I wrote a set of classes that provided both parsing and pretty printing.