If there's one thing that irritates me about the pg-led Lisp renaissance it's the fascination with the Ur-Lisp. Rewriting that Ur-Lisp has become a pastime. Here are just some of the reasons I think that's dumb:
Lisp is a bad model if you want some kind of axioms of computing
We already have the lambda calculus for that, and you can build a real language with that (see Haskell). If you want to write some minimal thingy in C, consider writing a Haskell, not a Lisp.
That you can write a Lisp evaluator in Lisp was interesting in 1959 (and maybe 1960), and let's face it, that Ur-Lisp was one broken language.
Car, cdr, wtf?
Contents of the address part of register, contents of the decrement part of register, what the fuck? What are they doing in a language, even a toy, written in 2010? Please use data structures.
Where are the closures?
If you're looking for a challenge, as opposed to redoing something that's been done ad meam nauseam for half a century fachrissakes, try to find a minimal and explainable way to do closures. Bonus points for efficient flat environments. Languages without closures are so 1959.
Where are the macros?
A Lisp without macros is meaningless.
Where's the control flow?
A Lisp without some kind of continuations and condition system is useless.
Where are the semantics?
If you read the RnRS attentively, you'll see that Lisp has evolved a deep and subtle set of semantic concepts, none of which feature in the Ur-Lisp.
What's the purpose?
Surely you're not learning much by repeating JMC's flawed Ur-Lisp from 1959. If you want to learn something, implement a language with closures and macros. If you want to learn more, make it a compiler. If you want to blow your head, implement hygienic macros or a higher-order module system or a static type checker. That's today's standard.
Look, Lisp is such a great language, but if anything we have to push it harder, not continuously go back to 1959.
Update: More fully-featured, modern Lisps, pulleezz
Subscribe to:
Post Comments (Atom)
11 comments:
You have to remember, it's not always about advancing the Lisp state of the art, sometimes it's just about advancing your own knowledge. Simple lisps are fascinating to folks learning about lisp because they are so simple, and so simple to implement.
This is the programming equivalent to yelling at some kids to stay off your lawn. Seriously, who cares what code other people write?
:f
@Kurt: Yes, but: they aren't Lisps, they're Ur-Lisps, and by implementing them, you'll learn little useful about implementing a Lisp, and probably some harmful things.
@fogus: I used to think critics suck when they write about the flaws in a movie or album. But today I think that stuff people put out there may have negative consequences, and it's right to criticize it. A bad movie for example lowers the already low ceiling for further bad movies. The same with programs.
The amateur PL community today creates one laughable PL after the next, exactly because noone cares. And some of these languages then become successful, and fuck up my life, because I may be forced to use them to access some library or script some program. If yelling at the kids prevents just one language with broken closures from emerging, I've succeeded.
Although I think you're overstating the matter, I can sympathize with the pain of dealing with languages that I dislike. I personally like little Lisps, but then again I've never met a Lisp that I didn't like. I think you're in the minority on this, but I'd probably never read this blog if you were the kind to follow the herd.
One more clarification @Kurt: The Ur-Lisp of 1960 was simply the earliest, flawed articulation of the Lisp language, and only in the 1980's, with Scheme, was most of it finally understood to a point where it actually made sense. So from a learning perspective, implementing a pre-Scheme Lisp can truly be considered harmful, IMO.
@fogus: Hm, lucky you, I've never met a Lisp I did like ;)
Actually, one of my pet peeves (as a Haskell programmer) is people talking about closures as if they were a language feature and not an implementation detail of some interpreter or compiler.
What you want is first class functions or procedures (lambda abstractions up to equivalence), not closures (pairs of code and environment). If you design your language properly, whether or not you used closures or graph rewriting, or any other implementation of first-class functions as part of the implementation should be impossible to tell from the perspective of the users of the language.
Although it's nice to advance the state of knowledge by making toys, I think I'll agree that 2010 lisp toys should include at the minimum closures and macros. I'd leave continuations for 2020.
@Cale: closures are the intersection of first-class functions and lexical scope. First-class functions with dynamic scope do not get you closures.
Ur-Scheme (were you thinking of it when you wrote this?) is surely a toy Lisp, but it is a compiler with closures and macros. I learned a lot writing it.
I think there's something to be said in favor of publishing it, even if it's not going to be useful to anybody who runs it — some of the things I learned writing it are not widely known. Among other things, it's a safe language that runs faster than any of the full-Scheme implementations I used to bootstrap it. (I suspect Ikarus may be faster, but still haven't tried it.)
I think telling people not to write things like this because they won't write anything new is kind of mean-spirited. It's like telling people to stop writing love poems because they probably won't say anything Rainer Maria Rilke or Elizabeth Barrett Browning or Goethe didn't already say, and better. Writing love poems is good for your soul, and so is sharing them with other people. Insisting that people not publish their work until they are pushing forward the state of the art, well, that's a recipe for them never getting to the level where they can.
Kragen:
The OP doesn't really reflect my current POV, and in fact maybe not even my then POV - it's just a small rant.
What I wanted to say is that people shouldn't stop at building a small Lisp, but go all the way.
No, I didn't think of Ur-Scheme.
Post a Comment