
Lisp: A Language for Internet Scripting and Programming (1998) [pdf] - jwdunne
http://norvig.com/lugm.pdf
======
brudgers
As I was reading, I couldn't help but thinking about why the world didn't turn
out this way, and I came to the conclusion that in 1998 the only two companies
who realized that the future of the web was the browser were Microsoft and
AOL. [1] The rough isomorphism between HTML and Lisp S-expressions [2] was an
obvious technical advantage over JavaScript and among the Lisps, though
tellingly not the case with Scheme, the association list was already in place
to do all the work that JSON has come to perform in exactly the same way but
for syntax.

AOL of course destroyed Netscape after purchasing it by encumbering itself and
all it touched with an East Coast Big Dumb Company mindset. It wasn't until
years later when Google started seeing Microsoft as the competition that
anyone else treated the browser strategically. By that time, JavaScript had
won just by showing up in IE 6 and in the legacy Mozilla carried from
Netscape.

What might have happened if Yahoo had decided the browser was strategic
instead of living off banner ad revenue at the expense of increasing
irrelevance? They had Graham and the Viaweb team, and so some manager decided
to port their code to C++ and the rest, as they say, is history that never
was.

[1] It is interesting to think that Apple would build its future in ways that
treated the browser as a commodity - first with the iPod and then with the app
store.

[2] See Slava Akhmechet's _The Nature of Lisp_. It's definitely worth reading:
[http://www.defmacro.org/ramblings/lisp.html](http://www.defmacro.org/ramblings/lisp.html)

~~~
klibertp
> among the Lisps, though tellingly not the case with Scheme, the association
> list was already in place

An association list is just a list which elements are conses. I'm fairly
certain that cons, car and cdr were part of Scheme since the beginning and
they are all you need to build assoc and friends. Scheme lacked a proper
hashtable datatype though, which was present in some other Lisps.

~~~
rurban
he was talking about scope here. hashes do not help much.

assoc lists were important to implement dynamic environments simple and fast,
which is not so easy with hash tables. In assoc lists you tolerate duplicates,
but by putting new at the beginning you override/"shadow" the old ones, until
you leave scope and use the old assoc list. and share the data! with hashes
you have to actively delete or copy the tables. non-efficient and very
complicated.

~~~
frou_dh
They're really neat. When I learned about them it emphasised that it's amazing
what a handful of cons cells and some thin air can do.

------
dmunoz
> Simple debugging. This is an area where AI techniques could be quite
> helpful. Detecting and explaining common syntax and runtime errors is a
> crucial step in teaching a new language. Tools which provide this type of
> support could increase the interest in this language in the mainstream. Our
> current debugging support is minimal and provides only the basic commands:
> step, skip, and continue.

I have given some thought to this in the past. Has there ever been a serious
attempt at this?

Sometimes the error messages for really simple mistakes (missing semicolon,
wrong punctuation, etc.) are obtuse and almost completely meaningless. Of
course, if it were easy to give simple, clear error message in such cases,
they resulting message would be simple, so it's other complexities that get in
the way. The biggest problem I see is that having labelled training data, e.g.
source code that fails compilation along with the specific actual error, is
unlikely, and having an expert provide small, self-contained examples is
unlikely to be useful (really, enough training data to be effective) in real
world errors, even when novice programs are fairly small.

Edit: I was just thinking about this, and with prudent use of a VCS, labelled
training data would just be pairs of the form <commit that fails, next commit
that compiles>. It would be interesting to see if it's possible to pull useful
data from exiting history, or if some level of restraint is necessary in
practice. Really, I'm just thinking about the precipice of supervised and
unsupervised learning here.

~~~
chubot
For syntax errors, check out:
[http://research.swtch.com/yyerror](http://research.swtch.com/yyerror)

It's not "AI" but I think it's a much more practical approach that any parser
could implement, with enough work and feedback.

I haven't used Go enough to know if this technique makes a qualitative
difference on the friendliness of error messages. Interested to hear opinions.

~~~
ansimionescu
I've used Go for a personal project for a bit now and the compiler output is
pretty good and consistent; beats Python and C++, I'd say.

------
pge
Here's a link to PG's essay and speech excerpts on why Lisp is great for web-
based applications (2001) -
[http://www.paulgraham.com/lwba.html](http://www.paulgraham.com/lwba.html)

PG delivered a similar message to my undergraduate CS class in 1996/7 as a
guest speaker when he was working on Viaweb and extolling the virtues of LISP
for server-side web applications.

~~~
nswanberg
It's strange that it took so long for someone to mention pg. Viaweb was
written in lisp, and the site we're on is in arc, a lisp dialect.

------
coldtea
> _The syntactic and semantic simplicity of LISP enables non-experts to
> quickly master a basic level of LISP programming._

For Scheme this might hold true. But most Common Lisp programs I've seen are
beyond hairy.

Plus, the (classic intro-to-LISP) notion that "it has a simple syntax with few
constructs so it must be easy to program in" has to die.

Assembly has very simple syntax too. I wouldn't write a large program in it.

~~~
Crito
> _" Plus, the (classic intro-to-LISP) notion that "it has a simple syntax
> with few constructs so it must be easy to program in" has to die. Assembly
> has very simple syntax too. I wouldn't write a large program in it."_

Suppose we amend that to simple _high-level_ constructs?

I don't think I've ever picked up a language as fast as I picked up scheme.
Not even python.

~~~
bunderbunder
Scheme's extremely simple* but it's a perverse simplicity.

My experience from tutoring CS students in Scheme back in the day was that it
usually either clicked immediately, or not at all. The folks who'd perhaps
never get good at it aren't necessarily poor programmers. I don't know that
any of them were great programmers, but that might be my prejudice as someone
who was having a hard time teaching them a programming language. Some of them
went on to get more impressive ones than the one I have, so probably
definitely it was just prejudice. Anyway, the point remains, I've met a lot of
people who struggled with Scheme, and it was most certainly not for want of
smarts. My best guess is that it's just that the language is only suitable for
people who have a certain approach to thinking that's perhaps unusual.

* And beautiful - easily one of the most lovely languages I know.

~~~
hajile
I believe this is where Common Lisp got it right and scheme got it wrong. The
scheme designers wanted a more pure language when often, the dirty imperative
method is desirable. Common lisp has many features to make programming of
real, large-scale projects easy (a great example is looping constructs which
are often more obvious and easier than the more 'pure' tail recursion
preference of scheme).

~~~
6cxs2hd6
Scheme has plenty of dirty imperative methods, if you want. Their names end
with `!`, like `set!` to mutate a variable. In most cases it's cleaner to be
purely functional, but it's not required.

Predicates end with `?`, like `equal?`.

This naming and consistency makes it easier to learn Scheme.

What makes Common Lisp more practical is libraries. Hairy and crufty some may
be, but many of them, and many of good quality. You know the old saying about
how X is a badly implemented version of half of Common Lisp.

The Scheme-descendant Racket is, however, plenty practical in this regard.

~~~
hajile
I really don't like the Common Lisp naming and the 2-space nature of the
language makes this even worse. The conflict of the implementors appears in
many places. I like many things about scheme, but I won't whitewash it's
problems.

Non-standard, non-portable racket libraries aren't the answer to scheme's
basic nature (though I believe r7rs-large will solve a lot of these issues).
More serious dealbreakers in my work are the lack of declare, no built-in OOP,
and no spec for optional and keyword parameters.

Scheme has other issues too such as the inability to turn off continuations
(they are great in some situations, but can cause performance issues and
specifically cause increased memory usage).

~~~
samth
Racket's extensive collection of libraries aren't meant to answer anything
about Scheme -- they're for Racket. That's why we changed the name.

Racket is, however, a great answer to "is there a Lisp that's both
conceptually consistent and has lots of libraries".

------
asgard1024
Note to any future academic paper writers: Please include a date in your
paper. Thanks.

Judging from Norvig's employment, this is at least 10 years old. And also from
SILK, which later evolved to JScheme, which is now used in e.g. Scheme Droid
interpreter for Android.

~~~
Create
Y2k

------
stiff
This is from 1998, and Peter Norvig has long since switched to Python.

    
    
      "LISP - a Language for Internet Scripting and Programming",
    
      Timothy J. Hickey, Peter Norvig, and Ken Anderson
    
      LUGM'98: Proceedings of Lisp in the Mainstream, Nov. 1998, Berkeley, CA.
    

As per [http://www.cs.brandeis.edu/~tim/](http://www.cs.brandeis.edu/~tim/)

~~~
informatimago
Any lisper who needs to make a living will switch to anything. Usually, that
doesn't remove any merit to lisp or the lisper.

------
pekk
Browser makers like Mozilla have had the option, at any time, to enable the
use of Lisp (or any other language) in the place of Javascript. Nothing
uniquely qualifies Javascript.

~~~
lisper
Not even "in place of" but "in addition to". There's a reason that the script
tag has a language attribute as part of the standard.

~~~
Ygg2
I'm afraid you're browser doesn't support XScript, please download Chrome
Explorer 310.

On a serious note, JavaScript and the lack of fragmentation is one of the best
features of Web. You don't have to download appropriate browsers (in theory
and mostly in practice) to run your website.

~~~
lisper
> I'm afraid you're browser doesn't support XScript, please download Chrome
> Explorer 310.

But this sort of thing already happens all the time. You don't have the right
flash player, or the right silverlight player, or the right version of Java.
There would be very little difference in the UX between different scripting
languages and the current UX w.r.t. media codexes, and the end result would be
the same in both cases: there would be some repertoire of languages and
codexes that everyone uses and become standard.

The alternative is to forever have to deal with a language that by design
cannot even handle integer math or unicode strings properly.

~~~
randallsquared
> But this sort of thing already happens all the time. You don't have the
> right flash player, or the right silverlight player, or the right version of
> Java.

That's exactly the point. Imagine dozens of them.

~~~
lisper
Dozens of what? Browser plugins? I don't have to imagine, that's the world we
live in. Dozens of languages? I very much doubt that will happen. Just as we
only have a small handful of codexes that actually matter (Flash, Silverlight,
H264, maybe ogg) I predict that we will end up with a small number of
languages that actually matter: Javascript, Python, Ruby, and Scheme. Maybe
CL.

IMHO that would be a better world than the one we currently live in.
Javascript is serviceable for its original purpose, but for serious webapps
it's broken beyond redemption. NOTE: This is not to say that it is impossible
to write serious webapps in Javasceript. Obviously it is possible. What I mean
is that at some point the aggregate cost of dealing with Javascript's design
flaws becomes greater than the aggregate cost of dealing with multiple browser
scripting languages.

~~~
reissbaker
> Dozens of what? Browser plugins? I don't have to imagine, that's the world
> we live in.

That's quite a stretch. There are two browser plugins that are in broad use on
the web: Flash, for fallback audio/video support and some casual games, and
Silverlight, for Netflix. Both are dead technologies when you consider mobile
web; even if you're only thinking about laptops/desktops, both Silverlight and
Flash have essentially been abandoned by their creators, and the web platform
has almost entirely subsumed their original purpose for existing, currently
with the exception of DRM.

Personally, what I'm hoping happens is that we get one, single better compile
target, and languages can just target that — giving the web a broader
selection of languages without the fragmented nightmare (and security
nightmare) of introducing dozens of new plugins. This is something that
browser vendors are currently working on: Google with PNACL, and Mozilla (and,
to some extent, Google as well) with asm.js. I hope we end up with PNACL, but
a sufficiently optimized asm.js would serve the same purpose, albeit with a
more difficult debugging / performance optimization story.

~~~
lisper
> Personally, what I'm hoping happens is that we get one, single better
> compile target

That is a terrific idea in theory, but the last time anyone tried to do that
the result was the JVM.

~~~
quacker
Are you trolling here, or are you really implying that the JVM is bad? Could
you elaborate?

I consider the JVM to be the best part of programming in Java. The JVM is
fast, lets you write very portable code, and it gives you a great debugging
experience. Plenty of other languages chose to target the JVM, like Scala and
Clojure, for its quality.

That's not to say the JVM is perfect. I don't like type erasure for instance
(I understand C# has 'better' generics). Nevertheless - and this idea comes up
frequently - imagine if browsers ran VM bytecode instead of interpreting
JavaScript. The browser would be totally language-independent. You could write
in any language that compiles to the browser bytecode, and deploy the
precompiled bytecode 'object' files. I mean, it is a great idea in theory, and
it's exactly what the JVM has succeeded in doing, except that the JVM does it
for operating systems and not browsers.

Of course, this is all a fantasy at this point. There's no possible way
browser vendors would ever agree on a standardized virtual machine, much less
all implement it (see DartVM).

~~~
lisper
> Are you trolling here, or are you really implying that the JVM is bad? Could
> you elaborate?

No, I'm not trolling. I was responding to someone who said that the two non-
dead browser plugin technologies were flash and silverlight. Java is notably
absent from that list. (Can you even interact with the DOM from a Java
applet?)

I agree with you that the JVM is the best part of Java, but that's not saying
much IMHO.

~~~
reissbaker
Java applets had a lot working against them from a technical and UX
perspective: they were insecure, and popped up quite scary warning notices
about security that had to be clicked through in order to run the applets.
Java was also poorly optimized for consumer-facing applications: JIT startup
and warmup time was sufficiently long that they felt more sluggish than
HTML/CSS/JS, despite the fact that in the long run the JVM outperforms JS by a
significant margin.

In an aside, the JVM has only relatively recently been an effective general-
purpose compile target, and it wasn't designed as such. The JVM's failure for
frontends doesn't give much indication as to where the pitfalls of targets
like PNACL or asm.js might be: it died (deservedly) because of reasons that
apply to neither technology — slow startup time and lack of effective
sandboxing. Both PNACL and asm.js start quickly, lean on hardware-acceleration
in the browser to react smoothly, are designed from the start as compile
targets, and are sandboxed to the point where browser vendors don't feel the
need to pop up warning boxes that scare off consumers.

------
einhverfr
I was thinking about this too. I am somewhat of a lisp newbie, but one of the
people on the LedgerSMB team also maintains Armed Bear Common Lisp (i.e. Lisp
in the JVM).

I remember talking with him about teaching languages to kids. Like me he has
three kids. I was noticing that many of the beginner languages were quite
Lispy, including Logo which I had been teaching my oldest and I asked about
the suitability of various lisps beyond this (I would end up going the
direction of Rebol instead at this point, but plan to come back to Lisp).

His response was that for a beginner, Lisp is nice, but Common Lisp was, in
his words, "too big" to be an early programming language, so one has to start
small and work up.

I can't help but wonder at this. "Simplicity in the eyes of the user" is not
something I have ever associated with Lisp as a whole but it seems like part
of that is jumping into Common Lisp directly.

Now, none of this means one couldn't have a lisp for the web. However, we
don't have one right now.

~~~
hajile
Brendan Eich made the statement (speaking of JS as the asm of the web):
"Source as 'bytecode' also avoids the big stupid Java bytecode mistake:
freezing a poorly designed lowered form of Java, then being unable to evolve
the high-form source, i.e., the Java programming language for fear of breaking
Java bytecode compatibility. This severely messed up the design of inner
classes and then generics in Java -- and then Sun broke bytecode compat
anyway!"
[Source]([http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageFo...](http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageForTheWebPart2MadnessOrJustInsanity.aspx))

We are at a point where JS is following the same path. Ideas like ECMAScript 4
were rejected because they would break compatibility and we are still working
around the problems of JS. We need that clean break now rather than later.
Such a clean break would be at it's best now rather than later. We could
simply continue supporting the current JS compilers 'as is' for old code (or
provide a JS to new language compiler) and replace the language with another
which is designed correctly (we could perhaps break the DOM too).

While I would like to see a scheme r7rs used (except with support for OOP,
built-in actors, and static typing), I suspect that M-expressions (more like
dylan) would be necessary (though for the record, I've seen more nested
parenthesis/braces in JS code than I've seen in a lot lisp code). Such a
language could also be interpreted via JS (or compiled to JS) for old browsers
(though I suspect telling people to upgrade or go without would promote
suitable updating more akin to telling everyone to change to digital TV or go
without).

We need a clean break and lisp is worthy of consideration rather than being
cast to the side like last time.

~~~
pjmlp
> though for the record, I've seen more nested parenthesis/braces in JS code
> than I've seen in a lot lisp code

I saw a presentation once, where they compared the amount of
parenthesis/braces in mainstream languages vs Lisp, with Lisp having less in
most algorithms being compared.

For example,

    
    
        func_call(args) vs (func_call args)
        array_access[index] vs (array_access index)
    

The thing is, since in other languages parenthesis/braces tend to be scattered
along the source file, it looks like less than Lisp based languages.

------
jokoon
I wonder if any teacher already tried to teach LISP as a first language
instead of java or C, and what there was to learn about it.

~~~
chimeracoder
MIT is where the legendary "Wizard Book" (SICP)[0] was developed, for teaching
their introductory class using Scheme.

A few years ago, MIT restructured their entire CS curriculum (not just the
intro class) in a way that required redesigning the individual curricula of
each of the classes, including the intro class. As a result, they couldn't use
SICP, since it didn't cover the same topics. At this time, they ended up
switching to using Python for the class.

This is sometimes presented by people who dislike functional programming as an
indictment of Scheme/Lisp, though this is very misleading. Nobody made the
decision to "abandon" SICP - "they" made the decision to redesign the entire
curriculum (top to bottom), which meant writing new syllabi/textbooks for
_all_ /most of their classes, especially the intro class, and _then_ "they"
made the decision to write the new syllabus/book for that new intro class in
Python[0].

Some schools (University of Minnesota is one) still use SICP.

Personally, I think that SICP is the best way to be introduced to both the
fundamentals of computer science and programming. The only caveat is that it
requires a certain level of dedication before-the-fact (something that could
be reasonably assumed in an MIT intro class). So it's not the best choice for
someone who "just wants to dabble" in programming and see if they like it (try
Python or Ruby for that), or for someone who wants to understand computer
architecture and engineering (try C for that), but for everyone else, it's
unparalleled.

The nice thing about SICP is that it focuses very little on learning the
nitty-gritties of Scheme (partly because there's so little to learn!), whereas
most other introductory materials I've seen have to focus on Java-specific,
Python-specfic, etc. features. Reading SICP feels more like reading a math
textbook that "just happens" to come with a REPL for mathematical expressions,
as opposed to learning the ins and outs of a given programming language or
environment.

[0] Of course, "they" refers to many different people, very few of whom would
be in the same "they" as it was in the 1980s when SICP was first written, so
one has to keep that in mind before concluding that MIT "changed their mind".

[0] [https://mitpress.mit.edu/sicp/](https://mitpress.mit.edu/sicp/)

~~~
hga
There's a bit more that went into all of this:

MIT's EECS undergraduate enrollment _cratered_ after the "dot.com" crash, more
than halved, after being 40% of the student body for decades.

The department panicked.

And it was most certainly ordered that Scheme be _entirely_ purged from the
base curriculum, even while they claimed they were teaching SICP concepts and
functional programming in 6.005, they were using Java, a language that's "not
even wrong" for the purpose (that, at least, has been improved to Python,
which is only [fill in the blank] hostile to FP).

Not one of the department's finer moments, from my no direct interest in EE at
all viewpoint, but from a less biased one you can safely say a MIT EECS degree
now means something quite different. And it's a damned shame for those outside
the department, for whom 6.001 was truly valuable, that MIT no longer offers
anything in its niche (outside of a rearguard 1 month version of it during
January).

------
ThePhysicist
Well, if using Lisp in the browser sounds tempting, you should have a look at
Clojurescript:
[https://github.com/clojure/clojurescript](https://github.com/clojure/clojurescript)

------
q2
For a moment, it really appeared LISP is acronym: <L>anguage for <I>nternet
<S>cripting and <P>rogramming rather than LISt Processing.

------
vinalia
LISP is still a great language for web programming! [1]

Lately it seems like more people are doing compile to JS (like asm.js and
Mozilla's emscripten work in Odin Monkey [2]) which fits in perfectly with
LISP dialects. Programmers can still create their own DSLs, macros, compilers,
etc. in LISP and use them for modern web apps today. Just because this is a
less popular/documented route doesn't mean it isn't possible. I hope we'll see
a rise in LISP web programming pretty soon.

It would be fun if someone could write a compiler for a new ClojureScript
dialect that targets asm.js and takes advantage of CPS for recursion like
Scheme does.

[1] [https://github.com/jashkenas/coffee-script/wiki/List-of-
lang...](https://github.com/jashkenas/coffee-script/wiki/List-of-languages-
that-compile-to-JS#wiki-lisp-scheme)

[2]
[https://wiki.mozilla.org/Javascript:SpiderMonkey:OdinMonkey](https://wiki.mozilla.org/Javascript:SpiderMonkey:OdinMonkey)

------
fsloth
OOoh, nice. Is this is a direct intellectual precursor to Clojure (although I
have no idea if the authors have had any collaboration)?

~~~
wging
Rich Hickey is probably not the same as Timothy J. Hickey.

------
mark_l_watson
I remember when Peter Norvig wrote the first cut at Silk - I think he wrote it
in one weekend.

~~~
S4M
I think he wrote it to teach himself Java.

------
vijaymathew
I've been working on a Scheme that might be more welcoming to people with a
()-phobia:
[http://vijaymathew.github.io/slogan/index.html](http://vijaymathew.github.io/slogan/index.html)

~~~
hajile
What advantage does this have over dylan?

------
zoowar
SILK - Scheme In 50 KB

