Posted Feb 17, 2007, 2:14 AM UTC
4913
Ah, Shivers... One hell of a CS professor.
If you happen to be at Northeastern and remotely interested in programming languages and co,pilers, I highly recommend you take his class on the subject. Even if you don't love the material, his stories will make it far worth it.
5
The T project hit a sweet spot in Lisp design that has rarely been hit since. Now that the code is available, I hope that somebody puts it to good use.
5
This is the sort info that makes programming.reddit so worthwhile. Thanks for it.
5
The lightweight languages lists are so fascinating to read... I wonder why there's no ll5+? Has the interest in little language design and research waned in recent years?
1
"I asked RMS when he was implementing emacs lisp why it was dynamically scoped and his exact reply was that lexical scope was too inefficient."
Huh. So that's why Emacs uses dynamic scoping.
I guess what they say about premature optimization is true (or should I be referencing a saying about legacy software?).
People more disgusted than me with Emacs Lisp have told me that this wasn't even a sane excuse, at the time, as better lisps had already proven themselves. And for dealing with the efficiencies of the day: my father still sneered at an editor he'd have to 'boot up' not ten years ago; the story of vi's origins suggests that Emacs-users mainly stuck to luxuriously fast connections to their servers, to even suffer such inefficiency in commands and drawing.
But I know none of this personally, and I anyway find it a bit wearisome that people today, flush with unimaginable wealth in computation and interconnection, bother very much with looking down on people who made decisions in states of now-unimaginable isolation and scarcity. From recent discussion, I suppose that the most important casaulty of dynamic scoping in Emacs Lisp is the ability of Emacs (or anything) to get from an Emacs Lisp program anything approaching the efficiency that CL and Scheme systems get.
Or the ability to use closures or reason about your code without having to take the whole system into account. That sort of unimportant things...
Well, I'm not so sure it is unfair to ding RMS for making a short-sighted decision. He set out to write an editor that would still be useful 20 or 30 years later, so that sort of implies fundamental design choices should've been made with an eye to the future.
Looking at it from a modern perspective, I'd say the current tragic problem with Emacs Lisp is that dynamic scoping makes it so very difficult to compile/translate/interpret/what-have-you Emacs Lisp into a Lisp dialect with a future, like Scheme or CL. For example, I suspect GNU Guile would have done a lot better if it had been the extension language for Emacs from the start.
Huh? In what sense does emacs lisp have no future? As part of emacs I'll bet it has a longer future than any of these Scheme in Java languages, even if it suffers from some poor design choices. I thought one of the interesting tidbits in the paper was the comment about prescheme in Scheme48 and the ability to handle multiple dialects.