Books of Note

Practical Common
LispThe best intro to start your journey. Excellent coverage of CLOS.

ANSI Common
LispAnother great starting point with a different focus.

Paradigms of Artificial Intelligence
ProgrammingA superb set of Lisp examples. Not just for the AI crowd.

Wednesday, June 04, 2008

A Timeless, Desert Island Language 

I started thinking about it today. What if I was stuck on the proverbial desert island? What programming language would I want to have to hammer out that critical calculation that would somehow return me back to civilization?

I know this is heresy, but I think I'd choose C.

"WTF!?!?!" I hear you cry. "This is a Lisp blog, dammit. You can't choose C." Well, you're right. But let me ramble for a second.

In my thinking this afternoon, I started to consider which programming languages are really timeless? Not just popular, mind you, but timeless. There aren't that many. COBOL was popular once. It wasn't timeless. PERL is certainly popular, but given the changes happening in PERL 6, it's not timeless either. Python? A very fun language, but not timeless. Ruby? Very hip and cool, but not timeless. How about Java? I once read something from the Long Now folks saying that they would be using Java for any programming because it was a language that could stand the test of time because of WORA. (If somebody can point me to a reference for this, please do. I was Googling madly for it this afternoon, but I can't seem to find it. I believe it was something Bill Joy wrote.) I didn't believe it then, and I certainly don't believe it now.

Nope, there is a huge difference between popularity and timelessness. I think C is timeless. C has been called "high level assembler." There are few other languages that do such a great job of raising you just slightly out of the world of bits, bytes, and machine registers, just enough to give you high level conditionals and loops, but not far enough that you can't get back to machine words.

Lisp is also timeless. Alan Kay has said that Lisp is "Maxwell's Equations of software." He's right. There is something that is so fundamental about Lisp that it simply cannot go away. It's far more than the parenthesis or the lists or the macros or any of that stuff that Lispers love. It's more than Common Lisp or Scheme or MacLisp or Emacs Lisp. It's all that stuff and more. At its core, Lisp is so compact and powerful as to be timeless. From McCarthy's original paper springs forth the whole world of every program that can be written.

In fairness to Kay, Smalltalk is pretty close to being timeless, too. In a certain sense, Smalltalk lives on in Ruby, but it's really the idea of message passing rather than Smalltalk specifically. Insofar as Smalltalk is synonymous with message passing (which it really isn't), it's timeless.

FORTH is timeless. The basics of a stack machine are pretty fundamental. The various FORTH words and implementation techniques may change (c.f. Factor), but the fundamentals are still recognizable as FORTH.

And that's why I'd choose C as my desert island language. Because in less than 10 pages of C, I can bootstrap a basic Lisp interpreter (or FORTH interpreter, for that matter). And with Lisp, I can write everything else. When PERL and Python are as dated as COBOL and Pascal, we'll still have Lisp. And it'll still be very recognizable as Lisp.


Comments:


C is very much bound to the model of a single cpu, binary, register based von Neumann architecture. You could not really use it on anything else.

Imagine having to use C on a system with one million very simple (only one instruction) asynchronous, balanced ternary, serial (1 Trit) cpus? ;)
 


excellent post, thank you
 


But can you not write a basic C implementation in 10 pages of Lisp?
 


You're stuck on a desert island and you're worrying about what programming language to use? You're a sick sick person.
 


I think I agree, even though I am a bit sad because I think the whole world should evolve. C is simply not the best "available" language, it is only true that it is a great syntax sugar towards assembly stuff.

This makes me really sad, and the worst part is that hardly any language tries to dethrone C. Sure, languages like Ruby make it super easy to do stuff quickly, but it lacks the really low level part. One can do inline-C in ruby, but let's be honest - why would anyone who works 24/7 in C, use ruby when he ends up doing most stuff in C _anyway_?

A sad state that there is no way around C. But also tells viewers that knowing C is EXTREMELY important
 


> But can you not write a basic C implementation in 10 pages of Lisp?

First of all, it's easier to write a basic Lisp implementation then otherwise, second, C languages are generally down to the metal hardware languages, as opposed to many a lisp which run interpreted just fine. So, considering that the C language would take more time, and also require knowledge about the CPU (we're on an island, no downloading docs, and reverse engineering is hard) it'd be much easier to implement a proper lisp in C (a day or two personally) then the other way around.
 


What if you were trapped on an island with a Lisp Machine...
 


But the real Desert Island question would be: is it easier to build a Von Neuman-like computer or a Chuch-like computer (lambda calculus machine), with coconuts and sand? Show me your computer, I'll tell you what basic language to put on ;-)
 


What if you were trapped on an island with a Lisp Machine...

Ha! Indeed. I'd probably still take C, but the Lisp implementation would be both trivial and wicked fast. ;-)
 


C is very much bound to the model of a single cpu, binary, register based von Neumann architecture. You could not really use it on anything else.

Actually, no. C doesn't make assumptions about CPU-count (it's running quite well on this multicore machine, for instance). Registers? Not really. Yes, the "register" keyword still exists from KR C, but it's all but deprecated, the compiler is free to ignore it, and its semantics were always "put this variable in fast memory," not necessarily in an actual register. It would work quite well in a stack machine, for instance.

vonNeumann? Yep, that's true. And there are definitely some assumptions in a lot of C code about word size, but the first C compilers ran on machines without 8-bit bytes, so it's hardly a property of C itself, but rather the codebases.

C definitely assumes that you have pointers to an addressable memory store and that pointers can be converted to integers at will. A lot of code uses this property to fiddle with pointers, assuming byte addressability, but again, this is more a property of the code, not the compiler.

C has been used to develop for VLIW machines, stack machines, DSPs, and just about everything else. As I said, while lots of code makes lots of assumptions, C itself doesn't make too many.
 


But can you not write a basic C implementation in 10 pages of Lisp?

Unfortunately, no. The parser alone would occupy a few pages, written in a parser generator language like LEX/YACC or ANTLR.

In contrast, the reader for a basic Lisp is approx 100 lines. No fancy Common Lisp readtables, reader macros, etc., to be sure, but something that will parse integers, lists, strings, handle quote, etc.
 


That sounds like a challenge...
 


What/where is the shortest lisp implementation in C?
 


Dave: I think the point the first post was trying to make was along the same lines as John Backus' 1977 Turing Award lecture ("Can Programming Be Liberated from the von Neumann Style?"). It's worth reading if you haven't seen it before.
 


Ha! Indeed. I'd probably still take C, but the Lisp implementation would be both trivial and wicked fast. ;-)

Even if you could do C (Symbolics only feature?) it would still compile to Lisp. Muahahaha!
 


...it was a language that could stand the test of time because of WORA. (If somebody can point me to a reference for this, please do.

WORA = Write Once Run Anywhere

Though I'd say:

WORABBCWTAS = Write Once Run Anywhere But Be Careful With The Application Server :-P
 


There is a lisp implemented in 500 lines of C. Named lisp500.c of course.
http://www.modeemi.fi/~chery/lisp500/
 


There is a lisp implemented in 500 lines of C. Named lisp500.c of course.
http://www.modeemi.fi/~chery/lisp500/


Ha! Yes, I had even forgotten about Lisp500. It's a lot more than you would need to get started, way more than a simple McCarthy interpreter. It actually makes an attempt to give you a lot of Common Lisp (SETF, for instance).

The code is quite dense and the 500 line limit is stretched a bit IMO (no comments, multiple statements per line to increase the density, etc.). Still, it gives you something very Common Lisp-esque, complete with a simple GC.

Heck, if you ripped out a lot of the Common Lisp stuff, you might be able to get it down under 400 lines. ;-)
 


If all you are going to do is bootstrap Lisp, why not ask for Lisp in the first place?
 


If I were on a deserted island, i'd want to know metallurgy and electronics for building a radio transmitter from sand and magnetite.

On the other hand, if I were not on a deserted island and civilization collapsed, then i'd be writing serial interfaces for Linux to manage industrial processes, so that would be C.
 


LISP is a beautiful language for many concepts of programming. Gorgeous if only parentheses could be seen as 3D bubbles on lists in prefix notation. Elegant, smooth, organic.

Processors, as they exist as consumer devices, don't follow the rules of lisp. They follow the rules of, hey check out this new thing we can do!!!!!!!! !!!!

I am interested in 'anonymous's comment regarding C being bound to a single cpu. I have somehow found myself writing a lot of code targeting multicore platform: nVidia GPU, Intel multicore, STI Cell, (still haven't played with some of the other cool players, SiCortex, the latest Sun Niagara 2 chip, etc.)

And, I ask you this, why does putting in lisp interpreter pthreads not throw out even one page... even one page. I mean Posix threads aren't the best way to do multicore, but... they are easy and well documented.

So... paradigm this, paradigm that... give me C and maybe a copy of that first paper on Lisp.

Forth... haven't tried it yet really.
 


http://franz.com/support/documentation/current/doc/multiprocessing.htm
very interesting... very far out from the main stream I find myself in, but interesting.
 

Post a Comment


Links to this post:

Create a Link

This page is powered by Blogger. Isn't yours?