Humble Lisp programmers

Maybe from the headline you were expecting a blank post? No, that’s not where I’m going.

Yesterday I was on and noticed that nearly all the books they recommended for me were either about Lisp or mountain climbing. I thought this was odd, and mentioned it on Twitter. Carl Vogel had a witty reply: “I guess they weren’t sure whether you want to figuratively or literally look down on everyone.”

The stereotype Lisp programmer does look down on everyone. But this is based on a tiny, and perhaps unrepresentative, sample of people writing about Lisp compared to the much larger number of people who are writing in Lisp.

Lisp has been around for over 50 years and shows no signs of going away. There are a lot of people writing Lisp in obscurity. Kate Gregory said something similar about C++ developers, calling them the dark matter of programmers because there are lot of them but they don’t make much of a splash. They’re quietly doing their job, not speaking at conferences or writing much about their language.

I imagine there are a lot of humble Lisp programmers. It takes some humility to commit to an older technology, especially given the pervasive neomania of the programmer community. It also takes some humility to work on projects that have been around for years or that are deep within the infrastructure of more visible projects, which is where I expect a lot of Lisp lives.

You can do very clever things in Lisp, but you don’t have to. As Ed Post famously said, “The determined Real Programmer can write FORTRAN programs in any language.” There must be a lot of code out there that writes (f x) instead of f(x) but otherwise isn’t that different from FORTRAN.

5 thoughts on “Humble Lisp programmers

  1. My first programming job was on an automated medical diagnosis system written in lisp, and yes, an awful lot of the core diagnosis engine looked very much like Fortran, complete with Fortran style variable names and lots of procedural code full of setq. It is true that one can write Fortran in any language.

  2. You just note, that our impression oft Lisp is heavily influenced by scheme, and lately clojure. Common lisp is by today’s standards a multiparafigm language and sometimes not more functional than, lets say python (although you can write functional code in it). The predecessors of CL were even closer to the machine. And if one thinks about the origin of `car` and `cdr`: content of address register and content of decrement register.

    Your grandfathers lisp couldn’t be that far away from FORTRAN.

    Also modern FORTRAN is much more high level than back then.

  3. Autocad still uses Lisp as one of its macro languages. There’s a good chunk of users right there.

  4. I tend to prefer programming languages based on their industrial utility, rather than other criteria such as elegance or expressiveness or “power”.

    Simply put, too many languages are “write-only”, meaning they make it is all too easy to write code that can be difficult to understand months or years later. I put Lisp and Perl 4 solidly in the “write-only” category, having seen (and written) far too much incomprehensible and unmaintainable code in those languages.

    Sure, it is possible to write spaghetti in any language, but it seems to me that the more “industrial” languages actively discourage it.

    Avoiding “write-only” characteristics requires a very disciplined programming approach. For Lisp and Perl, I mandate full Literate Programming even for short “throw-away” and utility programs.

    For R&D programming, I like to prototype in one language (most often Python) and do final implementation in another (most often C/C++). I’ve found it to often be wiser to completely isolate the final product from the initial efforts (and false trails). Trying to evolve a barely working prototype into a deliverable industrial solution is often best accomplished by treating the initial work as a learning process, and the final work as an engineering process.

    I think it was Don Knuth who said something like: “Programming is how we explain to other humans what it is we want the computer to do.” It is important to keep this in mind for all programming, even if the only ones to ever read it are our future selves.

    And, yes, I can still easily comprehend the FORTRAN IV programs I wrote 45 years ago, and the Pascal programs I wrote 35 years ago. My Lisp and Perl programs do not fare nearly as well.

    My assembly programs are still very readable, mainly because I was paranoid about forgetting all the low-level peripheral and instruction set features I had worked hard to understand and use well, and had a documentation-to-code ratio of at least 10x.

    Still, I never “outlaw” any language, especially for prototyping. Sometimes an algorithm or its implementation will “flow” more naturally in one language over others. Understanding the problem is the most important goal of R&D, and tool selection is an important facet of R&D. But delivering a maintainable product presents a different set of goals, for which the tools of research may not be appropriate.

    Still, it can be fun to push languages into new domains, and more than once I have pushed Python to do real-time sensing, analysis and control on deeply embedded single-chip ARM systems (it is so nice not to be hammering on 8-bit AVR or PIC processors for this work).

    Which reminds me of a truism I call ‘Bob’s Law’: “In any industrial system containing software, the hardware is free.” The cost of software continues to increase as the cost of hardware continues to decrease: Improving the hardware to better support and simplify the software ALWAYS pays off. So instead of running on “bare metal” or a minimal RTOS, I now typically run a stripped-down Linux with the RT kernel patches.

    Life is good.

  5. A language cannot survive without ecosystem – standard library, package manager, language interop and IO, IDE, toolkits for GUI, visualization, readers and writers. Hence this drives adoption! But outside of emacs and Maxima, where is Lisp?

Leave a Reply

Your email address will not be published. Required fields are marked *