etfb

jeff_duntemann commented "Lisp ties my head in knots", so I thought I'd help him out. The Aha! moment for me with Lisp came from seeing the association with Abstract Syntax Trees, which are a language compiler's internal representation of a line of code. Consider, for example, the quadratic equation, which can be expressed in Pascal syntax as (-b + sqrt(b*b - 4*a*c))/(2*a), where sqrt() is the square root function and * is the multiplication operator. (Note that this deliberately misses out the plus-or-minus part; I'll get to that later.) If you feed this into a compiler, what you get looks a bit like my illustration at right: a tree of operations, rearranged so that each operator has its operands as branches. If you were to convert an AST like this into text, using parentheses to show the tree structure, it would look like this:

(÷ (± (- 0 b) (√ (- (× b b) (× 4 a c)))) (× 2 a))

Lisp is, in essence, the textual form. The syntax is different - it doesn't use × and ÷ because it started in the 1950s with typewriter terminals, just like Fortran, but the differences are trivial. It takes some concentration to see how we get from the diagram to the Lisp form, but it makes sense. And once you have that sorted out, whole new vistas open up.

One significant step is the idea that you can define functions that operate on code as if it were data. I could write a function called expand-plus-minus, for example, that took a list like the above and turned it into two lists, one with a plus in place of the ±, and the other with a minus. Thus, without knowing anything about the quadratic equation, my function can create two new pieces of code. Compiling and interpreting blur into irrelevance, and it becomes a genuinely powerful tool.

That's really the key to Lisp. It's what makes the Lots of Irritating Superfluous Parentheses necessary and valuable, rather than irritating. Any time anyone refers to Lisp as like oatmeal with fingernail clippings, or asks me "how can you read it with all those parentheses?", I have to agree with whoever it was who replied by opening up a book, pointing to a page and asking, "How can you read the words in among all those spaces?"

I've been doing a lot of Lisp at work lately, and finding myself frustrated with SLIME, the Superior Lisp Interaction Mode for Emacs, which is the standard way of editing Lisp programs. It's nothing major - just some irritations here and there with how some of the commands work. For example: if you have a function named FOO and you want to find out where it's used, you use C-c C-w C-c (slime-who-calls). This opens a window with a list of the functions that use FOO, and pressing Enter on any of the entries on the list opens the associated file and highlights the right line. But to actually edit the line, you have to press C-x o (other-window). This is not What The User Expects (for certain values of User, ie me). So every time I do it, I find myself stuck in a window I don't want. And when I compile and get errors, I get a highly detailed and cryptic display of the complete stack trace, but no indication of the line and file that caused the error. And so on. It's all minor, but over a day of programming, especially in an office full of interruptions and distractions, it adds up.

I think the answer is obvious: it's time I rewrote some of the underlying commands and adjusted my Emacs to suit me.

(What -- did you think I was going to give up and use Visual Studio or something? Bah! Emacs means never having to say you're annoyed... for very long.)

I've been programming in Lisp recently, and hanging out on the #lisp IRC channel to ask stupid n00b questions and get advice. The latter is the ideal way to learn, if you don't push it; there are a lot of experienced people on there, as well as other neophytes, and they don't mind intelligent questions. Whether mine have been generally intelligent is left as an exercise for the reader. I should probably troll through the archives of comp.lang.lisp as well, provided I can avoid the complete arseheads who hang out there.

( Read on for ramblings and wishlists, of no interest to non-Lispniks I expect )

I've begun trying to teach the Elder Daughter of DOOOM some programming again. I toyed with the idea of teaching her Python, but in fact she really liked the Common Lisp I was showing her last year, so we've stuck with that. We're going a little faster now though, since I think she was getting bored. Here's what we did tonight:

(defvar family-tree 
  '(pa nanny ((bat beloved (edod batpup boywonder)) 
	      (bigweebro mrsbigweebro (cutie1 cutie2)) 
	      weeweebro)))

This is the family tree of her Nanny and Pa and their three offspring. Big Wee Bro has a lovely wife, Mrs Big Wee Bro, and two lovely daughters. Wee Wee Bro has a tendency to hang around with wee slips of gels, but hasn't managed to convince any of them to assist in the overpopulation of the planet, so he gets an entry all by himself.

(defun father (tree) 
  (car tree))

(defun mother (tree) 
  (cadr tree))

(defun children (tree)
  (caddr tree))

These are the EDoD's first-ever functions: given a family tree, they return the name of the father, the name of the mother and the list of names of the children.

So: (children family-tree) gives you ((BAT BELOVED (EDOD BATPUP BOYWONDER)) (BIGWEEBRO MRSBIGWEEBRO (CUTIE1 CUTIE2)) WEEWEEBRO), which is what you expect (it converts to uppercase for Hysterical Raisons; don't worry about it).

The bulk of the lesson was then in how to extract multiple pieces of information using these functions, and glue them together. I introduced her to list and append, which along with the already-familiar car and cdr and the much less useful cons are pretty much the primary toolbox for list manipulation, old-school style. Step-by-step, we wrote this:

(defun describe-family (tree) 
  (append (list (father tree) 'and (mother tree) 'love) (children tree)))

Result of application on the list of our family: (BAT AND BELOVED LOVE EDOD BATPUP BOYWONDER). Which is (a) true, and (b) not bad for half an hour of leisurely programming.

Next time we'll try something different: a function to print out her times tables. After that, we might revisit the family tree and see about a bit better formatting, so we can get something like "BAT AND BELOVED LOVE EDOD, BATPUP AND BOYWONDER". The insanely powerful format function will get a couple of lessons all to itself, methinks.

Teh Intartubes are abuzz with the news that Paul Graham, Lisp guru and one of the first dot com millionaires, has released a first draft of his loooooong awaited programming language, Arc. Initial response has been muted, almost entirely due to one statement he made:

... incidentally, Arc only supports Ascii. ... I realize that supporting only Ascii is uninternational to a point that's almost offensive, like calling Beijing Peking, or Roma Rome (hmm, wait a minute). But the kind of people who would be offended by that wouldn't like Arc anyway.

At first glance, this sounds like a breathtakingly obtuse statement: "nobody uses accented letters except total crackpots and French people and the like, and they're not important".  But I think things settled down a bit when he clarified: what he meant was that this is a work in progress, and it's got some gaps in it.  You can still use it to do a subset of the useful things you'd want a programming language for, but if you're looking for the be-all and end-all right now, then Arc isn't there yet.  So "the kind of people who would be offended by that" are the kind of people who like to have the finished product, all shiny metal and flashing lights like the Enterprise, not exposed plumbing and rusty bulkheads like Serenity or the Galactica.

Me, I like the exposed plumbing.  I've already downloaded the installer and started playing around with Arc.  I agree that it definitely solves some issues with Common Lisp and Scheme.  But it has its own issues too.  There's a long-standing argument about the virtues of what are called Lisp-1 and Lisp-2 implementations of Lisp, for example, and PG surprised me by picking the more Scheme-like Lisp-1 style instead of the Common Lisp Lisp-2 style that he'd be more familiar with.  But I can see how spending any time with one extreme, as he no doubt did when he was making his millions using Common Lisp, could make you long for the opposite side, and sadly in this case there's no middle ground because it's such a fundamental point.  But generally, the choices he's made in Arc make sense, and I can see a lot of benefit in following developments closely and not just discarding it all because version 0.1 isn't perfect.

But will there ever be anything in Arc (or any other Lisp) to compare with the ease-of-use of Delphi's Rapid Application Development?  Magic Eight Ball says: not a fracking chance in hell.  Which is a shame, really, because Lisp would be perfect if there were.