The German School of Lisp
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
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
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/Shen
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
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.
Arc
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…
- Focused: Uncompromising in their vision
- Spartan: Devoid of the seemingly unnecessary comforts found in many modern languages
- Controversial: Not always by design, but often because of their design
- Fun
:F
-
I intentionally avoid the word “minimal” in this post. Spartan is Mr. Majorinc’s word, and I think it is more appropriate. ↩
-
However, toy and Ur-Lisps are practical insomuch as the act of implementing them is good programming practice. ↩
-
I miss pattern matching.
clojure.core.match
, wherefore art thou? ↩ -
Regardless of the chances of bringing a libel suit on myself, I will say that fexprs are effectively runtime macros. ↩
-
Well, you could also use
(mul 4 (atan 1))
if you didn’t care about precision. :p ↩
17 Comments, Comment or Ping
James Iry
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).
May 3rd, 2011
Andy Wingo
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 :)
May 3rd, 2011
fogus
@wingo
They are indeed orthogonal, except where they overlap.
May 3rd, 2011
fogus
@iry
Hi James, I listed those examples in the Exo-Lisp category, but perhaps a new bubble would be more appropriate.
May 3rd, 2011
Manuel Simoni
I love this kind of article!
Lisp Machine Lisp was one big honkin’ Lisp though, so I see it as a practical Lisp.
May 3rd, 2011
James Iry
@fogus, sorry, missed them :-)
May 3rd, 2011
fogus
@manuel
Thanks for the information, I suppose my knowledge of LML is lacking. I know what I’ll be reading about tonight. :-)
May 3rd, 2011
Ralph Moritz
Very interesting. Trying PicoLisp now.
May 4th, 2011
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!
May 7th, 2011
fogus
@Kelvin, Thanks for the additional info.
May 7th, 2011
Andy Wingo
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.
Feb 10th, 2012
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?
May 14th, 2012
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: http://klisp.org/ Also be sure to check out his thesis on Recursive Adaptive Grammars. Really cool stuff!
Oct 2nd, 2014
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 …
Jo
Nov 15th, 2017
Alexander Burger
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.
Apr 18th, 2019
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).
Apr 18th, 2019
Jo
Dear Alex, dear beneroth,
@Alex “Jo, what you write is all wrong.” – Youre the only one pil -person I forgive such a sentence …
@beneroth “@Jo, you are spreading misinformation.” That’s not correct! – Do you wish, I publish the evidences? It would not good for the future of pil! And this is not my goal! And please dont forget: Tey’re not the most rotten fruits, where sitting the wasps. ;-)
I believe, the discussion is useful for us all, so I want answer about your objections:
Nearly 1.5 years are a long time in IT and your answers maybe relate to a very different situation since 2017. There was “some” changes in the IT-sector since my statement, so maybe there are some misunderstandings … (so there’s a pil-wiki in between – thanks a lot! But – I believe – isn’t Alex german? – Why no reference in german language then? You don’t like your own folks, your own language, Alex? (Its not a personal question, but a strategic question for the use of pil! Maybe there will be a german fork in future … ;-) )
“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).”
Yeah, thats (lamentably) right. In light, today (2020) we have in reality only one single browser-architecture worldwide. :-(
But I wrote about really different(sic) browsers/browser-architectures (like it’s worthy in a real(!) free world and not in a browser-banana-republic, only still named “free”!) and not about only one single browser, which is pushed underneath the world of computer users with different names and some minor variantes, like beneroth very truly describes.
I meant in my statement real different(sic) browser-architectures. In 2017 they’re (partially!) still there – but in 2019 it’s difficult to find them already – but this was 2017 still not my topic! Is it fair, to compare apples with pears?
So the vital, strategic question (for using pil) of the way of pil is:
Will pil go in future the way of the (current) US-alone-controlled (naturally with help of estrange “auxillar-troops” – like the erectors of the first, ancient “capitol”(Rom, not Washington! Means: “Head of the world” – megalomania set in stone) – banana-republic of IT (like (only nearly!) all those others), or has pil a future of real(sic) worldwide freedom? (The US-peoples and their ideas are only a handful in comparison with the “rest” ;-) of the world! We should never forget that, if we develope code for the world!)
I believe, mathematics should always think in mathematics, not in shortsighted “mainstream”- politics. So my role model is rather Pythagoras and not Bill Gates and his US-friends in the “whole world” ;-) My way: Future-(sic) instead shortsighted profit-orientated tricks …
The current “IT-banana-republic by the grace of USA” and their “private” (lol) corporations and compliably lieges in nearly the whole world aren’t the future for sure (its not only an ethical, it’s a mathematical problem at first, btw) and I believe, the development of a so much intelligent and forward-looking programming-language like pil should not go into the trap of current (f.e. “singlespybrowser-” and “OO”-) “mainstream” – because already tomorrow the (IT-/mathematical) weather can change …
(Means too – on the political and(!) mathematical floor: It’s not tolerable, that nearly the whole world- communication is controled today by still only one single browser-developer-monopol with unclear, apparent untrustworthy goals and potentials! And a language (which ever!), which would submitting itself under those crazy circumstances by concept, wouldn’t be worth to be used further, because it’s on a foreseeable blind alley …
I mean: Picolisp should be/remain open for really(!) different(sic) (browser-) architectures (for future – but the nearly-only-browser-orientation is a basic question anyway!) – and in those cases there are still(!!) the problems, written in my first statement.) (btw: If I’ve a little more time, I will send you code-examples per mail, to demonstrate this. btw II: But even if im running picolisp-code in the same browser (firefox in this case) but in different versions of this browser and/or on different machines, there are different results! Thats not nicely! And: Not acceptable for a serious programming-language.
And my answer, proposition and trigger into the world about that (I dont want only grumble for nothing!) is:
Lets write an own browser (with a google-independent(!) architecture!) or a pil-own UI-system in(!) and for picolisp! (I know today and after decades(!) not one single satisfactorily UI) – and this new UI in the spirit of Alex’ genial ideas of a small and handy system. I believe: It’s worth! Means: Please let’s not stop with pil halfway! There is a lot “air in the heaven” for it. )
At first ( ;-) – lisp is written in my year of birth!) we had such things like C and relational databases.
Then we’ve got the “grand solution” ;-) : “objectoriented” languages – but had still those old relational databases. This was “schizophrenia 1.0”: “gap 1.0” so to say.
And in a short time we got – consequentially – “objectoriented” databases. Gap 1.0 closed? Happy end? Oh no!
Because the “objectorientation” wasn’t this allrounder like we believed at that time. (today I belive: the OO-approach was/is a little greenly: Reality and mathematics are part of the same world (for sure) – but not always congruent in a linear, naive way … And this is (in my opinion), why the good old lisps (old like myself ;-) ) come back into the focus again today …) But today we have in picolisp the same (but funnily inverse) situation like in the past: A functional(sic) language – but: Still the old, rotten, oversophisticated objectorientated” database-structure now. Isn’t it a “gap”?
And so again/still(sic) there persists the “gap” between the concept of the programming-language-architacture and the concept of the database-architecture.
Thats normal in other languages – but why in pil too?? Pil has (with Alex’ philosophy) the chance to go completely(!) new (really consistent!) ways: Language- and database- architecture consequently by lambda-calculus!
Who not need this, should change to perl! ;-)
Who chooses (and why!) a slim functional(!) language like pil for this fat objectorientated programming? If I want do objectorientated work, I will choose a completely(!) object-orientated system (and have to hire (and pay!!) then a company -oh wrong – a division(!) of programmers )! But then clearly I’ve not the elementariness (in more than one aspect!) of pil!
If I decide for pil – and then I can do jobs alone, or with 2 – 5 friends – but still(!) have the old struggle with a surprisingly fat “objectorientated” database-logic?
I don’t want a one-man-submarine, if I need a hundred man for bring it to the water!
The “gap” (in my eyes) is: The genial slim concept of pil is only bad (because kind of inconsistent) represented in this conventional-fat-objectoriented database-part. I belive, this database-concept isn’t optimum for pil! Too fat! (Hey Alex, it’s clearly, that not one single person alone can stem all this and your pil- output is anyways truly giant! And me by myself have no solution for that at moment(!) So my criticism has not the goal, to cut the pil-development, but show some drags for bear down them and to animate others, to search solutions in your footprints. Your work is absolutely cogent and worth a critical word. You will never hear a word about Java, or C++ etc. from me – it would be arrant time waste.)
You wrote: “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.”
LOL! Yeah! Precisely! Thats the point! For you it is a feature – for me it is a serious trial to use pil nonstop. Who needs an OO-DB in a functional(!) language?
Who needs a wood-gas-generator in a jet-plane? (and a OO-DB architecture is a IT-wood-gas-generator for sure)
Why not go consistently the (genial!) slim pil- way further into the database-world?! This “gap”, this unexpected stop in front of the database-question (like the Kimbers and Teutons in front of the Rome-city! ;-) ) makes me crazy! ;-)
At first we believed in OO-languages,then sequentially in OO-databases, then we saw: OO isn’t the only way to universal happiness, so now we’re wisely going back to functional languages – but not so to an invention of “functional databases” at the same time! This I mean with “gap” of constistence.
I mean: OO is a Mammut today – good for jewellery-scrimshaw …
Benerorth, you wrote: “… but a more practical one …”
Is OO really “more practical” just in a lisp-environment??
We shouldn’t forget the different developing-conditions for those two concepts:
OO is for big companies with divisions of programmers: Nobody knows the real world of the neighbor, so alls is managed “encapsulated”.
But pil?? I have no need, to “oo-encapsulate” myself, if I have to write the whole code by myself (or 2-3 friends) anyhow! And the OO-concept has a lot of pitfalls! I mean: “Who believes, he can write a mirror of reality by OO-concept hasn’t tryed it in real!” ;-)
And – please let me say this for the end:
I see the future of pil not only in the (only currend!) commercial world, in which you live,
but I see the future of pil (because of his lankines!) in the world of centuries of coming “lonely-small-peoples-programmers” in all small (like pil ;-) ) angles of the world, which dont need hacking software for smart-bombs, always fat governments and shifty spy-projects, but writing code (for example) for small medical solutions for areas, where are not doctors and medical help there, and the small people have to try to help themselves – computer-assisted! (yachties, islanders, peoples without acces to the oh so very “social” systems, peoples after a war (!) … etc.)
@beneroth: You wrote: “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.”
Isn’t it an logical inconsistency (and a joke for experts), if there is an ostensibly “simple” language, but not simple enough as an entry for beginners?
Are beginners always idiots, which have no interest to understand, what they’re write? Which shouöd stay on this level their whole life? Do you belive, C, C++ or Java would be better for beginners? My belive is: There is no better language than a slim lisp-dialect for the entrance into the programming-world – and I belive: This could be pil in the future! (Unfortunately still not in the present – there is f.e. naturally elisp(!) and racket, which is a dead-end-street in my eyes :-( , because pil is faster and slimmer, but racket is more oblinging for small peoples (by license-possibilities already (! commercial use possible(!)) (because: closed source possible, if I understand right – ideal for kitchen-programmers, which dont want hack for companies, but for their poor neighbors allover the world – for 5 dollars per deal!) for small developers, but(!) free ) and the inviting pedagogic concept!))
Is pil only written as a finger exercise for experts, which anyway have down 10 or 15 languages already? Which of them would spend time for pil? See you really the real (real huge!) chances of pil?
Jo
Aug 13th, 2020
Reply to “The German School of Lisp”