Slashdot Mirror
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."
I don't care if LISP runs 500 times as fast as Java. It has a massively restricted API. People don't base their language choice on speed anymore. FORTRAN is still twice as fast as C, but everyone still uses C, for two reasons: FORTRAN is harder to learn, and C has more libraries.
Java's great strength is that it has a huge set of APIs, all in a unified form, making programming a less repetitive and painful experience. Java is for people who understand that recoding the same search tree three hundred times is not going to make them richer, cooler or a better programmer. LISP is for people with time to waste.
Denial isn't just a river in Italy
Just like BeOS was fast as hell, it didn't matter much because 5 people used it (sorry, Be people).
If you can create a language that will execute faster within the JVM, for example (hypothetical here), then you'd have something. Speed is relatively minor thing, and unless you code for compatibility, it won't matter how fast your stuff runs (or can be developed).
Programming in LISP is a breeze, Java slightly less so (at least in my mind). But what about maintenance? Other people debugging your code? Have you ever had the misfortune of modifying a poorly documented LISP program? It's a good deal harder to do than for a poorly documented Java program.
Give them an inch and they'll take a foot. Much more than that, you won't have a leg to stand on.
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.
Helping with organizational effectiveness is our job.
That was written in 1999...
One would be able to suggest that things have changed a little since then..
Although java does use lots of memory..
But it is no longer as slow..
... although I also like C#..
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.
You were mistaken. Which is odd, since memory shouldn't be a problem for you
Yes.
Read "Structure and Interpretation of Computer Programs" by Abelson and Sussman.
It is a fabulous book for introduction into functional thinking and shows many enlightening things about what you can do with Lisp in general and in this case Scheme.
Your next step might be "ANSI Common Lisp" by Paul Graham, giving an introduction into the Lisp dialect with which major applications in the industry are done (REALLY done, Franz Inc. and Xanalys, both commercial Lisp implementors and vendors have increasing sales over the years) - also a very clear and easy to follow book with lots of examples and exercises and a very cool reference which I tend to use a lot while Lisp coding.
If you prefer online information, you can find many links and pointers to Lisp on the webpage of the Association of Lisp Users (ALU, http://www.alu.org).
(Yes, I'm paid to code in Lisp)
(Yes, it's a lot of fun)
-- Beware the Jabberwock, my son!
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)
Personally, I love LISP and Scheme. Their simple syntax makes far more sense to me than other languages.
I think it's a classic cognitive dissonance effect that causes programmers of other languages to complain - they've spent so much time learning their pet language's wierd syntax that to admit that lisp is easier is to devalue all that effort - and no-one likes to admit they've been wasting their own time, just like windows programmers who've wasted 2 years of thier life learning the intricacies of win32, or x86 asm coders who can't admit how awful x86 asm is compared to PPC or m68k asm.
Then again, there's a theory somewhere on the net that programming language preferences are influenced by the programmer's native natural language - I was raised partly in an Irish-speaking environment, so lisp may just naturally make more sense to me, due to the different structure of irish sentences.
Choice of masters is not freedom.
Lisp is okay. The syntax is trivial but over the years it has evolved some good libraries and it is reflexive.
You can use lisp to write/generate lisp code which you can then interpret/compile and execute. The problem comes from the architecture of the VM. It was not fundamentally designed with objects and message passing in mind.
Prolog has a similar simple syntax but its VM is designed completely differently.
From that respect, the Smalltalk VM is closer to the paradigm.
While all three have had time to mature and evolve over the decades of their existence, Smalltalk has the most usable and extensive libraries to date.
Smalltalkers find Java class libraries "quaint."
That said, Smalltalk is still flawed because it is container based and the contained don't know they are contained unless explicitely made aware of the fact.
This is its major flaw, as a brick in a wall can make amply clear, its in a wall and its held there. The wall is the aggregate of the relationships between the bricks.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
I have written 2 Lisp books for Springer-Verlag and 4 Java books, so you bet that I have an opinion on my two favorite languages.
First, given free choice, I would use Common LISP for most of my devlopment work. Common LISP has a huge library and is a very stable language. Although I prefer Xanalys LispWorks, there are also good free Common LISP systems.
Java is also a great language, mainly because of the awesome class libraries and the J2EE framework (I am biased here because I am just finishing up writing a J2EE book).
Peter Norvig once made a great comment on Java and Lisp (roughly quoting him): Java is only half as good as Lisp for AI but that is good enough.
Anyway, I find that both Java and Common LISP are very efficient environments to code in. I only use Java for my work because that is what my customers want.
BTW, I have a new free web book on Java and AI on my web site - help yourself!
Best regards,
Mark
-- www.markwatson.com -- Open Source and Content
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.
You make a good point when you ask "Whose Lisp?" Lisp is a family of languages. Common Lisp, which is arguably the leading dialect now, has major flaws. It was designed by a committee, and not especially liked even by them. Common Lisp is like a big ugly old wrestler: powerful but lumpy and ill-mannered (i.e. impolite to the OS and other applications).
Disputes about Lisp are often about two different things. Those who attack Lisp are usually attacking Common Lisp. Those who defend Lisp are usually defending Lisp, the family.
Lisp the family sounds like a vague concept, but there is a solid core there. You could approximate it as either Common Lisp minus the crap, or as Scheme (another family member) plus more data structures and libraries.
Lisp would certainly look better if it had a better representative to send to the Language Beauty Contest than the lumpy old wrestler. It is about time someone made a nice new dialect. In the meantime I'll still take the wrestler over the alternatives, but the price I have to pay is using a language that is considered unfashionable.
In response to the discussion of the paper "Lisp as an Alternative To
Java" by Erran Gat, 1999:
I have a lot of experience with both Common Lisp and Java. I like
both langauges. Although I spent many years of my life as an
enthusiastic Lisp booster, if I were to start a new project now, under
most circumstances that I can imagine, I would select Java. But the
reasons don't have that much to do with deep programming language
concepts. (More about my credentials later.)
In the following, when I say "Lisp" I mean "contemporary Common Lisp
including CLOS" if I don't say otherwise. I talk about Lisp as it is
now. Lisp's history is an interesting subject but quite irrelevant to
the questions brought up by the paper.
>> The Erran Gat paper of 1999
The experiment and results in this paper don't persuade me of
anything. The programmers were self-selected; the Java programmers
were apparently quite inexperienced; the sample size is just too
small; judging a whole langauge based on a single programming problem
is too narrow. A small programming exercise like this tests only a
small fraction of the interesting aspects of programming.
The paper is valuable in that it makes you think harder about the
"which langauge is faster" question. Remember, langauages don't have
speeds; langauge implementations have speeds. And what you have heard
may not be true. Be skeptical of "common wisdom" about what's slow
and what's fast; such "common wisdom" is often outdated, limited to
particular contexts, or just plain wrong.
>> Why isn't Lisp more popular?
A language's popularity is strongly influenced by "network effects":
that is, as more people use a language, it becomes more desirable to
use. It is hard for a new language to "break through", and once it
does there is a strong positive-feedback effect. Breaking through is
very difficult and depends a lot on timing, luck, and often on
forceful publicity and marketing.
Java managed to do it, due to a confluence of many factors. It was in
the right place at the right time. Java's early success had a lot to
do with the rise of the World Wide Web, the decision of Netscape to
incorporate Java into their browser, the politics of Microsoft's entry
into the Internet area, the use of Sun's marketing resources, Sun's
decision to give out the implementation for free, and many other
factors on top of the technical merits (and demerits) of the language
and its then-available implementation.
Lisp's attempts to break through didn't succeed because the right
confluence didn't happen, partly due to luck and partly due to
ineptness of all of us who were hoping to promote it. It did not help
that Lisp was marketed primarily on the coat-tails of the "AI
industry" of the 1980's, which did not succeed as an industry
(although many parts of the AI technology are alive, well, and making
money today). It was also hurt by claims that Lisp could only run
well on special-purpose hardware, by its unusual syntax that puts off
so many people initially, by the lack of good free implementations (at
the time); I could go on and on.
It has helped Java's cause that there is one organization promoting
and defining the langauge and establishing standard API's in so many
areas. Many Lisp enthusiasts put their energy into refining and
improving the language (resulting in excellent technology such as
Scheme and Dylan) rather than all concentrating on stabilizing and
developing one standard.
The extensive set of standard API's created by Sun and the Java
Community Process is very valuable. There just isn't any Lisp
equivalent standard API for JMS, JDBC, Enterprise JavaBeans, and so on.
The positive-feedback "network" effects is extremely valuable to
Java's cause. It's much easier to find trained Java programmers than
trained Lisp programmers. All kinds of tools and libraries are
available (many free), many more than for Lisp. There are lots of
books available about Java, so many that even the subset that are
*good* books is pretty large, and not just the core Java language but
facilities such as RMI, Enterprise JavaBeans, JDBC, JMS, and on and
on.
For example, there are many commercial producers of messaging
subsystems that implement the JMS specification, and competition
between them is driving higher functionality and lower prices.
There's nothing like that going on for messaging subsystems and Lisp.
This has nothing to do with any technical features of Java and Lisp as
languages.
>> Lisp as a General-Purpose Language -- Lisp is not "exotic"
"Lisp" means different things to different people. If you read "The
Structure and Interpretation of Programming Langauages", you're going
to see Scheme code that is fundamentally different from the way code
looks in most langauges. I think this is all extremely interesting
and valuable, but it's not what I have spent my time on.
To me, Lisp is general-purpose programming language in which I have
done all kinds of system programming. In my experience, Lisp is a lot
less "exotic" than some people might expect. For example, the whole
"Lisp is functional, not procedural" business is largely irrelevant.
The control structure and overall organization of a program in Common
Lisp is extremely similar to that of a Java or C++ program. All these
languages have subroutine calling, object-oriented programming,
iteration, recursion, data structures, structured programming,
exceptions, multithreading, etc.
Any claims that groups can't program in Lisp, or that Lisp programs
are inherently unmaintainable, are nonsense. There is nothing about
writing a program in Lisp that makes it harder to maintain than a
program in C++ or Java.
>> Static Typing
Static typing is one of the biggest differences. I agree that Common
Lisp basically does not have static typing (yes, I know about
"declare"). Some languages have static typing that is so restrictive
that it seriously gets in the way of getting useful work done, and in
the Old Days we of the Lisp world were very much reacting to
constricting type systems. I am pretty happy with the Java concept of
types, which I feel provides useful expression of intent in the code,
and useful compile-time error checking, and doesn't get in your way
very much. The parameterized typing coming to Java (in JDK 1.5, last
I heard) should improve the situation further. Still in all, it's not
that big of a deal, and if I went back to using Lisp without static
typing I don't thihk my life would be all that different.
>> Parentheses and Macros
Lisp's unusual syntax, with the parentheses and what used to be called
"Polish notation" (i.e. no infix operators), bothers some people. It
looks unusual and unwieldy to those who are unaccustomed to it.
However, once you get used to it, and if you use a decent programming
environment (particularly a text editor that can "indent for Lisp" and
otherwise knows Lisp syntax, such as but not necessarily Emacs), you
quickly get used to it and it seems perfectly normal. (It is also
possible to make a Lisp-family langauge with a more conventional
syntax, as the Dylan designers decided to do.)
Lisp's ayntax allow programmers to see programs in the form of a
simple data structure, which is the basis upon which is built the Lisp
"macro" facility, one of the truly different and powerful features of
Lisp. Lisp macros make Lisp an extensible language, in profound sense
of the word "extensible". They are a form of programming abstraction
that, properly used, can help make complex systems more simple and
understandable. Now that I used Java, I do miss Lisp macros. On the
other hand, it turns out it's not such a big deal, and if I had the
power of Lisp macros in Java it would not really change my life all
that much.
>> My Experience
Lisp: I wrote the first Emacs-written-in-Lisp (known variously as
EINE, ZWEI, and Zmacs). It was in fact the second Emacs ever,
developed concurrently with the original Emacs (written in TECO). I
have also written in Lisp an interactive debugger, a local area
network control program, a compiler, and an object-oriented database
management system. I worked with small and medium-sized groups. I
maintained lots of code written by people other than myself. I was
one of the five co-authors of "Common Lisp: The Language". I used
Lisp, in an implementation that eventually evolved into Common Lisp,
between 1976 and 1988.
Java: I was one of the reviewers of "The Java Language Specification".
I edited early drafts for Bill Joy and Guy Steele Jr. I co-wrote the
Java part of the ObjectStore database management system, and a
transactional data manager called "PSE Pro for Java", both from Object
Design. Currently I am developing business-to-business integration
software in Java at the same company, now known as eXcelon. I have
been using Java since early 1996. (In between I did C++.)
I'd like to go into the question of development environments but this
is long enough as it is. In a nutshell, I really wish I had my good
old Lisp Machine development environment again; what I'm using for
Java nowadays is stone knives and bearskins.
-- Daniel Weinreb
dlw@exceloncorp.com