Your comparison is badly biased. In the Java code you put
the * on a separate line and in the Lisp code you didn't.
If you had done so in the Lisp code and had indented
correctly, as any good Lisp programmer would, they would be
equally readable.
I disagree with "Deeply nested code and structures are confusing.
Flatness is good". Too much of either one is a bad.
You seem to be assuming that Lisp LOC are longer than Java
LOC. That certainly hasn't been my experience, having done
a lot of programming in both languages. Quite the opposite.
There is no inherent link between s-expressions
and the powerful Lisp macro facility. It is
certainly easier to implement with s-expression
syntax, but can (and has) been done in languages
with infix syntax. See Dylan for example, and Java Syntax Extensions. While neither of these implementations allows using the full power of the language to generate code (i.e., procedural macros), there's no reason that couldn't also be done in an infix language.
1) Is lisp less amenable to use by a team? Can't you implement one object while I implement another? I'm asking because I don't know; all my programming has been for my own research.
If anything I think Lisp is more amenable to teamwork, if only because it doesn't dictate file/directory organization. I use Lisp in a small team (4 people) environment every day. On the other hand, it doesn't enforce quite as clearly defined APIs as does Java (with interfaces and public/private modifiers) so your team needs to be a bit more disciplined.
Actually, if Lisp has one major flaw it's that it allows too much flexibility. That, combined with the fact that a lot of Lisp hackers (I've worked with a lot) are extremely bright, can make it hard for us mere mortals to grok their code.
5) I really don't know what an IDE is. I gather it is something other than emacs, since emacs supports nearly every language, some
wonderfully well (try ESS for R). I really can't comment on this one at all; perhaps someone else could?
Lisp certainly has mature IDEs. The debugging environments in LispWorks, Macintosh Common Lisp, and Dylan are leaps and bounds above anything I've seen for Java or C. However, they do not tend to be so great at stepping through compiled code at the source level. (Dylan does not share this problem. Also I think this is less necessary in Lisp due to other debugger features.) They also tend to lack decent GUI builders though there might be something out there I'm not aware of.
[Sorry if someone said this already. Slashdot organization seems pretty unintuitive to me.]
I just want to point out that almost all modern Common Lisp systems are fully compiled. Even the code you type into the listener on the fly gets compiled to core. Lisp interpreters are relatively rare. (Maybe Scheme interpreters are more common though.)
Lisp does not have the concept of public/private/protected access to code. It does have packages, however, and you can use them to modularize your code. You explicitly export the API from a package. There is a "back door" for programs to use code in other packages even if it's not exported, but code that does that is easy to spot.
Dylan is a descendant of Common Lisp and Scheme that has cleaned up some of the warts in CL and uses a C/Pascal-like syntax. Dylan enforces encapsulation via modules. Note that these languages have no such thing as "class scope", and that is a Good Thing, in my opinion.
While I would prefer something like BRL over JSP simply because it's Scheme, I have to say that it seems to emulate one of JSPs worst traits: embedding program code in HTML. This is super convenient, and if used sparingly can be fine, but it'll be a pain when you start hiring content editors who don't have a clue about programming. (I know, in a perfect world we wouldn't hire such losers, but...) Mixing program logic and HTML seems to be strongly encouraged in BRL.
I prefer keeping the logic separate and using tags (e.g., <jsp:show-user-name/>) to call program code. It's a bit more hassle for the app programmer, but a lot easier for content editors to deal with. (And how many programmers do you know that want to also be content editors on a production web site?)
Right on the money, honey. I work at a company that has an e-commerce web site written in Common Lisp. When we got VC funding one of the requirements was that we eventually rewrite the whole thing in Java. Not for technical reasons, but because of their fear that we wouldn't be able to find enough good Lisp programmers. Well, we hired a boatload of Java programmers. They got approximately nothing done in about a year. We four Lisp hackers kept the site from grinding to a halt while they spent our money on Java dreams. VCs pulled out, we got rid of the Java programmers (and marketing spend-thrifts), we decided to continue with the conversion to Java, we generated 50K lines of Java code from the Lisp introspection facilities, we found that we had 10x code bloat in Java, dumped java, yay, back where we started, actually improving the site now!
One striking thing was the complete lack of interest most of the Java programmers seemed to have in learning anything about the Lisp code. I guess they thought "how is this going to help my career"?
Lisp is perfectly suited to web applications. Since it's mostly just application logic and sending bits out the wire, Lisp's ability to change code on the fly without restarting app servers and such is a huge win, especially since a web site often requires frequent, small updates.
Yes, Common Lisp has application servers (at least private ones like the one I work with). Yes, Common Lisp has DB connectivity. Yes, it has CORBA bindings. Dunno about asynchronous messaging, but I suspect it's a buzzword for something that we Lispers don't even glorify with a name because it's so easy to implement. I personally wrote a web page template system in about a day in Dylan, a Lisp descendant. No biggy. And it's much easier to use than JSP.
One of the beauties of Common Lisp is precisely that it supports both OO and functional (in the loose sense) styles of programming well. It supports each better than Java does. Common Lisp is Object Oriented, while Java is Object Obsessed. Common Lisp's object system is basically a superset of Java's. You could limit yourself to programming in a Java style in CL, but why would you want to?
Almost any language with functions/methods can support functional programming (in the loose sense) to some degree. Some encourage it more than others. Java discourages it by, for example, not allowing true first class functions/methods, by having many constructs such as IF that don't return values, by insisting that every single bit of code must belong to a single class, etc.
I agree to some extent that the set of available libraries is often the most important thing when deciding on a language for a project. Many of the Java APIs are made unnecessarily complex due to limitations of the language. But there sure are a lot of them.
It's not clear to me why you didn't use data structures in your Lisp program and did in your C++ program. If you're talking about Common Lisp then you could have used defclass or defstruct to define structures, or you could have written your own ADTs with a built-in type and accessor functions. Whahappen?
Slashdot Mirror
Your comparison is badly biased. In the Java code you put
the * on a separate line and in the Lisp code you didn't.
If you had done so in the Lisp code and had indented
correctly, as any good Lisp programmer would, they would be
equally readable.
I disagree with "Deeply nested code and structures are confusing.
Flatness is good". Too much of either one is a bad.
You seem to be assuming that Lisp LOC are longer than Java
LOC. That certainly hasn't been my experience, having done
a lot of programming in both languages. Quite the opposite.
There is no inherent link between s-expressions
and the powerful Lisp macro facility. It is
certainly easier to implement with s-expression
syntax, but can (and has) been done in languages
with infix syntax. See Dylan for example, and Java Syntax Extensions. While neither of these implementations allows using the full power of the language to generate code (i.e., procedural macros), there's no reason that couldn't also be done in an infix language.
Actually, if Lisp has one major flaw it's that it allows too much flexibility. That, combined with the fact that a lot of Lisp hackers (I've worked with a lot) are extremely bright, can make it hard for us mere mortals to grok their code.
Lisp certainly has mature IDEs. The debugging environments in LispWorks, Macintosh Common Lisp, and Dylan are leaps and bounds above anything I've seen for Java or C. However, they do not tend to be so great at stepping through compiled code at the source level. (Dylan does not share this problem. Also I think this is less necessary in Lisp due to other debugger features.) They also tend to lack decent GUI builders though there might be something out there I'm not aware of.I just want to point out that almost all modern Common Lisp systems are fully compiled. Even the code you type into the listener on the fly gets compiled to core. Lisp interpreters are relatively rare. (Maybe Scheme interpreters are more common though.)
My only complaint now would be that BRL probably won't play well with other tools like XML translators, etc. But it looks pretty cool.
Dylan is a descendant of Common Lisp and Scheme that has cleaned up some of the warts in CL and uses a C/Pascal-like syntax. Dylan enforces encapsulation via modules. Note that these languages have no such thing as "class scope", and that is a Good Thing, in my opinion.
I prefer keeping the logic separate and using tags (e.g., <jsp:show-user-name/>) to call program code. It's a bit more hassle for the app programmer, but a lot easier for content editors to deal with. (And how many programmers do you know that want to also be content editors on a production web site?)
I completely agree with everything you've said. I wish I had a clue how management made their decisions.
Right on the money, honey. I work at a company that has an e-commerce web site written in Common Lisp. When we got VC funding one of the requirements was that we eventually rewrite the whole thing in Java. Not for technical reasons, but because of their fear that we wouldn't be able to find enough good Lisp programmers. Well, we hired a boatload of Java programmers. They got approximately nothing done in about a year. We four Lisp hackers kept the site from grinding to a halt while they spent our money on Java dreams. VCs pulled out, we got rid of the Java programmers (and marketing spend-thrifts), we decided to continue with the conversion to Java, we generated 50K lines of Java code from the Lisp introspection facilities, we found that we had 10x code bloat in Java, dumped java, yay, back where we started, actually improving the site now!
One striking thing was the complete lack of interest most of the Java programmers seemed to have in learning anything about the Lisp code. I guess they thought "how is this going to help my career"?
Lisp is perfectly suited to web applications. Since it's mostly just application logic and sending bits out the wire, Lisp's ability to change code on the fly without restarting app servers and such is a huge win, especially since a web site often requires frequent, small updates.
Yes, Common Lisp has application servers (at least private ones like the one I work with). Yes, Common Lisp has DB connectivity. Yes, it has CORBA bindings. Dunno about asynchronous messaging, but I suspect it's a buzzword for something that we Lispers don't even glorify with a name because it's so easy to implement. I personally wrote a web page template system in about a day in Dylan, a Lisp descendant. No biggy. And it's much easier to use than JSP.
One of the beauties of Common Lisp is precisely that it supports both OO and functional (in the loose sense) styles of programming well. It supports each better than Java does. Common Lisp is Object Oriented, while Java is Object Obsessed. Common Lisp's object system is basically a superset of Java's. You could limit yourself to programming in a Java style in CL, but why would you want to?
Almost any language with functions/methods can support functional programming (in the loose sense) to some degree. Some encourage it more than others. Java discourages it by, for example, not allowing true first class functions/methods, by having many constructs such as IF that don't return values, by insisting that every single bit of code must belong to a single class, etc.
I agree to some extent that the set of available libraries is often the most important thing when deciding on a language for a project. Many of the Java APIs are made unnecessarily complex due to limitations of the language. But there sure are a lot of them.
It's a desert topping AND a floor wax.
It's not clear to me why you didn't use data structures in your Lisp program and did in your C++ program. If you're talking about Common Lisp then you could have used defclass or defstruct to define structures, or you could have written your own ADTs with a built-in type and accessor functions. Whahappen?