Comment Lisp and Java are both good langauges (Score 3, Insightful) 372
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
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
