Yes, there are a lot of independent consultants working in Common Lisp. There is some information about jobs in my survey paper at http://common-lisp.net/~dlw/LispSurvey.html. You might also get in touch with the people at Clozure, at http://www.clozure.com, who do a lot of Common Lisp consulting work and often bring together consultants and clients who need consultants.

I’ve been following your blog since the beginning, and really look forward to every new post …

I’ve been learning Lisp / Scheme over the last three years …

So far, I’ve worked my way through the following books :

- Structure and Interpretation of Computer Programs
- ANSI common Lisp
- Paradigms of AI Programming (In process)
- LISP in small Pieces
- Essentials of Programming Languages (In Process)

I really enjoy reading Lisp / Scheme code. The style of code that Lisp allows is truely unique and completely different from what Ive ever seen before. I’m a programmer for 10+ years now, and I’ve mostly written and read code in C, C++ and Java.

I write this mail to ask you a few specific questions:

- I like learning about a language by reading code written in it. I’ve done this for C, C++ and Java. (There’s no shortage of code in these languages). For Lisp, what would you suggest someone to read ? to understand the common idioms, good style, effective use ?

- Work : I’ve been working in the consulting industry since the beginning of my career. Its been over 10 years now. I’ve been thinking … Is it possible to work as an independent consultant working on Lisp ?

- Any other suggestions on how I can sharpen my skills on Lisp programming / AI ?

I hope to hear from you soon.

Regards,

Vinay

David Moon: I believe that the problem here lies in the differences between Zetalisp and X3J13 Common Lisp. In the latter, which is what I was talking about (and I should have made that clearer — sorry!), there really isn’t any semantic distinction between the classes error, serious-condition, and condition. They are useful only as conventions/mnemonics for people who think that you can say something about whether a particular condition class is, in and of itself, an “error”. That, of course, depends on what you mean by “error”, a word that I have intentionally avoided.

There are some conditions that, for all practical purposes, always indicate a bug, such as trying to compute the car of an array. While it is remotely conceivable that a program might do that on purpose, including in its contract the condition that that would signal, it would almost certainly be poor programming style. However, in my opinion, indexing off the end of an array is not, per se, a bug. You can write a linear search that’s slightly faster by letting Lisp itself check for the “I’ve reached the end of the array” circumstance, rather than coding it yourself.

(Note: if the array is easy to modify, a better trick is to store a copy of the desired value at the end of the array, so that you’re guaranteed to find it, and then you can omit the length check. But in many cases that’s not possible, and it’s not thread safe, and so on. But I digress.)

What you’re definitely right about is that I have not yet considered Lisp’s ability do do “handler-bind”, which is very important. I’ll talk about that in a future post. “signal” can also be interesting, but I don’t think I’ve ever actually used it.

You are right about the contract of +. Thanks for the correction.

The HyperSpec is annoyingly unspecific sometimes about unusual behaviors. Just recently I was asked whether the :junk-allowed t option of parse-integer means that if you give parse-integer a string, it should return nil rather than signaling. The spec is not clear on that, although it tends to suggest that it should signal, which is what I would choose if I were the spec writer. But I wish these things were spelled out more clearly; and it would be even nicer if it specified exactly what condition class were signaled in such cases.

If we ever get to define a new Lisp, and we have enough time and resources to do all this (X3J13 did not), and we don’t have to subject ourselves to a design-by-huge-committee process (such as X3 requires), I hope we’d get this all right. Java’s standard does much better job in this respect. But writing good standards is very difficult and time-consuming. I helped a with the Java spec and it was clear that Guy Steele and Bill Joy worked very long and hard on it. They also had the advantage of having Guy Steele, a great writer, and particularly a clear and deep thinker when it comes to programming languages.

If you are forced to code in a language or operating environment in which the implementation of conditions/exceptions is very slow, then, of course, you have good reason to avoid using them in any performance-critical area.

Most software obeys the old 80/20 rule, or even 90/10 or 95/5: 5% of the code occupies 95% of the execution time. In such a situation, you’d have to go back to using error codes or special returned values or multiple values, rather than exceptions, to denote unusual outcomes, in that part of the code. With any luck, you can use exceptions in the rest of the code.

One of the things I was going to talk about in the future was performance, especially the different characteristics of Lisp vs. Java performance. But I thought I should run some benchmarks to make sure I know what I’m talking about. I think I know what I’ll find, but one thing I’ve learned over decades of software development is that benchmark results are very often surprising. Measure, don’t guess.

“With an exceptional condition, you cannot continue processing because you don’t have the information necessary to deal with the problem in the current context. All you can do is jump out of the current context and relegate that problem to a higher context. This is what happens when you throw an exception.”

Borland’s Delphi Pascal compiler had a well-established exception model, not unlike Java’s but without exception specifications for functions. When Borland ported its compiler from Windows to Linux (the Kylix compiler), it was found that Linux’s model of exception handling was very different from Windows. In particular it was about two orders of magnitude slower in execution.

When Windows programs were recompiled under Linux – and this included Borland’s own core Delphi libraries – they were unsurprisngly found to be much slower. At the time, the advice from Borland (or at least their then chief designer Danny Thorpe at a talk he gave) was that this indicated that programmers had been abusing the exception mechanism by using them for ‘non exceptional circumstances’. An exception (said Thorpe) should only be something that happens rarely; Borland felt entitled to incorporate this assumption into the design of its compiler. You, the Kylix customer, should recode where exceptions were frequently thrown, to avoid them.

Of course, Kylix has not been a very successful product… but I wondered what you thought of this point of view. It has certainly guided the way I have coded things ever since, and seems to be a fairly useful rule of thumb.