or learn more

The German School of Lisp

May 3, 2011

The German school of Lisp is described by Kazimir Majorinc as a Spartan movement1 in Lisp implementation. But let me be clear, the Lisps in question are not toys like the one’s littering the Lisp landscape (including my own). Likewise, these Lisps are not libraries nor are they full-blown development ecosystems.

Let’s explore these distinctions for just a moment to clarify my meaning.


This post deals with that crimson space between, but first…


Exo-Lisps are the variants that exist to serve very pointed use cases. They can take the form of highly specialized libraries or embeddables like GLOS or Lush. Likewise, Exo-Lisps may facilitate embedding within applications or act as extension frameworks like Guile, Visual Lisp, Elk, and Emacs Lisp. Finally, Exo-Lisps like LFE and Liskell serve as skins over the semantics of another language.

Practical Lisps

Practicality is a relative term. Having said that, there are clearly a set of Lisps that exist primarily to solve “real world” problems, including: Common Lisp, Clojure, Scheme (R5RS, R6RS, R7RS-big), Racket, Chicken Scheme, and Dylan. I’m tempting libel cases by including this particular category and filling it with these particular choices, but so be it.

Kernel Lisps

I struggled to find a way of separating Exo-Lisps and Kernel Lisps and the following distinction from this struggle arose. Where Exo-Lisps serve as a framework for a specific problem, Kernel Lisps serve as a framework for a more general problem — language development and experimentation. Perhaps I’m splitting hairs. Some examples of Kernel Lisps include: R7RS-small, Scheme48, Lisp Machine Lisp, EuLisp, and Kawa.

Pedagogical Lisps

As I alluded to earlier, the Lisp landscape is rife with toys, Ur-Lisps, and half implementations. However, the vast majority of these Lisps exist for pedagogical pursuits and are rarely (if ever) overtly practical2.

Fluchtpunkt Lisps

Fluchtpunkt Lisps skirt the vanishing point between theory, practicality, and art. These implementations are all of the other categories in some way, while simultaneously being none in particular. They may or may not be general purpose languages in all instances, but they are all driven by a fervent ideal.

Below is a list of Fluchtpunkt Lisp implementations that I’ve found, and some discussion of their driving ideal (as I understand):


T is my favorite Scheme variant and the inspiration for many a Lisp thereafter. I’ve poured over Stephen Slade’s T book numerous times, finding something mind blowing each time. The primary driving force behind T was to prove that a Scheme could be made to run extremely fast, and fast it ran. T’s compiler technology was the motivation for numerous dissertations, and remains influential in many ways, even if some of its compilation techniques have fallen out of fashion.


Qi (and its successor Shen) really push the limits of what we might call a Fluchtpunkt Lisp. I suspect it requires a categorization of its own.

A few years ago I was looking for a Lisp to dive into and my searching uncovered two extremely interesting options: Clojure and Qi. I eventually went with Clojure, but in the intervening time I’ve managed to spend quality time with Qi and I love what I’ve seen so far. Qi’s confluence of features, including an optional type system (actually, its type system might be more accurately classified as “skinnable”), pattern matching,3 and an embedded logic engine based on Prolog, make it a very compelling choice indeed.


newLISP raised some ire at one point or another because of its design choices, specifically its choice of pervasive dynamic scope and fexprs (pdf).4 I like dynamic scope under some circumstances, but I can’t say that I’ve followed it to its logical end for any application of significant size or complexity. The advocates of newLISP are interesting folk and in many ways of my own mind. For example, how would one calculate Pi out to n digits in newLISP?

(define (pi n)
 (replace "\\" (join (exec 
   (format "echo 'scale=%d; 4 * a(1)' | bc -ql" n))) 

(pi 30) 
;=> "3.1415926535897932384626433832795028841968"

Why you would call out to the UNIX bc command of course. Why would you need your programming language to provide that type of calculation5 when there are more appropriate tools for doing so? I suppose the fundamental philosophy of newLISP is to not necessarily provide everything, but to make everything possible. newLISP facilitates possibility by treating the use of eval as a first-class approach and utterly idiomatic.


I agonized over including Paul Graham’s Arc in the category of Fluchtpunkt Lisp, but I think this is the correct place for it. The driving forces behind Arc are succinctness and centenarianism — both of which are certainly emblematic of the Fluchtpunkt ideal. Arc hasn’t taken off as much as non-Paul-Graham humans would have liked, but I believe that the root of the problem is that they prayed for Practical, but instead got Fluchtpunkt.

Pico Lisp

I first came across Pico Lisp when reading the paper “Pico Lisp: A Radical Approach to Application Development” by Alexander Burger and was instantly fascinated. The primary goal is to provide an idealized Lisp interpreter that runs as fast as possible. To accomplish this goal Pico Lisp limits its feature set and optimizes the code path along the dimensions of its features. The core types provided by Pico Lisp are numbers, symbols, and lists. Given the paucity of these types Pico Lisp has the advantage of always taking the most direct interpretation path and thus avoiding any unnecessary checks and abstractions that a more corpulent Lisp might require. For example, Pico Lisp’s quote function is defined in such a way that it returns all of its arguments unevaluated allowing the operation of quote to optimize into only a return of its cdr rather than the car of its cdr. Simple no?

Pico Lisp is, in my opinion, the most interesting entry in a family of really really small Lisps that also includes Nanolisp and femtoLisp, although I would hesitate to include these latter two in the Fluchtpunkt category.

Wasp Lisp

Wasp Lisp is a small Scheme inspired by Erlang with lightweight cooperative threads, communication via channels, and an implementation of MOSREF. This latter feature is fairly interesting in that it allows one to create a network of “drone” Wasp VMs that can receive secure snippets of code from a remote console for execution.

What is Fluchtpunkt?

Fluchtpunkt Lisps are…

  1. Focused: Uncompromising in their vision
  2. Spartan: Devoid of the seemingly unnecessary comforts found in many modern languages
  3. Controversial: Not always by design, but often because of their design
  4. Fun


  1. I intentionally avoid the word “minimal” in this post. Spartan is Mr. Majorinc’s word, and I think it is more appropriate. 

  2. However, toy and Ur-Lisps are practical insomuch as the act of implementing them is good programming practice. 

  3. I miss pattern matching. clojure.core.match, wherefore art thou? 

  4. Regardless of the chances of bringing a libel suit on myself, I will say that fexprs are effectively runtime macros. 

  5. Well, you could also use (mul 4 (atan 1)) if you didn’t care about precision. :p 

16 Comments, Comment or Ping

  1. Perhaps a category of its own, or perhaps not, there are the “non-lisp to lisp translations”. That is, somebody takes existing non-Lisp language X, replaces its surface syntax with sexps, and then bolts on some kind of macro system. Examples off the top of my head: Lisp Flavored Erlang and Liskell (a Haskell to lisp translation).

  2. It is a pretty diagram, but I don’t think it means very much. Your four characteristics seem more orthogonal than not, and the assertion that there exists a middle outside of the sets of the other four things that a lisp may be is amusing. But yes, they are pleasant colors :)

  3. @wingo

    They are indeed orthogonal, except where they overlap.

  4. @iry

    Hi James, I listed those examples in the Exo-Lisp category, but perhaps a new bubble would be more appropriate.

  5. I love this kind of article!

    Lisp Machine Lisp was one big honkin’ Lisp though, so I see it as a practical Lisp.

  6. @fogus, sorry, missed them :-)

  7. @manuel

    Thanks for the information, I suppose my knowledge of LML is lacking. I know what I’ll be reading about tonight. :-)

  8. Very interesting. Trying PicoLisp now.

  9. Kelvin

    Note Shen is the successor, not predecessor, to Qi lisp.

    The author describes Qi/Shen as a kernel lisp. Qi lisp is common lisp only. The upcoming shen is a super portable qi. I think Shen will be ported to clojure one day. That will be fun!

  10. @Kelvin, Thanks for the additional info.

  11. For these many months I had in the back of my mind that I was rude in a blog comment here, above. I meant to apologize; so, sorry about that!

    By “orthogonal”, I don’t mean to say that an implementation may not have both qualities. I merely meant that the presence of one doesn’t imply the presence or absence of another.

  12. bug

    It seems by this taxonomy that Lisps in general reside at the Fluchtpunkt between other languages as well. As many have experienced, languages like C#, Java and Ruby that offer crippled versions of functionalism and macro-like abstractions started to lose much of their mystique when I learned how to write an interpreter in Scheme. By extension, can it be said that these centrist Lisps offer a better vantage point from which to study other Lisps?

  13. Tim Schafer

    Just stumbled on John Shutt’s Kernel programming language and thought it would be relevant here. There is a project to implement it: Also be sure to check out his thesis on Recursive Adaptive Grammars. Really cool stuff!

  14. Jo

    Picolisp one can cancel, although it COULD be a nicely system – but htere are som heavy problems: – At first because the concept of GUI by Browser: Its inconsistent and error-prone, because every browser has a different behavior and the picolisp comes easy into the strudels of filters, firewalls, closed ports and so on. Its not an picolisp-error, but a conceptional mistake: There is no smooth working, if the browsers producing inconsitent data and behavior – nightmare number 1.

    The next problem ist the gap between functional programming language and objectoriented database-concept: The old gap (object-oriented language versus relational datamodel) on a new level. Why?

    At third: The documentation of picolisp is a nightmare: Gaps, inconsistencies, not really a coherent informations-system for learning.

    At fourth: If you want to read from keyboard over stdin, there is no function for that, you have to go over /proc/self/fd/0 !

    If you want to get crazy, then picolisp ist the right way …

    Some good ideas, but “a little” inconsistent …


  15. Jo, what you write is all wrong.

    “every browser has a different behavior” is not true any longer, since at least a decade. PicoLisp GUI applications run on every browser, even on text browsers like w3m. In PilBox (generic Android App) they run in the WebView component.

    In PicoLisp there is no “gap between object-oriented language versus relational datamodel”. Did you even look at it? The PicoLisp database is an OO-DB.

    Where is the documentetion inconsistent?

    The statement about /proc/self/fd/0 for stdin is wrong. You read stdin (keyboard, redirected or whatever) the normal way.

    • Alex
  16. beneroth

    @Jo, you are spreading misinformation.

    Browser: – since HTML5 there aren’t huge inconsistencies in browser implementations any more, and this will further decrease as currently the single company Google is de facto writing the web standard specifications and nearly all browsers are based on Googles chromium (including Microsofts browser). – you talk about browsers and then about issues with firewalls and networking, which have nothing to do with browsers. – picolisp standard GUI web framework supports everything from mere text browsers to mobile devices. Most other frameworks do not support such a variety of clients. Most other frameworks are a huge pile of javascript…

    OOP & functional: What is the gap you are speaking about? I cannot identify this gap. In my view and experience (coming from a C++ OOP background), picolisp is a extremely practical and very elegant blend of OOP and functional programming.

    Granted, picolisp implements OOP in Alan Kay’s sense (polymorphism and messaging), not in the sense of encapsulation as insurmountable barrier (as in the enterprise programming world). And granted, picolisp does not follow a purists functional approach (no variables/data, total immutability) but a more practical one (built-in functions can work in a immutable or mutable way).

    Documentation: I agree, as of now it’s a bit of a mess, as what is not contained in the language reference is spread out and incomplete. But it’s nowhere inconsistent (contradictory)! The language reference documentation fully covers the language plus documents all the core functionalities. It is dense, which needs proper reading. Not much beginner hand-holding, true – but then, picolisp is made for programmers who want to be able to fully understand (grok) and control their software, so people who want much hand-holding are most likely anyway not a overly good fit.

    Important to know is, that most of picolisp built-ins are written in picolisp too, and the source which isn’t, is thoroughly commented. And picolisp code is short. So one can always read the source – the one reliable source of truth in software.

    I recommend people to join the #picolisp IRC on freenode, there you get friendly and quick help.

    My experience: I read this article in 2013, and soon after came into picolisp. Since 2015 I use it in company software (other than most niche lisp, picolisp was always used for commercial software, has decades of being used in practical settings). The extreme succinctness and general flexibility of picolisp software gave me the best maintainability experience I ever had. And that is just the language – another big feat is the picolisp database, which is both simple and much more powerful than traditional relational databases, being a blend of relational, object and graph-database architecture.

    I might be a bit crazy, but not insane. The biggest drawback with picolisp is that it makes you experience the insanity of mainstream tech stacks (which are a result of perverse incentives).

Reply to “The German School of Lisp”