Lisp as an Alternative to Java

Joseph Dale writes "Lisp as an Alternative to Java is a detailed and well-reasoned study comparing Lisp to Java and C++ in terms of execution time, memory consumption, and developer effort. The author, Erann Gat, was the principal software architect for the Mars Science Microrover, the prototype for the Mars Pathfinder rover."

Comments

I'm a professional who uses Java

[under_score]

This is quite an interesting study. I use java professionally for most things that I do (I have also used C, Objective-C and a few others in the past). I have had to work with lisp a bit. Of course I took a lisp oriented AI class in school, but since then I have also had to do some porting from lisp to Java! Perhaps it was just a factor of the people who developed the lisp code, but I found it incredibly difficult to read - and my complaint wasn't with the nesting of parentheses. It wasn't strongly typed (is there such a lisp?) and the singular type of syntax (lists) make many aspects of the code difficult to unravel. That said, there are some things I really like about lisp, in particular its dynamic nature where you can build lisp functions at runtime and execute them at runtime. Sometimes I really wish I could do this easily with Java (its possible to do, just a huge pain in the butt). I think the real issue right now is that Java (and C++) are used in the "real world", whereas lisp is mostly isolated to academia. The article point this out. I've used Java for huge projects because it is no longer considered a risky language by large organizations. For whatever reason, lisp has not developed such a reputation. Does lisp have application servers? Does lisp has db connectivity? Does lisp have CORBA bindings? Does lisp have asynchronous messaging? Does lisp have naming and directory bindings? Does lisp have web page templating functionality? I'm sure all that stuff could be built, but I doubt most of it exists right now. Therefore, lisp is not acceptable for corporate use at this time.

Re:I'm a professional who uses Java

[Lambdaknight]

> Does lisp have application servers?

Yes

> Does lisp has db connectivity?

Yes

> Does lisp have CORBA bindings?

Yes

> Does lisp have asynchronous messaging?

Yes

> Does lisp have naming and directory bindings?

Yes

> Does lisp have web page templating functionality?

Yes.

Two points more:

1. Doubt is not knowledge. Many people THINK they know about the popularity of Lisp because they don't hear as much about it as they hear from the hype languages (which is quite logical).

There are far more Lisp projects going on than people imagine, only people don't scream out "HEY! COOL! I'M DOING IT WITH LISP!" they go "Yepp, I'm using Lisp." the Yahoo Store engine for instance. Microsoft's Bob. Many industrial applications (not only the academia!).

2. The syntax isn't hard to read, it's just hard for people not used to it. This is, of course, true for every language.

Besides: Common Lisp is not strongly typed but you can strongly type a specific function by declaring what types the arguments will have. That makes Lisp a "strong typing on demand"-language in my point of view.

Re:I'm a professional who uses Java

[Lambdaknight]

Well, people don't know it or have prejudices against it like you. And there's noone hyping it to the end.

The reason why it's not hyped is because Lisp HAD a hype in its history whose decline happened to the same time (and was mostly induced by) the AI winter.

Most Lisp programmers from that time have still a bad taste in their mouths because of that hype (mind, that the hype was over was not because Lisp is a bad language but because the AI winter) so they won't start another.

Younger Lisp programmers (like myself) are both happy and unhappy about the lack of a hype.

Happy because that means you have a much more undisturbed basis on which you can settle your community. The community efforts and activities are easily overseeable and you always know what's going on.

Unhappy because the community isn't very large and so activities DO happen, but more slowly than in the Java or Perl community because we have fewer people.

As an example: that article is from 1999 and is widely known in the Lisp community... but only today it has been published on Slashdot.

If someone writes an article about Perl, it is released immediately here.

Keep in mind that 2 years are an eternity in computer terms.

Re:It's about the API

[redhog]

Nahnah. You haven't touched a LISP the last 20 years or so, have you? There's a popular LISP dialect called Scheme. It has a huge function library called slib, and there are bindings for a hell lot of C libraries for Scheme (it is also very easy to create new such bindings for most implementations of scheme).

Interesting, but flawed?

[tkrotchko]

Its interesting to see the results of a short study, even though the author admits to the flaw in his methodolody (primarily the subjects were self-chosen). Still, I don't think that's a fatal flaw, and I think his results do have some validity.

However, I think the author misses a more important issue: development involving a single programmer for a relatively small task isn't the point for most organizations. Maintainability and a large pool of potential developers (for example) are a significant factor in deciding what language to use. LISP is a fabulous language, but try to find 10 programmers at a reasonable price in the next 2 weeks. Good luck.

Also, while initial development time is important, typically testing/debug cycles are the costly part of implementation, so that's what should weigh on your mind as the area that the most gains can be made. Further, large projects are collaborative efforts, so the objects and libraries available for a particular language plays a role in how quickly you can produce quality code.

As an aside, it would've been interesting to see the same development done with experienced Visual Basic programmer. My guess is he/she would have the lowest development cycle, and yet it wouldn't be my first choice for a large scale development project (although at the risk of being flamed, its not a bad language for just banging out a quick set of tools for my own use).

Some of thing things I believe are more important when thinking about a programming language:

1) Amenable to use by team of programmers
2) Viability over a period of time (5-10 years).
3) Large developer base
4) Cross platform - not because I think cross-platform is a good thing by itself; rather, I think its important to avoid being locked-in to a single hardware or Operating System vendor.
5) Mature IDE, debugging tools, and compilers.
6) Wide applicability

Computer languages tend to develop in response to specific needs, and most programmers will probably end up learning 5-10 languages over the course of their career. It would be helpful to have a discussion of the appropriate roles for certain computer languages, since I'm not sure any computer languages is better than any other.

There is more data available for other languages..

[crealf]

The article about Lisp is a follow-up of an article by Lutz Prechelt in CACM99 (a draft is available on his page along with other articles).

However there is more data now, as, Prechelt itself widdened the study, and published in 2000 An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl (a detailed technical report is here).

If you look, from the developer point of view, Python and Perl work times are similar to those of Lisp, along with program sizes.
Of course, from the speed point of view, in the test, none of the scripting language could compete with Lisp.

Anyway some articles by Prechelt are interesting too (as many other research papers ; found via citeseer for instance)

Re:It's about the API

[gawi]

From what I've seen of SLIB, it is not comparable with the Java 2 platform (standard edition) version 1.4. :

Threads

I/O (blocking or non)

Reflection API

Weak references (and the likes)

Networking (including http client, ipv6 support, URLs, datagrams, network interface)

RPC (RMI, CORBA)

Security (permission, keys)

Relational database API (implemented by MANY vendors, you can often *choose* your implementation...)

Text formatting

Data structures (OK, needs functional improvements, I agree)

Useful classes: date, calendar, locale, time zones, currency, timer...

Logging

Regexp

Zip

Preferences

Accessibility

Imaging API

Naming API (directories, ldap)

Printing API

GUI API (awt, Swing)

XML parser + DOM + SAX

XSLT

Components (java beans)

Sound

Should I continue with enterprise edition?

I think no langage can compete with Java in terms of API richness and uniformity.

Re:It's about the API

[Wavicle]

He was comparing apples to oranges near as I can tell. I can't actually read the original paper so it is kind of hard to tell, but the Lisp group was all self selected experts. Read carefully the stated problem and explain to me how anyone could take 63 hours to complete it in Java? The average experience of their Java sample set was 7.7 years!?!!!!! Didn't Java come out in 1995? Where did they find a panel of OAK seed developers? After re-reading that section it looks like he interchanges "years of programming experience" with "years of experience in that language". So why weren't we given the average number of years with experience in that particular language?

Secondly he was using a task which Lisp is very good at, and well optimized for - list processing. People working in Lisp tend to be well exposed to this kind of problem.

Why Java succeeded, LISP can't make headway now

[joneshenry]

Java was never marketted as the ultimate fast language to do searching or to manipulate large data structures. What Java was marketted as was a language that was good enough for programming paradigms popular at the time such as object orientation and automatic garbage collection while providing the most comprehensive APIs under the control of one entity who would continue to push the extension of those APIs.

In this LinuxWorld interview look what Stroustrup is hoping to someday have in the C++ standard for libraries. It's a joke, almost all of those features are already in Java. As Stroustrup says, a standard GUI framework is not "politically feasible".

Now go listen to what Linux Torvalds is saying about what he finds to be the most exciting thing to happen to Linux the past year. Hint, it's not the completion of the kernel 2.4.x, it's KDE. The foundation of KDE's success is the triumph of Qt as the de facto standard that a large community has embraced to build an entire reimplementation of end user applications.

To fill the void of a standard GUI framework for C++, Microsoft has dictated a set of de facto standards for Windows, and Trolltech has successfully pushed Qt as the de facto standard for Linux.

I claim that as a whole the programming community doesn't care whether a standard is de jure or de facto, but they do care that SOME standard exists. When it comes to talking people into making the investment of time and money to learn a platform on which to base their careers, a multitude of incompatible choices is NOT the way to market.

I find talking about LISP as one language compared to Java to be a complete joke. Whose LISP? Scheme? Whose version of Scheme, GNU's Guile? Is the Elisp in Emacs the most widely distributed implementation of LISP? Can Emacs be rewritten using Guile? What is the GUI framework for all of LISP? Anyone come up with a set of LISP APIs that are the equivalent of J2EE or Jini?

I find it extremely disheartening that the same people who can grasp the argument that the value of networks lies in the communication people can do are incapable of applying the same reasoning to programming languages. Is it that hard to read Odlyzko and not see that people just want to do the same thing with programming languages--talk among themselves. The modern paradigm for software where the money is being made is getting things to work with each other. Dinosaur languages that wait around for decades while slow bureaucratic committees create nonsolutions are going to get stomped by faster moving mammals such as Java pushed by single-decision vendors. And so are fragmented languages with a multitude of incompatible and incomplete implementations such as LISP.