
Lisp as an Alternative to Java (1999) - nwhitfield1
http://norvig.com/java-lisp.html
======
lisper
This article appears on HN on a regular basis, so I thought people might be
interested in a bit of historical trivia: the reason this article is called
"Lisp as an Alternative to Java" instead of some other language is that it
cribbed the title off my original study
([http://www.flownet.com/gat/papers/lisp-
java.pdf](http://www.flownet.com/gat/papers/lisp-java.pdf)). The reason _that_
article was titled the way it was is that I was working at JPL at the time and
there was a software crisis underway. To that point, spacecraft had been
mostly programmed in assembly language. The then-recently-launched Cassini
spacecraft was a notable exception, having been programmed in Ada. But it was
becoming clear that neither of these approaches scaled well, and so the hunt
was on for an alternative. Java was the hot new language at the time, and it
was under serious consideration to become the new standard for spacecraft
coding. But Java was new and immature (and, in those days, very very slow),
and I was advocating to use Common Lisp instead. That study was conducted --
and the paper was titled -- in order to bolster my case.

Ultimately, Common Lisp flew on a spacecraft once, on the New Millennium DS1
mission. Unfortunately, there was a serious political shitstorm that
accompanied that mission, and Lisp never flew again despite several million
dollars having been spent to show it to be a viable approach. :-(

~~~
pjmlp
That is what I have found in most of my research of computing since Burroughs
attempted to use an Algol variant for systems programming.

The general opinion is that those systems failed due to technical issues,
however most of the time failures are caused by political wars.

They are even worse when they are caused by those that don't want things to
change, like what seems to have happened during Longhorn development.

So one needs a group strong enough monetary and political, to be able to
change ways of computing, sometimes even loosing a couple of battles to
eventually win the game.

~~~
bluejekyll
Info on the Longhorn project: [http://longhorn.ms/](http://longhorn.ms/)

~~~
pjmlp
Windows 8 base design is basically Longhorn to certain extent.

They brought COM+ Runtime back from the grave, exchanged the COM type
libraries for .NET metadata and renamed it WinRT.

At the same time C++/CLI syntax was repurposed for C++/CX this time doing AOT
compilation to native code. Similarly, .NET went through two new AOT
compilation toolchains, first the MDIL binary format used in Windows 8.x,
followed by .NET Native introduced in Windows 10.

Which begs the question if the Dev and Windows devisions weren't so busy
fighting each other, maybe just maybe, Longhorn would have had the UWP
application model instead of Windows having gone through all these releases
until they had settled their differences.

Now it still remains to be seen how much it will eventually matter.

This was just an example, there are others regarding other technologies, for
example Symbolics had quite a few internal fights.

[http://danluu.com/symbolics-lisp-machines/](http://danluu.com/symbolics-lisp-
machines/)

------
preordained
I've experienced those types of speed ups when doing "puzzler" programs in
Haskell as opposed to Java (the language I make money programming in). If
given a few weeks to implement a REST API or something much more real world,
I'd kick Haskell to the curb and cleave to Java like a long lost lover.
Libraries, tooling, community support and information...these are the
language's "killer" features.

~~~
seagreen
I support this attitude!

Haskell is coming around though. We got Stack which is a fantastic package
manager, and we now have a web API library which is pretty much unmatched:
[http://haskell-servant.readthedocs.io/en/stable/](http://haskell-
servant.readthedocs.io/en/stable/) (each Servant endpoint has a type, and you
can generate docs and client libraries from your backend code). Editor tooling
has historically been the other problem, but that's starting to come around
too.

~~~
harryjo
It's like Year of Linux on the Desktop. Every year it gets better, and some
long-suffered pain point is solved. But every year the world moves on and
users want more. Without a massive investment, it just can't keep up.

------
giardini
What are Oracle's plans for Java and the JVM?

"Insider: Oracle has lost interest in Java" \-
[http://www.infoworld.com/article/2987529/java/insider-
oracle...](http://www.infoworld.com/article/2987529/java/insider-oracle-lost-
interest-in-java.html)

"The email, sent to InfoWorld on Tuesday by a former high-ranking Java
official, claimed to feature details from inside Oracle. It said the company
was becoming a cloud company, competing with Salesforce, and 'Java has no
interest to them anymore.' The subject line cited 'Java -- planned
obsolescence.'"

"Oracle’s “planned obsolescence” for Java" \- [https://jaxenter.com/oracle-
and-javas-planned-obsolescence-1...](https://jaxenter.com/oracle-and-javas-
planned-obsolescence-121144.html)

'Oracle is cutting back on Java EE...it[Oracle] does not want to allow other
companies to help out on the Java platform. Proprietary product work will be
done using the Java app server WebLogic, and there will also be a proprietary
microservices platform. The email also dashes any hopes of Oracle
collaborating on a ‘Java foundation’ with other companies, let alone ever
relinquishing its ‘ownership’ of the Java platform.'

~~~
joostdevries
From what I hear the JVM still has a funded team at Oracle. It's Java EE that
has been put in the fridge. See fi this article on the upcoming Graal vm:
[https://medium.com/@octskyward/graal-
truffle-134d8f28fb69#.9...](https://medium.com/@octskyward/graal-
truffle-134d8f28fb69#.9tsd6xbs6)

~~~
meddlepal
Java EE is back. Oracle reversed course recently. I'm on mobile so I can't
find the soyrce but if you browse /r/java you can read about it. They were
thinking about killing EE for their own proprietary platform which backfired.

SE isn't going anywhere. Personally I'm a JVM developer but I really don't
care too much about EE.

------
nine_k
Statically typed language vs dynamically typed language is always a large set
of differences / compromises.

Java in 1999 was about as inexpressive as today's Go. The gap is narrower if
you take today's Java 8.

------
cm3
Or Oberon
[http://www.jucs.org/jucs_4_5/open_standards_beyond_java/Fran...](http://www.jucs.org/jucs_4_5/open_standards_beyond_java/Franz_M.html)
(1998).

The tech was released in 1996:

[http://www.modulaware.com/mdlt69.htm](http://www.modulaware.com/mdlt69.htm)

[https://github.com/Spirit-of-Oberon/Juice](https://github.com/Spirit-of-
Oberon/Juice)

[https://github.com/berkus/Juice](https://github.com/berkus/Juice)

~~~
pjmlp
With your nickname I was expecting Modula-3. :)

~~~
cm3
Good point, though Juice was a direct answer to Java from a pupil of Wirth, so
there's that.

It's funny that Franz was influential to both Brendan Eich (JS) and Andreas
Gal (Tracing JIT) but we still got JavaScript as a language, even though
Brendan cited[1] Oberon as an influence. At least we got tracing JITs and the
alternative AST encoding from Franz's intellectual cloud. I would really like
to understand how Bill Joy and Brendan Eich studied Oberon and we still got
Java and JavaScript, which haunt us to this day like the industrial takeover
by C in the 1980s does.

[1]
[https://news.ycombinator.com/item?id=9733520](https://news.ycombinator.com/item?id=9733520)

~~~
Roboprog
Love your description of the C/Java regime as a coup d'etat.

Join the dynamic programming underground! :-) (Or at least use a static
language that's not all jacked up)

~~~
pjmlp
C would never had taken over the computing world if AT&T had the freedom to
sell UNIX and did so at the same price levels as the other OSes, instead of
giving almost for free to universities as they decided to do.

Same thing with Java, it was available for free, just download and install
with a JDK that was "batteries included" versus the chaos of trying to write
portable code in C or C++ in the mid-90's.

------
dschiptsov
If one has serious interest in expert level Common Lisp code there is the
Norvig's masterpiece _Paradigms of Artificial Intelligence Programming_ (PAIP)
which is available form Amazon or torrents.

There is also the Common Lisp code from AIMA second edition.

PAIP and AIMA for CL is the same as SICP and old classic HtDP for Scheme.
After mastering these one might consider oneself a programmer.)

------
claystu
For me, it's a question of tooling.

I would love to see a Common Lisp expert do an entire book on Armed Bear
Common Lisp (Common Lisp entirely on the JVM). Edi Weitz hinted at what might
be possible in his book, Common Lisp Recipes, but only very superficially.

To me, the power of Common Lisp married to the ubiquity and library of the JVM
is the great possible future for CL.

~~~
jlg23
> For me, it's a question of tooling.

emacs & slime[1]

> I would love to see a Common Lisp expert do an entire book on Armed Bear
> Common Lisp

I'm curious what you'd expect from such a book. There are some excellent books
on CL in general and good libraries that provide a convenient layer over
implementation specific things (e.g.: uiop or cl-fad). One usually does not
think about a specific CL implementation when writing code - I'd even go as
far as saying that targeting a specific implementation is usually a sign of
bad coding style.

[1] [https://common-lisp.net/project/slime/](https://common-
lisp.net/project/slime/)

~~~
claystu
> emacs & slime[1]

I've spent a lot of time with emacs, and slime was what I used when I was
exploring Common Lisp: both SBCL and CLISP. Emacs is really powerful and I'm
fairly at home with it, but I've come to prefer more graphical IDE's. Judging
from the popularity of Eclipse, Visual Studio, NetBeans, etc...I'd say I'm not
alone. Telling programmers it's emacs+slime or the highway is not a strength;
it discourages everyone who prefers those other environments.

> I'd even go as far as saying that targeting a specific implementation is
> usually a sign of bad coding style.

I was suggesting ABCL because it is a full implementation of CL on the JVM. If
there are other CL's with ABCL's level of maturity on the JVM, then they would
work just as well.

Beyond that, I imagine that many programming projects target specific
implementations for various, pragmatic reasons.

~~~
taeric
What do the graphical environments gain you, in most cases? I'll not argue
that they don't usually have better defaults configured. Autocomplete, in
particular, typically works out of the box. These can work in emacs, though.
(Even in vim, to be honest.)

Seems most of them "win" by having more effective advocacy than they do more
effective features.

~~~
claystu
>What do the graphical environments gain you

Simplicity. In my IDE, I start it up and then program.

With emacs, it always felt like I spent a lot of time curating the editor.
Part of that was because customizing emacs is fun--I have this big .emacs file
that imports an even bigger .elisp file--but I also always seemed to be
referring to some documentation because I'd forgotten that particular set of
key-chords or messing with something to get it to work.

I've come to prefer simplicity. In fact, after years of using emacs, I
switched to vim for the moments when I want to program on the command line. (I
think my only customization in VIM is mapping jj to escape)

~~~
noobermin
In case this helps anyone else, I've found that a better shortcut for me is
Ctrl+[ , which actually maps to escape too. I too found having to tap escape
to exit modes was annoying since I had to make my fingers leave the home row
and there is no need to customize mapping in this case.

If you're used to hitting ctrl with your left pinky, which is necessary for us
emacsers, then Ctrl+[ will be 100x better than hitting escape.

------
ww520
It's not a popular opinion. With all due respect to Norvig, I feel it was not
a valid comparison. Java came out on 1996. Most people were not experienced in
it and were still figuring out how best to use it at the time. The language
and tooling were still immature. Lisp had been around for a long time then.
And he was very good very experienced in lisp at the time. Plus he had the
insight gained for the test afterward. So it is kind of expected to do well.

The greater variance between programmers than languages is very telling. It
shows experience and competence trump language difference.

------
dustingetz
Has Peter Norvig written about why Google went all in on java?

~~~
davidron
Did Google? Google is very much a polyglot orginization.
[https://www.quora.com/Which-programming-languages-does-
Googl...](https://www.quora.com/Which-programming-languages-does-Google-use-
internally)

As for Android, Google Purchased Android Inc in 2005, and I'm pretty sure the
decision to use Java came before Google's purchase.

~~~
pjmlp
It also helps that Android team has quite a few ex-Sun engineers that used to
work on Java, so I imagine that they rather keep pushing it than anything
else.

They are always quite clear that it is Java + C or C++ for native methods,
regardless of what developers might wish for.

------
beders
It's the same old problem. Writing as little code as possible is a non-goal
for a team of developers. Writing maintainable, easy-to-understand code is
much much more important.

And while I value Lisp (I started on Allegro Common Lisp on Sun OS), it's
density is also its greatest problem for any significantly large codebases.

------
Kinnard
Has anyone produce compelling insights on what causes these productivity
differentials?

~~~
abecedarius
Dunno, but note that the Lisp programmers in the study were self-selected from
a call for volunteers on comp.lang.lisp (and maybe comp.lang.scheme, I don't
remember). I suspect programmer skill mattered more than the choice of
language. (I was one of the volunteers, so obviously I'm biased.)

Ron could've partly controlled for this by posting the same query on
comp.lang.java -- of course it's still very hard to say how much bias would
remain.

~~~
danbruc
My guess also. I obviously could not resist and tried it in C#, took me 45
minutes but I admittedly did not bother to bring it to production quality. One
could certainly spend another hour or even an entire day and optimize it in
all kind of ways, from readability to performance. Also the available tools
are certainly important - selecting and converting a couple of lines into a
new method takes me less than five second or so with ReSharper, those things
add up if you have to do it often enough.

------
qwertyuiop924
As a Schemer who hates Java, I only wish it was.

