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.
The second performance result is the low development time. This can be accounted for by the fact that Lisp has a much faster debug cycle than C, C++ or Java. The compilation model for most languages is based on the idea of a compilation unit, usually a file.
More importantly, Lisp is not "file oriented". In Lisp, a function is a function is a function - you don't have the complex mess of static/public/private/whatever.
Of course, Lisp is also write-only, like Forth and APL.
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#..
LISP weenies are like those "algebrawookies" who rant and rave how fundamental THEIR field is to everything. Yet, when asked, they can't provide a single example of an application that was borne directly out of their work.
Anyone who already knows Lisp have any suggestions on a good place to start?
______________________________________
Ever notice how fast Windows runs? Neither did I...
Learning to read Lisp is much easier than learning to read C++ or Java, it's just that nobody thinks so because they personally don't remember all the time they wasted learning the harder languages. Lisp's simple syntax makes it extensible--parsing is so easy you can create just the language you need for the code you're writing. Those other languages are so hairy that hardly anything other than a compiler understands them even incompletely, ruling out any tools more powerful than pretty-printers.
I was interviewing for a job, and they asked me how my LISP skills were. They are pretty shady, and I told them so. Then I started to inquire about why they needed LISP. Back in the day, they hired a guy to write their core system. He got full freedoms, and chose to implement it in LISP since that was something he was good at and few people knew.
After implementing it, he started to basically blackmail his employer for more money. The "You can't replace me" sort of attitude we all fear to encounter and sometimes love to give. His employer just told him to get lost, and hired three of the best LISP programmers in the country.
I just thought this was a really good story, and very pertinent in this context. If you consider learning to LISP, don't soil the reputation of LISP programmers with this kind of attitude! (And that goes any other obscure implementation as well)
Stop the brainwash
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
For max performance and easy integration with C-APIs try this language at http://www.ocaml.org. I only heard about it from the ICFP contest but it is a very cool language IMHO.
...I developed a scheduler using JESS, which is a Lisp like language written in Java, which integrates with Java. I did look at Lisp as a candidate solution, but a lot of compilers support the CommonLisp standard to varying levels, which caused some headaches.
The performance using JESS was quite incredible given that it was a language within Java.
I also agree that Lisp is an absolute pig when it comes to readibility, you just get brackets everywhere, and you end up adding more and more.
It's to guarantee the safety and well-being of its members. It's plain greed if you rather neglect people who've hit hard times than give a bit out of your own wealth.
The study does show an advantage of lisp over java/c/c++ -- but only for small problems which depend heavily on the types of tasks lisp was designed for. The author recognizes the second problem ("It might be because the benchmark task involved search and managing a complex linked data structure, two jobs for which Lisp happens to be specifically designed and particularly well suited.") but doesn't even mention the first. ... but still. If we're choosing a language for a task, this should be a primary consideration.
While I haven't seen the example programs, I suspect that the reason the java versions performed poorly time-wise was probably directly related to object instantiation. Instantiating an object is a pretty expensive task in java; typical 'by the book' methods would involve instantiating new numbers for every collection of digits, word, digit/character set representation, etc. The performance cut due to instantiation can be minimized dramatically by re-using program wide collections of commonly used objects, but the effect would only be seen on large inputs. Since the example input was much smaller than the actual test case, it seems likely that the programmers may have neglected to include this functianality.
Hypothising about implementation aside, the larger question is one of problem scope. If you're going to claim that language A is better than language B, you probably aren't concerned about tiny (albeit non-trivial) problems like the example. Now, I don't know whether this is true, but it seems possible that a large project implemented in java or c/c++ might be built quicker, be easier to maintain, and be less fragile than its equivilent in lisp. It may even perform better. It's not fair to assume blindly that the advantages of lisp seen in this study will scale up. I'm not claiming that they don't
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)
To whom are you referring? I'm curious. Philosophers? MIT graduates?
I'm not a big fan of Java or C++ but the premise that because Lisp performs better it is a viable alternative to either language is flawed. Performance is not usually a factor in most development.
They go one to say that the Lisp programmers were more productive as well. Lisp is a functional language and as such requires a different way of thinking than a Java or C++ programmer is used to. An object-oriented programmer is not going to be more productive by switching to a functional environment. Not in the short term anyway.
You can do OO style programming in Lisp and Scheme. Lisp has Common Lisp Object System (CLOS). In Guile Scheme, there is GOOPS which closely resembles CLOS.
It seems Slashdot hosted an almost identical discusion back in May.
As before, the discussion founders on variable definitions of what makes one language better than another and the fact the skill of the programmer is more important than the features of the language.
The usefulness of a programming language is partially determined by non-technical issues. From the corporate point of view, the issue is the availability of qualified programmers. From the programmer point of view, it's the demand for people with that programming skill. These two complimentary forces tend to concentrate skills in a narrow range.
Typically, what broadens the playing field is a killer app. Does List have such an application?
You were overheard of saying the following:
"People don't base their language choice on
speed anymore."
If that is the case, sir, then, why don't we see people stampeding to port all their code to LOGO, huh?!
Muchas Gracias, Señor Edward Snowden !
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.
Well, the article is alreay totally outdated... It compares lisp execution time to java's 1.2 runtime environment.... Which didn't include the hotspot compiler. You would have to re-run this test using a more modern JRE to get any results that are meaningful in today's world...
Aside from the statistical meaninglessness of this article that others have pointed out, I'm also not impressed by the trivial nature of the problem they tackled. 600 lines of code? Well sure, if you're writing baby programs, lisp may very well be they way to go! If you're going to get into more serious projects, however, I'm doubtful that it's still more useful. Lisp is simply less readable than C/++ or Java. Its compactness simply makes it harder for humans to decipher... When it comes to bug fixing in a big project, you don't just tool around, debugging stuff in real time (Which, btw, you can do easily with java and beanshell).... You look through the code to understand *why* something isn't working they way you thought it would work...
All in all, I remain unimpressed.
In my opinion Smalltalk makes a much better alternative to Java.
Smalltalk has all the trappings--a very rich set of base classes, byte-coded, garbage collected, etc.
There are many Smalltalks out there...Smalltalk/X is quite good, and even has a Smalltalk-to-C compiler to boot. It's not totally free, but pretty cheap (and I believe for non-commercial use everything works but the S-to-C compiler).
Squeak is an even better place to start...it is highly portable (moreso than Java), very extensible (thanks to VM plugins) and has as very active community that includes Alan Kay, the man who INVENTED the term "object-oriented programming". Squeak has a just-in-time compiler (JITTER), support for multiple front-ends, and can be tied to any kind of external libraries and DLL's. It's not GPL'd, but it is free under an old Apple license (I believe the only issue is with the fonts..they are still Apple fonts). It's already been ported to every platform I've ever seen, including the iPaq (both WinCE and Linux). It runs even on STOCK iPaqs (ie 32m) without any expansion...Java, from what I understand, still has big problems just running on the iPaq, not to mention unexpanded iPaqs.
And of course, we can't forget about old GNU Smalltalk, which is still seeing development.
Smalltalk is quite easy to learn--you can just pick up the old "Smalltalk-80: The Language" (Goldberg) and work right from there. Squeak already has two really good books that have just come into print (go to Amazon and search for Mark Guzdial).
(this is not meant as a language flame...I'm just throwing this out on the table, since we're discussing alternatives to Java. Scheme/LISP is a cool idea as well, but I think Smalltalk deserves some mention.)
Yeah, but you can do that in many different ways.
You can be humane and support the people who have, for some reason, failed in their lives so that they can get back on their feet.
Or then you can kick them while they're on the ground and hope that the "losers" will die soon so that they'd stop bothering you while you're ripping off your fellow human beings.
This was published in 1999 and states an average of 7.7 years programming experience with Java for the the test subjects. Since Java was released by Sun in mid 1995 this number is obviously wrong! What about the other numbers they give? Are they just trash too?
Your imagery is misplaced. The purpose of the lesser people is to provide support for the myths carved by the supermen, such as myself. We can't be supermen if we're cleaning crap off the streets. I recommend that you and your kind learn your place. There are two kinds of people in the world, Great Men, and lowly men. You are not a Napoleon.
Can you do a "shock the monkey" banner in lisp?
One thing worth noting is that XML is just an annoyingly verbose way of writing LISP.
While the world seems to have standardised on Java for XML work, the most clear, easy and natural way I have seen to process XML is in Scheme. This site has the details, defining an equivalent representation of everything XMLy in Scheme, and providing a cool parser implementation.
The fabled "scripting language in XML" could turn out to be pretty-printed scheme s-expressions...
Remember - when you're downloading XML, you're downloading communism^H^H^H^H^H^H^H^H^HLISP !
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.
It's still an emulator.
You might like to look at the following links before you conclude that Lisp is not usable in the real world:
http://www.paulgraham.com/paulgraham/avg.html
See:
http://www.bagley.org/~doug/shootout/
By far the FASTEST VM I've ever seen, especially when it comes to graphics. The limbo language is exceptionally clean. For those who don't know what inferno is it's closly related to the plan 9
OS by bell labs. More information on inferno can be found here. http://www.vitanuova.com/inferno/concepts.html .
Those of you running windows, check out the plug-in demos. While they are running take note that when it's running graphics the cpu usage on your system should be no more than 5-7%. On the otherhand, equivilent java programs like to peg your CPU whenever you try and do some mediocre graphics.
Peter
www.alphalinux.org
Lets' avoid the "Different languages are good for different types of projects" conclusions. Boring! :(
Is either language good when implemented directly on a chip?
Lisp implemented in hardware turned out to be a distaster in the eighties. Symbolics, Lisp Machines International, the Texas Instruments TI Explorer, the Xerox's Lisp Machines all came to a dead end. Symbolics lasted long enough to emulate their machines on Alpha(Open Genera), and now Alpha's are probably going to be phased out, too.
I have seen lots of attempts to put Java on a chip, but I'm unaware of any real successes.
Is there a reason to think that Java will do better in the embedded field than Lisp did on workstations?
Why do you do a comparison then?
Memory consumption for Lisp was significantly higher than for C/C++ and roughly comparable to Java. However, this result is somewhat misleading for two reasons. First, Lisp and Java both do internal memory management using garbage collection, so it is often the case that the Lisp and Java runtimes will allocate memory from the operating system this is not actually being used by the application program.
If your tests concluded that Lisp was allocating memory for the same task, why would you conclude that just because it uses garbage collection the results were misleading. If my peak memory utilization for Lisp is A, and peak memory utilization for C++ is B, if A > B it's pretty much cut and dry.
In the real world we shouldn't care about garbage collection, if your app looks like a memory hog, chances are that's the way it'll be preceived by the general user.
The problems with the API can be solved by porting a LISP to the dotNet framework.
MS Empire minion
I am afraid of a bearded weirdo running after me screaming "it's GNU/LISP!", "it's GNU/LISP!"
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
Is it just me or is this whole study flawed because its not the languages per se that he is testing, but the compilers for those languages.
The only criteria considered in the article (development speed, execution speed, memory usage) are of secondary importance. Most of the money spent on software development is spent on maintenance. Maintenance is what most programmers do.
The most important criterion for language choice in the real world is: how easy is it for someone to understand a program written in this language?
That's why Lisp is, and deserves to be, a loser.
¦ ©® ±
"Syntactic sugar causes cancer of the semi-colon." -- Alan Perlis
...let's emphasize that the date of the article makes it completely irrelevant. Java near the beginning of its life was not just slow, nor sloooow, but it was SLOOOO-OOOOO-OOOOW. We tried to use it for some things at the Human Genome Project, and gave up. I don't know what version of Java he was referencing, but it certainly wasn't Java 1.3, which has turned in some pretty major improvements.
I myself pretty much just Emacs for all my Java programming.
However, I have to say that an IDE can be useful for two things - The first is helping novice programmers understand the language better and develop within your application faster (here I speak primarily of code completion). The second is debugging... I know there are many debates on weither or not debuggers are really useful and I try not to rely on them much, but sometimes when you have a really nasty multithreading issue there's nothing more valuable than being able to scan system memory during runtime.
I know many would argue against using code completeion - I myself am not sure yet weither to see it as a crutch or not (I figure it's probably better to have a solid understanding of what you're trying to call). However, cruch or no it does make it possible for lower level programmers to work more effectivley in a system and sometimes you have tasks that don't require a lot of design, just a lot of work that can be done (with supervision) by entry level people.
So even though the presence of good IDE's may not make a language "good", I think it helps determines if a language is viable for corperate programming.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
http://artists.mp3s.com/artist_song/234/234762.htm l
It's called Monk by the vendor. I've kind of learned to like it. It's easy to work with linked lists.
But I've been paid well to use it.
The vendor has a new version that uses Monk and/or Java. So who knows.
Please don't waste moderator points on this.
I spent a lot of time with scheme in school - I took a number of classes that used scheme and was also a scheme labby (where I helped students in scheme classes and also led sessions to try and help people explore concepts presented in class in more depth). Even now I personally think Scheme is the best language in the world to teach programming.
However, I'm also a corperate Java programmer. Thus I have no congnitive dissidence at all, I'm really comfortable in both lnaguges, in fact I use a lot of techniques I learned in Scheme in Java. I have to say that for corperate programming, Java is simply a better choice at the moment.
There are a lot of reasons why I think that, mostly boiling down to a rich set of tools, corperate system API's, and a lot of programmers with a wide range of experience. But I don't think cognitive dissonance is the problem - if Scheme became viable you'd see a lot of programmers head that way just like they've headed to Java from other languages.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Lisp is all well-and-good...Until you try to build a multithreaded app.
First they make you a UNIX,
Then they make you LISP.
Every once in a while, I get the urge to write programs in Lisp. It usually happens late at night when, presumably, the satellites are overhead. This is unusual in that, while I consider myself a competent programmer, my Lisp skills hover around the HelloWorld level.
My current working explanation for these urges is that Lisp was the native language of the inhabitants of Ancient Mars, mankind's ancestral homeworld. I'm not talking programming languages here, but rather that the syntax of the spoken Martian language was lisp-like.
I've tried to uthe lithpe, but I find it jutht doethn't have the thtrong typing of java, or the eathe of creating eathily extenthible uther-defined typeth.
that and there'th thothe thtupid pronunthiation problemth.
TheNewWazoo
Smalltalk.ORG has links to all the versions of Smalltalk plus more.
How about ada? Ada95 is one of the most efficent
languages to program for, assuming you will be
doing object oriented design or embedded apps.
Java isn't doing all that well in embedded world
and C++ is a joke when it comes to cost of the
production. Not many people look into ada,
but they should. It is a baby of DOD, to cut
costs on development of software. Last time
DOD ventured into computers they made internet.
I think we should listen to them on this one
closely, because what they say may have alot of
merit, unlike that of a Java promoting drone and
LISP huddling professor.
p.
http://perlpimp.com for few links.
One reason Lisp has fallen because the Lisp community could not resist the temptation of feature creep. Common Lisp is a huge language with all sorts of cruft and a difficult to understand packaging system. Java, on the other hand, is a much smaller language, but with a huge API. It is much easier to learn Java and then to pick and choose what parts of the API you need to know. Lisp should have standardized and modularized the API rather than bloating the language.
BTW, there is a link within that, which talks about how Java's handling of floating point is terrible and even sets back technology if fully endorsed by the industry and academia.
Java is a very young language. It is easy for me to predict that in 30 years from now, that Java's library will be a mess. For instance, Sun will have theirs along with GNU's and also don't forget other meanfully re-implemented libraries by other communities (AI, Graphics, Scientic Computation, Multimedia, etc). Java is just beginning on a long trip through computer science.
What has happened to Lisp? Algol? Smalltalk? Ada? Even C? Huge changes. That last paragraph talks about fragmentation? Let's see how Java (and C#)stand up to reality. BTW, Gosling has already said that many features should be added to Java. Read the link above for full details.
This is not flamebait. This article should be modded up to a positive number. Act like an adult and do it.
I just started learning Smalltalk in school this semester, and one thing that struck me as interesting is how flexible it is. However, this flexibility also introduces some problems: security. While Java sacrifices some flexibility from C/C++ to implement a (theoretically) secure environment, Smalltalk doesn't seem make any concern in this area. For example, you can redefine the class Object and basically change the behavior of all your programs. There are no access specifiers (like protected/private) for the methods. My question is, with this weakness, what mechanism is there to make Smalltalk suitable for a large project, when a big team of people are working together?
Another question: since everything in Smalltalk is implemented as objects and message sending, wouldn't that introduce a huge overhead? It's nice from a academic point of view, but is it practical in reality?
Lisp: Ton lit c'pas une trampoline.
BTW, there is a link within that, which talks about how Java's handling of floating point is terrible and even sets back technology if fully endorsed by the industry and academia.
Java is a very young language. It is easy for me to predict that in 30 years from now, that Java's library will be a mess. For instance, Sun will have theirs along with GNU's and also don't forget other meaningful re-implemented libraries by other communities (AI, Graphics, Scientic Computation, Multimedia, etc). Java is just beginning on a long trip through computer science.
What has happened to Lisp? Algol? Smalltalk? Ada? Even C? Huge changes. That last paragraph talks about fragmentation? Let's see how Java (and C#)stand up to reality. BTW, Gosling has already said that many features should be added to Java. Read the link above for full details.
This is not flamebait. This article should be modded up to a positive number. Act like an adult and do it.
Where are the good, cross-platform GUI toolkits for Lisp?
Become a FSF associate member before the low #s are used
Lisp: Good news Bad news How to win big also known as "Worse is Better"
Lisp on your Palm!
Lisp/Scheme is pretty cool, but depending on the implementation you choose, you usually get little or no support for making GUI applications. So if its going to be used anywhere, I'm guessing CGI scripts and such on the web. Using it with SVG might be a pretty good option.
------
bleh
generation of programmers appeared who preferred internal notation to any FORTRAN-like or ALGOL-like notation that could be devised." LISP was started as an extension of Fortran. The M-notation could not be used directly because of the character limitations of the IBM 026 key punch. S. R. Russell's observation about eval led to the implementation of an actual interpreter for LISP, this is what froze the language. This resistance to change was so great that it was impossible for McCarthy to even change 'car' and 'cdr' to names that had sense.
It is also good to read the history of LISP because we need to remember that LISP was developed specifically for the killer application of artificial intelligence. Unfortunately looking back we can now see that artificial intelligence stagnated for decades. What happened? The field was caught in an unhealthy fascination with exactitude, theorem-proving, logic. While these mathematical ideas are beautiful and engrossing, we have to keep in mind we are dealing with a problem area of artificial intelligence that is supposed to work in the real world. The right way to progress in artificial intelligence was to embrace statistical, evolutionary approaches.
Of course LISP is Turing-complete (provably), so in theory anything can be programmed in it. But we have to understand from reading the history the mindset associated with its origins, origins that are linked to an attempt to subsume artificial intelligence as a subset of mathematical logic. In this context, LISP can be argued to be computer science's greatest catastrophe. If great programs to finally succeed in conquering artificial intelligence are only now being written in LISP, it is just evidence that, academically speaking, the previous generation needed to die off to let progress resume.
The link should be Kawa.
____________
Something should be done about this:
Post Comment
Lameness filter encountered.
Your comment violated the postercomment compression filter. Comment aborted
Bush's education improvements were
Thanks for ruining a Tclers day;-).
I've used Lisp professionally for about 18 months. Two major complaints will cause me to never go back:
1. Do a search on the web for various kinds of components, free source, and other third party stuff written in Lisp. The resources are very, very scarce.
2. Emacs. Lisp and emacs are close friends. I don't like emacs. I hate emacs. Any development environment which REQUIRES you to use a particular editor (and many Lisps come perilously close to doing just that) is not for me.
I'll never willingly use Lisp again.
C//
...i'd be ecstatic.
if this keeps up can we look forward to LOGO APIs?
;-)
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
Lisp may be fast, but assembly is the fASTeST.
And let me tell you that having the yahoo store engine in lisp has been one incredibly lovely pain in the ass for the developers who inherited it.
MITs Computer Science 101 (6.001) is based a the
LISP variant called SCHEME. About half of the
MIT students take this course required for all
computer science majors and electrical engineeers.
This course has used LISP for most of its 30 year
history except one term when it tried Java.
It is presumed the most MIT students have programmed
extensively in high school one of the more practical language like C or JAVA.
This purpose of this course is to teach fundamental
program constructs and not how to get a job.
It's interesting to hear that lots of people describe Python as Lisp without parentheses. That's exactly what I thought when I, as a long-time Lisp hacker, first looked at Python. Python even duplicates accidental historical features of Lisp that many Lisp hackers now consider a bad idea. They did not get there by accident.
The problem is, what "Lisp without parentheses" means is a dumbed-down Lisp. There is a reason for those parentheses. Lisp without parentheses means Lisp without the core idea of Lisp: that the programs are made out of Lisp data structures. Lisp without parentheses means Lisp without macros, and that means a Lisp that is no longer (as John Foderaro famously called it) the "programmable programming language."
i think it would be cool to integrate Lisp into
your Java VM and then use Lisp to perform recursive functions and AI operations and such.
of course, you could use a pre-processor for that instead.
on second though, maybe that's a stupid idea.
nevermind.
/zard
The date on the report is from two years ago, and the JDK used was 1.2?!
Let's get drunk and delete production data!
Moderators, if you're still here: please mod this up.
> 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?
There are exactly two dialects of Lisp that have relevance to this discussion.
ANSI COMMON LISP is designed for large application development by a large team of programmers. It is the first object oriented langauge to have an ANSI standard. (circa 1990).
Scheme is a minimalist language designed for ease of learning. It is specified by R5RS.
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.
I wonder what would happen if the code were re-run with modern implementations of those languages? Allegro Common Lisp 4.3 is about two major releases old. And the CMU CL x86 compiler totally 0wnz it anyway, especially on numeric code.
I'm sure Java's gotten better too.
Heh, seriously though, lisp is nice if you're into functional programming and need the easy morphism that it allows. I prefer java, but thats because I learned that kind of programming before functional, and never quite got the hang of it.
-
http://www.newlisp.org/
Lost in the noise.
http://www.newlisp.org/
Lost in the noise.
First off, one of the best spokespersons for Lisp is Paul Graham, author of "On Lisp" and "ANSI Common Lisp". His web site is Here.
Reading through his articles will give you a better sense of what lisp is about. One that I'd like to see people comment on is: java's cover ... It resonates with my experience as well. Also This response
to his java's cover article succinctly makes a good point that covers
most of the bickering found here...
I personally think that the argument that Lisp is not widely known, and therefore not enough programmers exist to support corporate projects is bogus. The fact that you can hire someone who claims to know C++ does NOT in any way shape or form mean that you can hire someone who will solve your C++ programming problem! See my own web site for more on that.
I personally believe that if you have a large C++ program you're working on and need to hire a new person or a replacement who already claims to know C++, the start up cost for that person is the same as if you have a Lisp program doing the same thing, and need to hire someone AND train them to use Lisp. Why? the training more than pays for itself because it gives the new person a formal introduction to your project, and Lisp is a more productive system than C++ for most tasks. Furthermore, it's quite likely that the person who claims to know C++ doesn't know it as well as you would like, and therefore the fact that you haven't formally trained them on your project is a cost you aren't considering.
One of the points that the original article by the fellow at NASA makes is that Lisp turned out to have a very low standard deviation of run-time and development time. What this basically says is that the lisp programs were more consistent. This is a very good thing as anyone who has ever had deadlines knows.
Yes, the JVM version used in this study is old, but lets face it that would affect the average, but wouldn't affect the standard deviation much. Java programs are more likely to be slow, as are C++ programs!
The point about lisp being a memory hog that a few people have made here is invalid as well. The NASA article states:
Memory consumption for Lisp was significantly higher than for C/C++ and roughly comparable to Java. However, this result is somewhat misleading for two reasons. First, Lisp and Java both do internal memory management using garbage collection, so it is often the case that the Lisp and Java runtimes will allocate memory from the operating system this is not actually being used by the application program.
People here have interpreted this to mean that the system is a memory hog anyway. In fact many lisp systems reserve a large chunk of their address space, which makes it look like a large amount of memory is in use. However the operating system has really just reserved it, not allocated it. When you touch one of the pages it does get allocated. So it LOOKS like you're using a LOT of memory, but in fact because of the VM system, you are NOT using very much memory at all.
The biggest reasons people don't use Lisp are they either don't understand Lisp, or have been forced by clients or supervisors to use something else.
((lambda (x) (x x)) (lambda (x) (x x))) http://www.endpointcomputing.com a scientific approach to custom computing.
Lisp. Java. Which one sounds sexier? :-)
No doubt that Lisp is one of the great programming languages of all time. But still it wasn't designed for systems programming and commercial software development. Dylan is basically a cleaned-up, fully object-oriented descendant of Lisp that has infix syntax and a powerful module and exception system. A Dylan entry won second place in the ICFP 2001 Contest. (See the page http://www.hoult.org/~bruce/dylan-hackers.html for more info about the Dylan entry.)
The ICFP entry was written with the open source version of Dylan for unix, Gwydion Dylan. http://www.gwydiondylan.org. For people that want to help improving the compiler, there are plenty of opportunities. It's a great compiler already, but there are still plenty of advanced optimizations that one could implement. Both major Dylan compiler implementations are written in Dylan themselves so the code is easy to understand.
Another implementation of Dylan for Windows by Functional Objects has an advanced IDE, and supports the Win32 API, COM, Corba, etc. Like Gwydion Dylan, it produces very fast code.
.. Because it's possible for person of average intelligence (IQ = 100) to write passable code in it.
LISP and to a lesser extent Smalltalk are power tools. If you're good and smart, you'll write something which is really beautiful, elegant and fast. But most people aren't that good, and they produce crap.
And crap in Java is still more maintainable (I should know, I'm untangling a 700+ class ball of spaghetti as we speak) than crap in LISP or Smalltalk.
The fact that MIT and Berkeley (I think) and other schools with great CS programs start with Scheme illustrates the point -- it's not for well... the dumbass in the other cube.
> No doubt that Lisp is one of the great
> programming languages of all time. But still it
> wasn't designed for systems programming and
> commercial software development.
Don't be silly. This is *exactly* what Common Lisp was designed for. Have you actually *looked* at a commercial Common Lisp implementation? Perhaps you are thinking Lisp is restricted only Scheme?
I wanta liskp or scheme base scripting language! When is it going to happen??
List as an Alternative to Java is like "Linux as an Alternative to Windows"
Technically, +nix is superior to windows, but Java/*nix lack the mainsteam support and will struggle to wrestle it outta Gates's hands for reasons such as [home / small business ] PC makers support, peoples familiarity, ease of use, and the marketing/P.R./Legal budjet of MS, etc...
Java is already supported on 99% of people's browsers, has Sun behind it, and has more people with the knowhow to program it.
Unfourtunateley.
Ali
The biggest flaw in the paper is "experience"...
First off, most people over judge themselves.
If you ask them, "Do you consider yourself below avg, avg, above avg, expert, 31337?", most will respond with atleast one level higher.
If you ask people how many years, they tend to tack on some years or include years of experience done in another language.
I've seen this many times while interviewing potential consultants and it has never ceased to amaze me. I would wager that only 1 out 5 people are at the level they say they are at. That's probably being a bit kind.
Point from the article: Who the hell has 7 years of experience in Java by 1999? (This still happens with resumes and interviews. Gotta laugh when I see it. And, yes, I interview Java applicants.)
Don't know who posted this a while back, or on what topic: but it makes sense when these args come up:
--------------------
You Work in a Fashion Industry
I've spent the last several years trying to explain to colleagues why
they should start using another obscure-but-good language, Eiffel, to no avail.
Here is what I have learned. Note that this is not about the pros and cons of
particular languages or paradigms, its about the way the programming language
industry actually works.
The language industry is dominated by network effects. There are major
costs with using a minority language, and for an individual project these
completely outweigh the benefits, even when the benefits are very large. Hence
it is generally far better to stay with a majority language. The costs of a
minority language include:
Support. Sure, you can get a GPL compiler for most languages, but on a project
you don't want to have your coders digging into the code trying to
fix a bug, you want them writing code. Support is something you outsource.
Performance. Every minority language claims to be faster than C, but often
isn't in practice. Whatever the truth, C and C++ are at least known
quantities. Maybe the minority language will be faster, maybe slower. If its
faster, well gee so what. If its slower then you have a major problem.
Tool support. These days even small projects start by drawing UML diagrams and
then converting these automatically into class templates. CASE
tool vendors don't support minority languages. Ditto for testing and
documentation tools. Little things like tying your compiler to your
configuration control manager might potentially be major headaches. Again, its
more risk that the PM can do without.
Nobody ever got fired for buying C/C++/Java. If you are a PM this is a major
issue. Every language is going to bring some headaches, but if you have chosen
a minority language then these headaches can be turned into an excuse for
project failure, and hence for hanging you out to dry.
Trained staff in a minority language are going to be rare. This does not
necessarily make them more expensive (nobody else wants them), but it
does make recruitment much harder and more uncertain. Alternatively you have to
train all your existing people in the new language. And for Functional
Languages its not just another syntax, its a whole new way of thinking. The
industry went through this with OO languages, and many PMs have vivid memories
of reams of non-OO obfuscated C++ written by a bunch of C hackers who had been
sent on a one week C++ course. Getting your head around a new paradigm can take
months, and this is time that the project just does not have.
So, overall the PMs want to go with popular languages, not for PHM
reasons, but for entirely rational local reasons. But rational local decisions
turn into globally arbitrary decisions, as the entire herd gallops off in a
random direction chosen only because most of the herd thought that most of the
herd were headed that way.
The lesson of this is that if you want to introduce a language, you don't
concentrate on making it a good language, you try to persuade the herd of
programmers, PMs and tool vendors that your language is the Next Big Thing. The
important point here is not how much the language will do for productivity,
quality and cost, it is to create the perception that everyone else thinks that
this language will be the next big thing.
There are two ways to do this. One way is to tackle the whole industry at once.
For an object lesson in how to do this, see Java. For an object lesson
in how not to do it, see Eiffel. Believe me, I know all about this. I have
spent a long time giving presentations extolling the technical virtues of
Eiffel, only to have my audience say "Yes, but in the Real World....". In the
Real World what counts is the network effects. And you know what? My audiences
were right. It has taken me a long time to realise this.
The other more interesting and more promising way to introduce a new
language is to identify a niche market and attack that. Once you have taken
over your niche you can expand to nearby niches and start to build momentum.
Python is doing exactly this in web serving, for example. Web serving is a good
niche because lots of people do it, and productivity and quality generally
count for more than raw performance. Projects also tend to be small, so
experiments are not the Career Limiting Moves they are for large projects.
Education can also be a useful niche if you can afford to take the long view,
which is how Pascal, Basic and Unix got started.
Why not FORTH? This can be implemented much more efficiently than either Java or LISP. Are people just afraid of stacks?
now we need to go OSS in diesel cars
And I have to say that I don't think I ever use lists... Usually, I use arrays, structures, objects and hash tables. Lisp has support for multidimensional arrays and you can define your own structures or classes.
And, I'll say that with CMUCL, it compiles down to the same assembly as C does.
Try a modern lisp, say, one written in the last 10 years.. Or, read `Common Lisp the Language', which dates back to the early 80's.
My bookshelf has about thirty books on J2EE programming, alone. It also has SICP, The Little Schemer, The Seasoned Schemer, Common Lisp (Steele), Lisp (Winston & Horn), and my old AI texts. The Little Schemer and the Seasoned Schemer are great for learning about functional programming, but they don't say anything about using slib. It would take me a year to work through SICP (and I don't doubt I'd be a much better programmer) but I don't have a year, and it still (after a quick browse through the TOC) doesn't say anything about the things I have to do every day (say, yank data out of a database, turn it into an XML document, run it through an XSLT engine, and send the result back to a web browser).
This isn't a troll. It's a plea for help. What's a fast and efficient way to start developing apps in scheme or lisp?
Ceci n'est pas une
Good things about using guile scheme:
Major downsides to scheme
However, it's not an insuperable barrier. Provided people use a bit of common sense and design clean interfaces (and document them) it's generally not too much of a problem.
In any case, I'm convinced that using guile has been a big net win for the project.The scope that scheme is used in just keeps growing, because it's just so damn convenient.
Disclaimer: speaking for me, not my employer.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
I almost couldn't believe it when I got Matlab 6 at work and its GUI and API had been re-written in Java. Slow as shit until I disabled almost all of the GUI. I wonder who the moron who suggested Java for Matlab was? I'd sure like to kick his ass for almost ruining a great program.
ain't that the truth...
Now go listen to what Linux Torvalds is saying
Er, Linux Torvalds?
>
p /h istlit1.html
>Don't be silly. This is *exactly* what Common >Lisp was designed for.
>
I stand by my original assertion. You might want to read this paper which describes the early history of Lisp:
http://www8.informatik.uni-erlangen.de/html/lis
You also might want to read the Purpose page of the book "Common Lisp the Language":
http://www.math.uio.no/cltl/clm/node6.html
Face it, functional program languages do not represent real-world processes in ways that non-technical (particularly non-mathematical) people think, object-oriented languages do. Now any programmer worth his salt can, given sufficient resources, do the mapping of user requirements to functional constructs just fine, but for business application programming, it's just much more effective to say "the Ledger object sums all the values in the Activity column" to a business user than "the accumulate function is mapped over the list of transaction elements"
It's a nice language and a different way of thinking about things, and it has certain charm to it.
But you can't get down and dirty to the bare metal with it. It's hard to do bit twiddling in lisp, for instance. Or pointer arithmetic.
But for high level application development, where you don't need to access the low level, it's perfectly fine. I think the big argument you'll have againt using lisp is that few really know the language.
My personal suggestions to lisp afficionados:
1. Be more polite and less snobbish. When someone wants to learn your language, welcome them in, and forgive them their faults as they learn.
2. Put together a free win32-based lisp dev environment. For unix, it's pretty easy to get a free lisp environment, but for the microsoft world, the only real dev environment is Franz, and they want mucho $$$$$ for their package. And Franz is like killing a mosquito with a sledgehammer. Something a little lighter and more accessible would do nicely.
There are two ways to do this. One way is to tackle the whole industry at once.
Another way is to build on the industry's current state, rather than change it whole-hog. C++ was essentially a superset of C, and Java didn't stray that far from C++.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
OK. www.orbitz.com, then new travel site that's spending lots of cash advertising on TeeVee. Implemented in Lisp.
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
Beyond this, all of the results are based on one programming problem. I'm quite sure that I could choose a programming problem that C would be faster for then Lisp, java, and even Fortran.
Lisp is faster then C/C++ for many tasks, however there are many tasks that Lisp is slower or completely unsuited for.
You can't base the decision to replace a language, on the languages ability to solve one problem. C is a very general purpose language, while lisp is much better at certain tasks and is less of a general purpose language.
The researcher was obviously looking for the result he got.
If the research were to be unbiased, they should choose several common computer algorithms, and have each implemented by a large number of programmers in the languages to be studied. If in the end lisp outperfomed java and C/C++ in a majority of cases that would be a good argument for doing more lisp programming.
Environmentalists are their own worst enemy. ~tricklenews.com
and give me the names of a couple of libraries that GNUcash does not require?
The point is that the GNUcash developers see a neat feature in some esoteric library, decide to use it once or twice, rinse, and repeat. They couldn't design a decent product if their lives depended on it. It's a big bloated collection of about 3000 "cool hacks". I think I'll be sticking with Quicken, thank you.
-sting3r
Extra delimiters help convey the nature of code. Most of the time, you don't need the flexibility of every single entity being equivalent/interchangeable with every other one. The extra delimiters act as implicit, concise documentation.
"The unexpected appearance of an interpreter tended to freeze the form of the language, and some of the decisions made rather lightheartedly for the ``Recursive functions ...'' paper later proved unfortunate. These included the COND notation for conditional expressions which leads to an unnecessary depth of parentheses, and the use of the number zero to denote the empty list NIL and the truth value false. Besides encouraging pornographic programming, giving a special interpretation to the address 0 has caused difficulties in all subsequent implementations."
-John McCarthy, http://www-formal.stanford.edu/jmc/history/lisp/no de3.html
Take a look and feel free: http://www.PieMenu.com
>> Face it, functional program languages do not represent real-world processes in ways that non-technical (particularly non-mathematical) people think, object-oriented languages do. <<
That is hogwash. You are not an expert on how poeple think. And get this news: PEOPLE THINK DIFFERENTLY.
oop.ismad.com
Table-ized A.I.
That would be quite a lot of languages. And yes, even LISP!
Will work for bandwidth
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.
There is zero evidence to back up the notion that a Lisp (e.g. CLOS) app would be less maintainable. Of course, there's not a lot of evidence either way, but there's at least a little evidence that it might be more maintainable:
http://www.spr.com/library/0langtbl.htm
This table shows that CLOS requires fewer lines of code (LOC) per function point than Java, in other words a typical CLOS app will require fewer LOC than an equivalent Java app. This data roughly jibes with the LOC results from the NASA/JPL study. This makes CLOS a "higher-level" language than Java.
Anyway, apps written in higher-level languages are easier to maintain than apps written in lower-level languages, simply because there is less code to worry about. Less code to do the same task also usually means that there is less code duplication, which is a common source of bugs. Thus, we would expect that a CLOS app, on average, would probably be easier to maintain than a Java app. (Yes, there are other factors in what makes a language more or less maintainable, but high-levelness is one of the few that is actually measurable.)
Granted, the SPR languages table is rather coarse-grained... apparently a lot of the levels for languages were extrapolated from other languages based on language features. (e.g. I think Java probably deserves a slightly higher language-level rating than C++, but then again Java lacks some things like genericity which might partly offset its LOC gains from automatic memory management/etc versus C++. Same goes for Scheme deserving a higher level.) But still, the table seems to be roughly accurate from my experience with programming various languages, and it's the best data we've got. It would be great if better and more detailed studies could be done comparing languages for developing (and maintaining!) larger, real-world apps, but this type of research is difficult and expensive, so it never seems to get done. :-(
Regarding complaints about the NASA study again... same goes for tiny apps versus huge apps. The jury is still out on whether statically-typed (Java/C++/Fortran) or dynamically-typed (Lisp/Smalltalk/Python/Ruby) languages scale better to huge apps. My personal feeling is that dynamically-typed languages scale better, but I don't think there's any real data proving either case. (Something like CLOS in particular with its powerful meta-programming capabilities I think would start to seriously crush Java in terms of maintainability for enormous apps.)
(By the way, I'm mostly a big Smalltalk fan, but I have a lot of respect for Lisp and its variants. I do work with Java too, but I don't find it particularly inspiring. ;-) See http://squeak.org for a cool, free, open-source (including the VM!) Smalltalk that runs on most any platform.)
As for a prediction of where Java will be in 30 years... my guess is it'll probably be around quite awhile, having a life-cycle similar to COBOL. Java and COBOL are similar in a lot of ways... neither language is revolutionary in terms of fundamental language features (as opposed to Lisp or Smalltalk), but both had good support for development of business-related apps, and gained a lot of momentum as a "standard"...
> http://www.math.uio.no/cltl/clm/node6.html
Efficiency, Power and Stability all sound like good attributes for commercial software to me. You're right that it's probably not the best language for systems programming though.
Does Java? The typical Java-fan critique of JSP acknowledges that Java is a lousy language to embed in web templates. There's a plethora of templating systems out there that implement various non-java syntax to embed in web pages -- webmacro, XMLC, etc. Is there one of them that could legitimately be called the "Java" web page templating system?
JSP taglibs are a kit to build your own non-Java language to embed in HTML.
Why not use a well-designed language that lends itself well to embedding in HTML and other markup, the Scheme-based BRL. I'm using it very successfully at work. Compare its code for sending e-mail or dealing with a database with any other language or system. I'm biased, but the code isn't. For rapid development of database-driven web apps, it cranks.
This is where the "everything is an expression" model of Scheme wins out over the package/class/method/statement/expression hierarchy of Java. If Java statements in a JSP get unwieldy, you need to come up with a package, class and method to put them in. With Scheme/BRL, you just wrap a function definition around the code in question (define (show-user-name) ...) and toss it in sitedefs.scm.
How much harder is [(show-user-name)] than <jsp:show-user-name/>? In either case, the content editor is just treating it as a black box. They need to understand what goes in and comes out, but don't otherwise care how it works. The logic hasn't really been separated, just abstracted.
There are varying degrees of abstraction. For example, conditionals would be less abstracted. The content editor needs to understand the logic in order to have control over what is shown to the user, e.g. "If this and that form field are blank, then show this message, otherwise do that." This is the beginning of programming. The more ambitious the content editor, the more "programming" gets involved.
BRL gives you complete choice to vary the amount of abstraction according to the ambition and ability of the content editor. And you're not stuck if you change your mind later.
When debugging, I find it handy to have the HTML and code mixed in front of me. I'm looking at actual HTML generated, and I want to find the code responsible. With little abstraction, it's one-stop shopping. Forcing an n-tier architecture from the start would be cumbersome. It's unnecessary. BRL is not like JSP, where once code goes into a page it's unlikely to ever come out.
In the field of computer science, this is practically ancient, having been written in late 1999. It may be interesting as a historical perspective, but the article has little or no value as a modern comparative evaluation.
After reading this book, I always get a woody whenever I hear of LISP. Just because of the history, it's what the grandaddy hackers hacked with.
Or there's Dylan as an alternative to Java:
l
http://www.fun-o.com/resources/beyond-java.phtm
goals maybe, but not attributes