Lisp as an Alternative to Java (1999) | Hacker News Reader

Lisp as an Alternative to Java (1999)

norvig.com

77 pointsnwhitfield1103 comments

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). 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. :-(

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.

Info on the Longhorn project: http://longhorn.ms/

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/

For people that are curious about the story behind Common Lisp in space, Stuart Sierra gave a talk at Clojure West that includes that story that I thought was interesting (along with the rest of the talk!)

https://youtu.be/-RaFcpNiYCo?t=8m10s

A more detailed (and accurate) account:

https://www.youtube.com/watch?v=_gZK0tW8EhQ

Stuart got one significant factual detail wrong: the race condition was in Lisp code.

Out of curiosity - what caused limitations of scaling ada?

I'm not sure. I've sent out some inquiries to the people I know who actually worked on Ada code back in the day. If I get a response I'll post it here.

I appreciate that

OK, I got a reply, but it was off the record so I can only pass along my own interpretation of it here.

It turns out I was wrong when I said that the reason Ada didn't get used more was that it didn't scale. It did. It worked just fine on Cassini, and there was no reason based on that experience to believe that it wouldn't work on other spacecraft.

The reason it wasn't used more turns out to be the same reason Lisp wasn't used more: politics. Cassini was being developed at the same time as the Pathfinder mission Because Pathfinder was done on a (relatively) low budget, they used C because it was easier and cheaper to get C coders and compilers than Ada coders and compilers. Pathfinder was seen as the way of the future while Cassini was perceived as part of the stodgy (and expensive) past, so subsequent missions were built on top of the Pathfinder C code base and not the Cassini code base.

Ironically, it was the same event that killed Lisp which also killed Ada, though the effect was less direct. The Remote Agent was originally going to be the mainline software that controlled the entire DS1 mission. But when it became clear that the RA would not be ready in time, management decided to demote the RA to a flight experiment and adapt the Pathfinder software to run the DS1 mission. Because the Pathfinder mission itself was over, the team was available, while the Cassini team (the Ada folks) were still busy working on Cassini. By the time the Cassini mission ended [1] and the people with Ada experience became available again, C was already entrenched as the new de facto standard for slight software. The success of the subsequent Mars missions, and particularly the spectacular success of the Mars Science Laboratory EDL (which, I have to say, was freakin' amazing) further cemented the status of the Pathfinder approach to software development.

I have to give the C folks a lot of credit here: they have produced an awful lot of very reliable code for a very long time now. But I still think they're playing with fire.

[1] The Cassini software development team actually became available before the end of the mission, but they were still needed through the Saturn oribit insertion in 2004.

Actually have one more question if you don't mind - I've done a fair amount of both lisp and embedded (vxworks or baremetal). I've been tempted to push lisp or scheme as a prototyping environment for higher level (i.e., UI or some other non-RT) code. I've always had some amount trepidation due to GC pauses, and memory exhaustion.

Are there any papers on the actual lisp ports? Are there any gotchas?

> Are there any papers on the actual lisp ports?

No. The flight Lisp was just a commercial product: LispWorks. You can probably get detailed info from them. We also used CLisp and (what is now) Clozure Common Lisp for development.

> Are there any gotchas?

From Lisp? No, not really. In fact, I was pleasantly surprised at how easy it was to port the code from one Lisp to another. That part mostly Just Worked.

Thanks for the response!

You bet.

What do they use now?

AFAIK (I left JPL over ten years ago), mostly C.

I have seen your essays and finally bothered to look at your home page in your profile.

Now you work on SC4? And before JPL and other places of ill repute?

When do you kick back and put out low quality, lowbrow work? Haha.

I was curious to see Lexicons, and Ciel seems neat, now there is a buildup in systems programming in high level langs. GC-less and system-friendly Lisps are hard to come by, and sadly it seems like work on this stopped a while back.

Thanks for all your work, open and closed. I have enjoyed your essays and you seem to be giving us great stuff. Keep it up!

Thanks for the kind words.

> When do you kick back and put out low quality, lowbrow work?

I have gobs of "low quality, lowbrow work" which I don't publish. Too embarrassing.

But I kick back a lot. Lisp is a huge lever that allows me to appear a lot more productive than I really am :-)

Some of us can be unproductive, Lisp or not.

Despite all the jokes I can profer on HN in this trendy topic, some of us are destined to suck at programming, from Assemly to PHP to Datalog to J!

I suck at programming right now, and am sure that I will always suck to some extent. The trick is putting in the effort to suck LESS.

> some of us are destined to suck at programming

That sounds like a self-fulfilling prophecy.

I keep coming back, years later after avoiding a CS minor even, because the bruises on my ego from it being beyond me. I wonder which n+1 iteration will be the charm. Haha.

Have a look at this (please note that it's very much a work in progress):

https://github.com/rongarret/BWFP/

Feedback appreciated.

Try Scratch. MIT designed it for kids to do code like they play with legos. They proceeded to do amazing things with it.

https://scratch.mit.edu/

I am waiting for my son to grow up a little to play with it.

Honestly, I find a lot of this frustrating because I do not have a small goal. This week I came up with a few minor projects and will try to implement them in different languages if I have a chance, like an IP subnet calculator, and a reporting tool for maildirs on my computer. Trying to learn without simple goals has proven wasteful. I decided this last weekend to change course.

We shall see how it goes.

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.

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/ (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.

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.

On OpenVMS, Flex's Ten15, and Ada w/ middleware, it was common to use their cross-language, development support to code pieces of apps or systems in whatever language suited them. Then they smoothly integrated with varying performance effects. One could write the parts absolutely needing Java community in Java, integrate a middleware like ZeroMQ, and write the rest in a better language. Other stuff could be gradually ported if necessary to better language. Automated if a simple program.

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...

"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...

'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.'

To cite Brian Goetz (Java language architect) [1]: "It is totally in Oracle's self-interest for Java to remain vibrant. We have billions of lines of Java code. We have tens of billions of dollars a year in revenue from Java-based products. We employ 10-15 thousand Java developers. If Java were to become irrelevant we wouldn't be able to hire new developers, we would have to pay a lot of money to retrain those developers, we would have to rewrite billions of lines of code. Much better to make sure that Java remains a productive platform for development. And if it happens to benefit the rest of the world that's collateral damage."

[1]: https://youtu.be/Dq2WQuWVrgQ?t=56m14s

Oracle's plans for Java and the JVM are pretty open:

• In Java 9 modularise the platform, add a static linker, support new JIT compiler plugins with an advanced new compiler (Graal) as the first user, a whole other bunch of things.

• In Java 10 add value types, better generics, local type inference to the Java language, possibly a replacement for JNI/native code usage (Project Panama), a bunch of other things.

There are quite a lot of plans for Java actually, considering that it's not a profit center for Oracle.

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...

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.

Seems funny, considering Amazon's cloud is (as I understand it) heavily backed by Java. If there's a cloud to aspire to be, that's the one.

... And much of the rest of the code written these days: https://github.com/blog/2047-language-trends-on-github

If we're talking about the JVM, we must also include Clojure, Scala, Groovy, and any other JVM language code that would be killed if the JVM died.

If we're talking about the language, then the majority of Android and its app ecosystem are included.

Most importantly, don't forget that Java the specification is an open standard with dozens of runtime implementations and 7 compilers (not counting Google's). And the primary compiler, Sun's javac is GPL.

https://en.wikipedia.org/wiki/List_of_Java_virtual_machines https://en.wikipedia.org/wiki/List_of_compilers#Java_compile...

Let's not oversell that.

There are maybe in total 2 compilers out there which are still usable (i. e. not 10 years out of date and unmaintained).

The specification is "open" in the sense that you can't build your own implementation of Java without accepting a proprietary licensing agreement with Oracle (assuming you even get one).

The latter is not correct. You can do it and people have.

That's wrong. Feel free to present an example.

Android is one obvious example. GNU Classpath is another. Avian is another.

Sorry, but no. None of them can passed the JCK, which is a requirement to certify a Java implementation.

Your original statement was you can't BUILD an implementation without getting Oracle's blessing. Now you've switched to saying you can't CERTIFY which is a different claim.

I understand that you are trying to play semantics here, but in this case it doesn't work.

You can't BUILD an implementation of Java, because "Java" is defined by "passes the Java conformance tests".

You can build "something", but it won't be Java, so don't call it Java. Even Google understood that.

When comparing Java to C#, planned obsolescence is an appropriate euphemism.

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.

Or Oberon http://www.jucs.org/jucs_4_5/open_standards_beyond_java/Fran... (1998).

The tech was released in 1996:

http://www.modulaware.com/mdlt69.htm

https://github.com/Spirit-of-Oberon/Juice

https://github.com/berkus/Juice

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

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

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)

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.

Well we eventually also got Go, but it has its own set of issues.

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.

> 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/

> 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.

> 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.

LispWorks and Clozure CL are good non-emacs IDEs, and there are several others. I will agree that Emacs and Slime are pushed a little too hard sometimes.

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

That has not been my experience actually using Lisp for a number of projects. IME it's far more likely to support specific platforms (Linux, Windows, OSX, ...) than it is to support specific Lisp implementations. Even that is usually only because a required C library doesn't run on Windows or something like that, which is no different than Python, Java, or any other language.

No offense, but between your conclusions being incorrect and your phrasing ("I imagine..."), it sounds like you're hypothesizing without much actual experience writing Lisp.

Clozure CL's IDE basically is a clone of Emacs/Slime though -- you even send sexps from the Emacs-style editor to the repl via C-x C-e. Not that I mind it myself, but people who don't like Emacs wouldn't like it, I'd imagine.

That's slightly backwards.

The second Emacs (after TECO) was written in Lisp. On a Lisp Machine. Stallman later went for an Emacs, GNU Emacs, written on top of Lisp VM implemented in C. That one then got support for 'inferior' Lisps, external Lisp processes run from GNU Emacs. Extensive modes were ILISP and ELI. Slime is kind of a reimplementation of ILISP.

Clozure CL goes back to Coral Lisp, an early Lisp for the Macintosh, written in the mid 80s. Coral Lisp, and the Coral Common Lisp, and then Macintosh Allegro Common Lisp and then Macintosh Common Lisp all were written mostly in Lisp and had an Emacs-like editor (FRED - FRED Resembles Emacs Deliberately) included plus a bunch of tools: backtrace, inspector, interface designer, Editor-based Listener with REPL, etc. The main difference to GNU Emacs: it was focused on Common Lisp programming, it was implemented all in Common Lisp, it all ran in one application (no external Lisp), much of the tools made use of the GUI toolkit from the mac (menus, dialogs, buttons, copy/paste, AppleEvents, ...). MCL then was dead end, because it was tied to the old Macintosh libraries. OpenMCL was a fork initially thought to run on the spaceship mentioned before (but it was actually LispWorks, which was used for the spaceship). It was stripped down and ported to Unix or something similar. OpenMCL, later renamed to Clozure CL, was brought to the new Mac OS and got a simple IDE, but not based on the MCL code, but using some of its IDEs.

So Clozure CL's IDE goes back to the old MCL IDE and to Hemlock (the Emacs-like editor from Spice Lisp / CMUCL). It's not based on remote/external execution, like Slime.

Clozure CL's IDE is very simple, offers not many tools, and those tools are not really powerful. For MCL there were much better IDE tools developed. But MCL is gone.

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.

A tree view of the bazillion files in the typical Java project. (of course, if the project wasn't organized as one file per "design pattern" + domain part, each file of which has 1 or 2 executable lines nested within the required ritual...)

As well as a tree view of the properties and methods of the handful of "god classes" within said projects.

But seriously, on the plus side, IntelliJ is actually fairly usable in that you can quickly toggle on and off the supplemental info panels and just use the "distraction free" editor panel, particularly with the vim (key map) plugin (don't know if there's an emacs plugin).

I think Steve Yegge had a comment in one of his rants that IDEs have better support for languages that require IDEs :-)

There are tree views in emacs. Looks like the most popular is https://www.emacswiki.org/emacs/NeoTree.

Pretty sure I have seen similar things written for class views. I had one that was interactive view of javap's output. I liked that one pretty well. (I'm partial to anything that is just an interactive version of an existing cmd line.)

>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)

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.

I like IntelliJ, but I still spend time here and there window-shopping the settings and plugins. That seems to be the nature of things, regardless of the tool.

Take a look at what the Smalltalkers are up to these days, with custom visualisations for different classes:

http://gtoolkit.org/

I don't know how useful this is in practice, and it's not representative of what IDEs for mainstream languages are doing, but it's pretty cool.

You hit my fundamental problem. Specifically, "how useful this is in practice."

It makes for some awesome demos. But... so does https://www.youtube.com/watch?v=VEcobuYr5wg. I'm just not sure how practical this is.

Don't get me wrong. Sometimes, I do want to boot into IDEA for some of the refactor tools. If I truly used them enough, though, I would write one for myself in emacs.

> [emacs & slime]

I was not aware you have experience with both, I just tried to point out what most people use today. I did not intend to start yet another editor war, even clay tablets are fine with me :).

> If there are other CL's with ABCL's level of maturity on the JVM

My point is that the (virtual) machine does not matter at all. ABCL is just another CL and it should not be relevant except for when you are specifically looking into interfacing java libraries (for which one does not need a book, just a few paragraphs of docs).

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

Only to the point that you sometimes have to implement things for your current CL implementation (i.e. stuff not defined in the standard and for which no interop. libs exist - a pretty rare thing).

This is how the LispWorks IDE on ARM/Linux/Gtk+ looks, when displayed on a Mac X11 server: https://pbs.twimg.com/media/CoufhEFUkAExgqe.jpg:large

https://pbs.twimg.com/media/CouoF9DVUAUUhg1.jpg:large

On the Mac using native Cocoa:

https://pbs.twimg.com/media/CouqqaLVIAA4DRU.jpg:large

I love emacs, but I must admit that slime is not very appealing to me. I can not stand the lack of readline in the repl.

emacs + slime + semantic + srefactor

The last two are game changers.

>emacs & slime

Yeah, no. We had Lisp Machines and Smalltalk environments in the 80s, why would we go back to something so crude in 2016?

And Java IDEs are somehow comparable to Lisp Machines or Smalltalk IDEs? Slime is much more similar to those environments than Eclipse.

Eclipse is derived from VisualAge for Java, which was derived from VisualAge, which was a Smalltalk IDE.

There are a few remnants - the Java Browsing perspective [1] is basically the classic Smalltalk browser [2], which is still there in modern Smalltalk [3]. The only people i've ever seen using it are old Smalltalkers who have reluctantly come over to Java!

[1] http://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse....

[2] http://www.abclinuxu.cz/images/clanky/krivanek/smalltalk-80-...

[3] http://files.pharo.org/media/pharoCheatSheet.pdf

> The only people i've ever seen using it are old Smalltalkers who have reluctantly come over to Java!

I also use it occasionally.

Then again, I used Smalltalk on an university project before Java was announced to the world. :)

>And Java IDEs are somehow comparable to Lisp Machines or Smalltalk IDEs?

Well, when it comes to editing Java, they're leaps and bounds above Emacs for the same task. If they offered the same flexibility and power for Lisp, Emacs/Slime would not even compare.

(And Eclipse is a descendant of a once-popular Smalltalk IDE).

Exactly, anyone building a VM-based system would do well by taking a good look at Smalltalk (past and present implementations) and Erlang to see what a VM-based environment can do before they reduce the feature set to that of what's available in browsers (or less).

This is one reason I dislike ChromeOS.

Google could have leveraged Dart with Dartium and created a Smalltalk like environment, instead we got just yet another browser based OS.

Apparently developers of GUIs like HTML+CSS, so that may be one reason. I never liked browsers as application engines too much, because I've grown up with demo scene mags on floppy disks that had their browser-like engines with all kinds of multimedia features that ran on standard PCs, not just Amiga with custom multimedia chips. As a result, it's painful to watch how much hardware we waste when running Electron, Instagram, Gmail, Java IDEs, etc.

I fully agree with you.

I was an avid collector of Hugi.

Also was a bit disappointed to see Java and .NET follow the VM route when we had Oberon, Modula-3, Delphi, Ada ,Eiffel among many others.

At least their designers seem to finally willing to offer the same kind of toolchain, instead of having us rely on third parties for those features.

> At least their designers seem to finally willing to offer the same kind of toolchain, instead of having us rely on third parties for those features.

What do you mean?

I mean Oracle's plans to eventually have AOT on the JDK instead of having us buying Excelsior JET, J9 or whatever.

Similarly Microsoft's efforts regarding MDIL cloud compiler, .NET Native and CoreRT.

Every time I see that suggestion I wish people actually had some experience with what Lisp Machines allowed, or at very least worked with what is left of them, commercial Common Lisp environments.

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

> emacs & slime[1]

Here the Windows support (important if you want to target a larger audience) is really bad.

Have you tried it? I use Emacs+SLIME+ClozureCL on Windows without problems. It mostly worked out of the box, I think I had to tell SLIME where to find ClozureCL but that was it.

Well I did and I found that ClozureCL+Emacs+Slime on Windows ( all latest versions as of today ) do not support the "step command" and I find this an annoying deficiency. Apparently none of the major open source CL implementations on Windows does.

> Have you tried it?

At least I tried out Emacs on Windows (from Cygwin) a few years ago.

Cygwin itself is a huge mess and a big compatibility problem, and it's not really fair to blame those issues on any particular software distributed by Cygwin.

Emacs has a perfectly good native Windows build available on its download page, and it works great and it supports Slime just fine.

Having a Lisp implemented in the JVM has its advantages, but also its downsides. For one, all these libraries available for the JVM are targeting Java, not Lisp. This means that they are expected to be used as Java objects, not as part of a Lisp program that follows a more functional style. The result is that you lost a great part of the advantage of using Lisp, since you're forced everywhere to make concessions to the OO programming style when using these libraries.

what do you think about clojure ?

I've never tried clojure; it looks interesting, though different from Common Lisp. I have invested some time--though not a lot--in Common Lisp and enjoyed it.

I would like to actually use CL for something. Unfortunately, my feeling was that the infrastructure--especially for GUI's--wasn't there the way it is with lots of other languages and that was a real deal breaker. In this, I don't believe I'm alone.

Armed Bear Common Lisp already exists. The JVM with all its libraries exists. Common Lisp on the JVM seems like an easy win-win to me, but I would like to see somebody really proficient in CL explore that in depth first.

There are several GUI libraries for CL.

The best and most complete is Qtools (and CommonQt), which wrap Qt. IMO it makes Qt development easier in Lisp than it is in C++. Installation on Linux is super easy, just make sure the Qt libs and dev libraries are installed from your package manager, and then install with QuickLisp. On OSX it was tricky installing the Qt libs, but after that installing with QuickLisp just worked. I haven't tried on Windows, but supposedly it works for people. https://github.com/Shinmera/qtools

I've also used ltk a few times, and it's okay, but it's wrapping Tk, so ...

I think there are also interfaces for wxWidgets and Gtk, but I've always liked Qt, so I haven't looked very hard.

racket has some nice gui libraries.

Or perl6 on jvm

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.

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

Did Google? Google is very much a polyglot orginization. https://www.quora.com/Which-programming-languages-does-Googl...

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

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.

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.

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

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.

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.

Hmmm, this seems like it merits replication.

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

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.)

Reply on news.ycombinator.com