Lisp as an Alternative to Java 372
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."
It's about the API (Score:4, Troll)
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.
Re:It's about the API (Score:1)
It's for people who don't care to write lean and fast code.
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.
Re:It's about the API (Score:2, Interesting)
Then how do you explain that the development times reported for Lisp were about half those of Java, comparing the median?
Re:It's about the API (Score:2)
Or to ask the question in reverse: why did Dylan choose to move to a pseudo OO paradigm with optional type checking?
I suspect the answer is that for larger projects, the skeleton/framework provided by a more static system allows some bugs to caught early, and in general acts to guide development.
Has anyone used LISP/Scheme in a larger project?
We do (Score:2)
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.
Re:It's about the API (Score:5, Insightful)
Secondly he was using a task which Lisp is very good at, and well optimized for - list processing. People working in Lisp tend to be well exposed to this kind of problem.
I've been coding lisp for a few years. (Score:2)
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.
Re:It's about the API (Score:1, Informative)
Lisp: OO or functional? (Score:2, Informative)
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.
Re:It's about the API (Score:5, Informative)
Re:It's about the API (Score:5, Informative)
From what I've seen of SLIB, it is not comparable with the Java 2 platform (standard edition) version 1.4. :
Threads
I/O (blocking or non)
Reflection API
Weak references (and the likes)
Networking (including http client, ipv6 support, URLs, datagrams, network interface)
RPC (RMI, CORBA)
Security (permission, keys)
Relational database API (implemented by MANY vendors, you can often *choose* your implementation...)
Text formatting
Data structures (OK, needs functional improvements, I agree)
Useful classes: date, calendar, locale, time zones, currency, timer...
Logging
Regexp
Zip
Preferences
Accessibility
Imaging API
Naming API (directories, ldap)
Printing API
GUI API (awt, Swing)
XML parser + DOM + SAX
XSLT
Components (java beans)
Sound
Should I continue with enterprise edition?
I think no langage can compete with Java in terms of API richness and uniformity.
Re:It's about the API (Score:2)
Re:It's about the API (Score:1)
The link should be... (Score:2)
The link should be Kawa [gnu.org].
____________
Something should be done about this:
Post Comment
Lameness filter encountered.
Your comment violated the postercomment compression filter. Comment aborted
Re:It's about the API (Score:2, Informative)
Do yourself a favor and learn about Common Lisp. Not all members of the LISP family are equal. You are most likely thinking of Scheme. Scheme is a reduced API (on purpose) used mostly for academic purposes. It is most likely what you are taught in CS at the University. Common Lisp is the API heavy LISP with everything (probably the kitchen sink too! though I haven't found it yet).
Great place to start [lisp.org]
The Common Lisp HyperSpec [xanalys.com] (The ANSI CL standard reference) -- view this for the API features
You obviously do not know or understand LISP (the entire family). Learn it (CL would be your best bet). Do not just trash it without understand what it is all about.
Re:It's about the API (Score:2)
I've worked in 10 different flavors of FORTRAN, several versions of PL/1, several versions of Basic, several assemblers including machines no one here has probably heard of (ITT ADX-9303, interrupt driven I/O only), SNOBOL, APL, LISP, PERL, and others I don't readily remember. I haven't looked at JAVA. C/C++/JAVA seem to be languages that need huge support libraries to overcome the lack of builtin features and capabilities.
My use of C/C++ has always been frustrated by the lack of language features and abilities that make things easy.
REPOST:A classic /. posting on languages as fasion (Score:2)
--------------------
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.
Re:It's about the API (Score:2)
Thats true, but Fortran is mainly used in scientific computing, where arguments are often arrays, and frequently arrays of such size that passing them by anything other than reference is insane, not to mention undesirable.
Well defined function names and documentation will tell a reader which functions modify which arguments, anyway.
Statistically meaningless (Score:3, Insightful)
Re:Statistically meaningless and incomplete (Score:2)
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.
Missing the point. (Score:3, Insightful)
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).
Writeability vs. Readability of LISP/JAVA (Score:3, Insightful)
Re:Writeability vs. Readability of LISP/JAVA (Score:2, Informative)
Another point is that Lisp programs tend to be much shorter than programs in languages like Java / C++ for the equivalent functionality. See the figures in the study for example.
This makes them significantly easier to modify and maintain.
Mark
Re:Writeability vs. Readability of LISP/JAVA (Score:3, Informative)
For example, what's the natural way to define the factorial, n! ?
0! = 1
n! = n * (n-1)! if n > 0
Clear and simple.
Suppose I have to perform a function on every node of a rooted tree:
starting with the root:
walk through any children.
process the current node.
And that will translate directly into clear and easy to understand (and easy to debug) code.
You think and use recursion every day, you just don't recognise it. That's not to say that recursion is the only thing that should be used, but when used correctly it makes code very easy to understand.
Re:Writeability vs. Readability of LISP/JAVA (Score:2)
I'm not sure I agreee with your argument though - Yes, with a good editor (defined as Emacs, I'm not sure how well Vim would take on Lisp code [I'm probably maligning it unfairly here]) Lisp code is fairly easy to follow - though the old joke of someone having hacked in to get the Lisp code for SDI and printing out the last page as proof (4000 ')' in a row) has a ring of truth to it.
Similarily though, loading any Java code into emacs and just running "indent-region" over the whole document will give my easily readable code even over poorly formatted and undocumented stuff. I've never run into any Java code taht wasn't easy to understand after one pass with a reformatter, and I think that would be true of almost any language now.
Re:Writeability vs. Readability of LISP/JAVA (Score:2)
-jon
Re:Writeability vs. Readability of LISP/JAVA (Score:2)
Actually the standard doesn't require Common Lisp to be tail recursive. A decent implementation should be, however, at least at appropriate optimization settings.
Re:Writeability vs. Readability of LISP/JAVA (Score:2)
You're an experimentalist, right? :-)
Seriously, LISP is to functional programming what Fortran is to imperative programming, or what Simula is to object-oriented programming. Modern functional programming is pure algebra.
Try out Haskell, Clean, or ML. You might be pleasantly surprised.
Re:Writeability vs. Readability of LISP/JAVA (Score:2, Insightful)
First, you obviously haven't used lisp. Second, you have missed the entire point of the syntax of lisp. The syntax of lisp is the same as data in lisp, s-expressions. The function read can be used to read a piece of code or a data. If you don't see the utility of this, god help you.
Re:Writeability vs. Readability of LISP/JAVA (Score:2)
Actually, it turns out to be incredibly useful for reading and writing any sort of data - not just code.
Re:Writeability vs. Readability of LISP/JAVA (Score:2, Informative)
Huh?? I've never written a single AI program in my life. Program and data being the same are good for far more than self-modifying programs. To name some uses: program analysis, program configuration (read and eval the data), and macros. The latter is probably the single most important thing in lisp. Unlike pattern substitution in most other languages, macros in lisp are really powerful. See this [lisp.org] for more info on macros.
Re:Writeability vs. Readability of LISP/JAVA (Score:3, Informative)
Why is it relevant how readable a program written in some language one doesn't know is? I don't think there's anything wrong with Russian because I can't gain any understanding from looking at a Russian text. I think people who know (i.e. use regularly, not studied for two weeks one semester in school) Lisp find it perfectly readable.
I'm a professional who uses Java (Score:5, Informative)
Re:I'm a professional who uses Java (Score:5, Informative)
Yes
> Does lisp has db connectivity?
Yes
> Does lisp have CORBA bindings?
Yes
> Does lisp have asynchronous messaging?
Yes
> Does lisp have naming and directory bindings?
Yes
> Does lisp have web page templating functionality?
Yes.
Two points more:
1. Doubt is not knowledge. Many people THINK they know about the popularity of Lisp because they don't hear as much about it as they hear from the hype languages (which is quite logical).
There are far more Lisp projects going on than people imagine, only people don't scream out "HEY! COOL! I'M DOING IT WITH LISP!" they go "Yepp, I'm using Lisp." the Yahoo Store engine for instance. Microsoft's Bob. Many industrial applications (not only the academia!).
2. The syntax isn't hard to read, it's just hard for people not used to it. This is, of course, true for every language.
Besides: Common Lisp is not strongly typed but you can strongly type a specific function by declaring what types the arguments will have. That makes Lisp a "strong typing on demand"-language in my point of view.
Re:I'm a professional who uses Java (Score:2, Informative)
Re:I'm a professional who uses Java (Score:5, Insightful)
The reason why it's not hyped is because Lisp HAD a hype in its history whose decline happened to the same time (and was mostly induced by) the AI winter.
Most Lisp programmers from that time have still a bad taste in their mouths because of that hype (mind, that the hype was over was not because Lisp is a bad language but because the AI winter) so they won't start another.
Younger Lisp programmers (like myself) are both happy and unhappy about the lack of a hype.
Happy because that means you have a much more undisturbed basis on which you can settle your community. The community efforts and activities are easily overseeable and you always know what's going on.
Unhappy because the community isn't very large and so activities DO happen, but more slowly than in the Java or Perl community because we have fewer people.
As an example: that article is from 1999 and is widely known in the Lisp community... but only today it has been published on Slashdot.
If someone writes an article about Perl, it is released immediately here.
Keep in mind that 2 years are an eternity in computer terms.
Re:I'm a professional who uses Java (Score:2)
Re:I'm a professional who uses Java (Score:2)
Re:I'm a professional who uses Java (Score:2)
No need for the "was". Objective C is the primary development language for Mac OS X, which probably already has a larger installed base than NextStep/OpenStep ever did. And GNUStep is steadily coming along.
Re:it's in the name (Score:2)
Re:it's in the name (Score:2)
Re:I'm a professional who uses Java (Score:2)
Thank god the Microsoft Bob team didn't trumpet its use of LISP. LISP has a hard enough time getting good press as it is - why throw a poisoned pill like that in?
Re:I'm a professional who uses Java (Score:2, Informative)
- http://www.franz.com/products/ [franz.com]
- http://www.xanalys.com/software_tools/products/id
e .html [xanalys.com]
Handy link with a lot of information http://ww.telent.net/cliki/ [telent.net]More Lisp vendors:
'Free' (whatever the current definition of that is nowadays) Lisps:
Re:I'm a professional who uses Java (Score:2, Insightful)
second, you complain about the simple syntax. this is perhaps lisp's greatest feature. lisp supports macros like no other language. it is easy to make a program which generates code if the target has a simple syntax. why do you think gcc converts C into a lisp like language for processing? programming in the simple syntax of lisp allows you the programmer to program the language to suit your problem. alas, the power of such abstraction is sometimes not appreciated.
database access exists for lisp. corba exists for lisp. i've seen lisp to html generators. why don't you come to comp.lang.lisp and post this. between the flames you may be enlightened.
Does Java have web page templating? (Score:2)
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 [sourceforge.net]. 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.
Re:I'm a professional who uses Java (Score:2)
Re:I'm a professional who uses Java (Score:2, Interesting)
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.
Re:I'm a professional who uses Java (Score:2)
Seeing stories like this (and having the relatively sheltered career, such as it is, that I've had), I've often wondered why management worries about finding (insert language) programmers rather than just finding good programmers (with the assumption that a truly good programmer will be able to relatively rapidly acquire whatever skill set is necessary). I don't dispute that one can probably find more Java programmers than Lisp programmers, but can one find significantly more truly good Java programmers than good Lisp programmers?
To the untrained eye (like mine), it's also always mysterious why, when your team was able to build everything necessary with four programmers, a good management would want to a) take on a lot of extra people (and salary, no doubt) and b) take on the risk associated with a transition rather than c) just make sure that you four remained sufficiently well compensated that you'd want to stay on and continue meeting their needs. It'd seem to me that c) would be not only less risky, but less expensive.
Important point: Functional orientation (Score:2, Insightful)
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.
Re:Important point: Functional orientation (Score:2)
Plus, if you really want to close this back door, you can start uninterning symbols. I can't think offhand of any way someone could get their hands on something that that's been done to.
1999 (Score:3, Insightful)
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..
Re:1999 (Score:1)
Re:1999 (Score:2)
Learning Lisp? (Score:1)
Re:Learning Lisp? (Score:3, Informative)
Read "Structure and Interpretation of Computer Programs" by Abelson and Sussman.
It is a fabulous book for introduction into functional thinking and shows many enlightening things about what you can do with Lisp in general and in this case Scheme.
Your next step might be "ANSI Common Lisp" by Paul Graham, giving an introduction into the Lisp dialect with which major applications in the industry are done (REALLY done, Franz Inc. and Xanalys, both commercial Lisp implementors and vendors have increasing sales over the years) - also a very clear and easy to follow book with lots of examples and exercises and a very cool reference which I tend to use a lot while Lisp coding.
If you prefer online information, you can find many links and pointers to Lisp on the webpage of the Association of Lisp Users (ALU, http://www.alu.org [alu.org]).
(Yes, I'm paid to code in Lisp)
(Yes, it's a lot of fun)
Re:Learning Lisp? (Score:1)
(I myself am more a Common Lisper).
The "bad programming styles" you're speaking of are the dominance of recursion over simple iteration, I presume?
Please tend not to speak humble in these posts because people's opinion will be influenced by that.
Have you read "Structure and Interpretation of Computer Programs", btw?
Re:Learning Lisp? (Score:2)
You may have missed the point. The authors of SICP aren't trying to teach a programming language. They're trying to teach how to program, and, in the opinion of many (myself included), do a very good job. Scheme is incidental to their actual task (although it does suit it well).
Re:Learning Lisp? (Score:1)
Once more suggestion : never ever write Lisp without a decent editor (Emacs comes to mind). Backeting hell awaits.
Good LISP story (Score:1)
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)
Interesting, but flawed? (Score:5, Insightful)
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.
Re:Interesting, but flawed? (Score:3, Interesting)
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.
2) Lisp has been around since the 1950's, in one form or another. I find that I can read lisp code from the Lisp 1.5 programmer's manual, which originated in 1965. Our kids will probably still be able to in another 30 years.
3) How large is large enough? Is: "language of choice for 10^7 illiterate script-kiddies" a stronger recommendation than: "there are a sufficient number of competent programmers who are proficient in the language and familiar with the problem domain"? Notice that second statement is probably not true for any of the languages discussed, for most problem domains.
4) Except for the Microsoft offerings, pretty much everything is cross platform. Think gcc and cmucl, for easy examples.
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?
As for mature compilers, again, I think all of the languages mentioned so far are in fair shape there. Java and c can both use the same back end in gcc, and so does gcl.
6) Technically, all the languages mentioned are Turing-complete
After going over the above, it looks to me as if personal choice and the resources immediately at hand are really the only reasons to pick lisp over c over c++ over java over lisp.
Re:Interesting, but flawed? (Score:2, Insightful)
I don't think that's a fatal flaw
Well, it is, assuming you're trying to make the kind of generalization that the original paper [acm.org] was trying to make. The original author took a randomly selected bunch of programmers who claimed to know either Java, C, or C++ and assigned them the task. In comparison, Mr. Gat's paper [nasa.gov] was based on a call to a bunch of dedicated LISPers. whose expertise one could reasonably expect to be much higher than someone who might have taken a LISP programming class N years ago.
You really can't compare the two papers. Either you get "experts" on both sides, or you get randomly chosen programmers on both sides, but not a mix.
IDE can be a great training tool... (Score:2)
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.
Ocaml instead of Lisp (Score:2, Informative)
Re:Ocaml instead of Lisp (Score:2, Informative)
Perhaps not quite as illuminating as it appears (Score:1)
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
Re:Perhaps not quite as illuminating as it appears (Score:2)
This sort of thing is an annoying recurring theme in our industry. The fastest G4 based Macs may or may not be faster than the fastest P4 based PCs. But it's impossible to get a good comparison because the Mac addicts keep pointing at photoshop and the PC addicts keep pointing at Quake.
According to the two economists who determined that the Dvorak keyboard is better than the Qwerty keyboard without the burden of scientific research: Java, C and C++ *must* be better than Lisp; or Lisp does not provide significant advantages over Java, C and C++ because if Lisp did, then businesses would adopt it in order to save money.
Just once I'd like to see a really fair comparison based on rigorous effort.
There is more data available for other languages.. (Score:5, Informative)
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 [ira.uka.de] (a detailed technical report is here [ira.uka.de]).
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 [ira.uka.de] are interesting too (as many other research papers ; found via citeseer [nec.com] for instance)
The whole premise is wrong (Score:1)
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.
CLOS (Score:1)
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.
Re:The whole premise is wrong (Score:1)
Common Lisp (and Scheme too, although the Schemers usually a) don't like to hear that and b) don't tend to program that way) is a hybrid language. That means, it isn't "just" functional, you can program imperatively as well.
Object systems exists for both Lisp "paths", so object-orientedly as well, and, as in CL you usually program a programming language suiting your task, you can use whatever programming paradigm comes to your mind.
It's different to program in Lisp not because Lisp restricts you to some phony paradigms, it's different because Lisp doesn't restrict you at all. And the (at first glance) strange syntax is a small price to pay for that.
Lisp Redux (Score:1)
It seems Slashdot hosted an almost identical discusion [slashdot.org] 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?
Lisp (Score:3, Insightful)
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.
Not really (Score:2)
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.
Read the history of LISP Was Re:Lisp (Score:2)
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.
Re:Lisp (Score:2)
This couldn't possibly be true with
Lisp is nice but Smalltalk is better (Score:3, Insightful)
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.
I've written 2 Lisp and 4 Java books (Score:4, Informative)
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
Re:I've written 2 Lisp and 4 Java books (Score:2)
Two good choices are CMUCL and CLisp. Information for both of these may be found at www.cons.org [cons.org]. (Warning-there have been some problems with the site lately. Be patient or try again if there is a problem. :-)
Emacs Lisp is mostly suited for writing Emacs and extensions thereof; it differs from more modern Lisps in some important ways. Of course, one should still know it to facilitate customization of Emacs. :-)
Re:I've written 2 Lisp and 4 Java books (Score:2, Informative)
The Xananlys free educational system is very usable as-is. The only real constraints on the free personal version is that it will only run for 5 hours (then you simple have to restart the IDE) and that you can not save small stand-alone executables.
That said, try the free personal version, and if later you need to distribute small compiled applications for Linux or Windows, then buy the Pro version.
Under Linux, CMU Common LISP is free and generates very fast compiled code. Under Windows, Linux, etc., CLisp is free and although uses compiled pseudo-code, it is fairly fast, and uses very little memory so it is very appropriate for writing small scripts and utility programs.
-Mark
Why Java succeeded, LISP can't make headway now (Score:5, Informative)
In this LinuxWorld interview [linuxworld.com] 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 [ddj.com] 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 [umn.edu] 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.
Lisp is standarized. (Score:2, Informative)
> 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 [xanalys.com] 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 [schemers.org].
Common Lisp vs. Lisp (Score:3, Insightful)
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 [paulgraham.com]. 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.
Re:Common Lisp vs. Lisp (Score:2, Insightful)
In my experience, most people who "attack Lisp" direct their tirades against Lisp 1 - 1.5, or the all-caps Lisp which appears in, say, Tanimoto's Elements of Artificial Intelligence (1987). Analogous are those clever critics who blast Fortran. Only after you inquire deeper, it becomes clear they are talking about Fortran-77, Fortan-66, Fortran-IV, or even Fortran-II.
Why Lisp is just academic (Score:2)
What about GUIs? (Score:2)
Re:What about GUIs? (Score:2)
There's always CLIM for such things.
Re:What about GUIs? (Score:2)
Hm, I'm still looking for a *good* GUI toolkit for Java, preferably something with nice functional constraints instead of the overarchitected event framework of awt and swing. About the only GUI framework that I really liked was FranTk in Haskell, which sadly was a ferocious pain to compile. I'm not a functional nazi, I just don't like doing everything "by hand", which is what it feels like in Java. Last I looked there wasn't even a packing layout manager in Java like Tcl/Tk has, I had to get it third-party.
Anyway, I plugged your question verbatim (minus the question mark at the end) into Google, and came up with a gigantic list of toolkits, including a standard API for GUIs in common lisp called CLIM.
Any toolkit is going to be limited to the platforms it's been ported to -- it's not as if Swing magically works when the core JVM is ported after all.
Re:What about GUIs? (Score:2, Interesting)
I am not sure what you mean by a packing layout manager (but you can tell me next time you see me on IRC).
I do see a list of toolkits, but they all seem to be based on terrible base toolkits, like Tk or WxWindows, or are not portable at all.
CLIM is a good idea, but I cannot find any free (beer) implementations, which seriously limits its usefulness.
Swing has the property that, since it is written almost entirely in Java, it can be ported with little effort. Bindings need not be written for each component, but only for windows (Xlib meaning) and a few other things. Unfortunately, this tends to make it a bit slow, but that's not a concern for me.
Re:What about GUIs? (Score:2)
There is a Free-CLIM project, although I don't know its status
It's unclear, though, how the lack of free CLIM implementations makes any statements about its usefulness. It merely indicates that you are either unable or unwilling to use a commercial implementation, which is fine, but really only makes a very local statement about it's usefulness (viz. that it's not useful to you in particular).
Re:What about GUIs? (Score:2)
LISP is first computer language at MIT (Score:2)
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.
Some hopefully useful points (Score:2, Informative)
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 [paulgraham.com].
Reading through his articles [paulgraham.com] 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 [paulgraham.com] ... It resonates with my experience as well. Also This response [paulgraham.com]
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 [endpointcomputing.com] 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.
Functional vs. OO (Score:2, Insightful)
Lisp and Java are both good langauges (Score:3, Insightful)
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
Re:Multithreaded Apps? (Score:2)
Specifically what features do you feel that a Lisp such as Lispworks (as Mark mentioned) or Allegro do you feel are missing that makes building multi-threaded applications a problem? For your reference, the chapter of the Lispworks Reference manual describing the MP package is here [xanalys.com]
Re:Having done some things in lisp (Score:2)
Agreed that Lisp won't put you close to the hardware (in most cases - there are always the Lisp machines :-). Disagreed that it's hard to do bit twiddling. In fact, there are two different good ways to do bit twiddling: bit-arrays and their associated functions, and ordinary integers together with the logwhatever, dpb, ldb etc. functions.
I can't really address suggestion 1, though I can't ever remember being particularly ill-treated by anyone. As for 2.:
Re:Why not FORTH (Score:2)
I wish it had a Linux port, since that's what I use exclusively these days.
Re:Server Side Scripting (Score:2)
Re:Learning Lisp/Scheme for real world apps (Score:2)