paulgraham.com · Domains · Slashdot Mirror

Re:Bayesian Filtering Flaw? by Kenard · 2002-08-19 16:23 · Score: 1 · on Slashback: Pop-Ups, Books, Qmail

I'm in a similar situation, a lot of spam and little real mail. Although there would be a lot of spam compaired to the lagit mail, the proposed method takes into account how many msg you have of each spam and non-spam, which should take care of outweighted spam/non-spam msg.
p.s. I am working on too, though for kmail. I admire how fast he got his working.

Re:One way to do it by DoctorFrog · 2002-08-19 00:41 · Score: 2 · on The Continuing Rise of E-Mail Marketing

how do you know what is spam to some people isn't useful to others? And who gets to decide?

Yes, I see your point; basically you have to hand the decision over to someone else. Perhaps private companies could compete with spamlists and you could go with the one that you trusted, which avoids the need for legislation completely.

Even so, it's not a complete solution since the spamlists will always be playing catch-up, and the only way to know if you agree with their latest choices is to check (defeating the purpose), and there'd be endless suing of the spamlisters by people saying, "But I'm not a spammer, and this isn't my nose, it's a false one!"

Bah, another beautiful idea slain by closer logical examination. :-( Back to the drawing board! So far the best idea I've seen was the filtering mechanism proposed by Paul Graham a short time ago. I'd love to give it a try, anyway, whenever it becomes generally available.

Paul Graham on Fighting OOP by Tablizer · 2002-08-16 07:42 · Score: 2 · on Paul Graham on Fighting Spam

Paul's
Why Arc is not especially object oriented

I would personally like to see Paul Graham spend even more time fighting OOP than spam. The second one is a lost cause arms-race IMO.

Here is something that rang true with me on his OOP musings:

Object-oriented programming is like crack for these people: it lets you incorporate all this scaffolding right into your source code. Something that a Lisp hacker might handle by pushing a symbol onto a list becomes a whole file of classes and methods.

I think using databases (properly) are the same way: a single relational formula does most of the work of a bunch of classes and "hand-indexing" these classes and methods together. (AKA GOF-math)

OOP hard-wires the "noun structure model" into the code (what Paul calls "scaffolding"). LISP and relational techniques tend to use *formulas* to manage these instead of physical code structure. IOW, we don't build structures, we order the information to build *itself* into the needed structures. (OO has the concept of "self-handling nouns", but it lacks the concept of self-handling structures, or interlinks, between those nouns.)

It less disruptive to change a formula than change the physical structure of the code.

OOP fans spend too much time looking for "the proper pattern or model". If you do it right, there is no one proper model or structure: it is virtual views that you create on an as-needed basis and can change on an as-needed basis without a bunch of code rework. You can also have multiple different views without them stepping on each other.

OOP creates code and work that is unnecessary and fragile.

(oop.ismad.com)

arc by Anonymous Coward · 2002-08-16 04:18 · Score: 0 · on Paul Graham on Fighting Spam

I wonder when Paul will release arc to the world.

Re:Try Common Lisp by alispguru · 2002-08-08 02:26 · Score: 2 · on Is FORTRAN Still Kicking?

I apologize for my tone, but this kind of misinformation is understandably a sore point with Lisp people. Paul Graham's On Lisp is a great book for explaining modern Lisp style, as well as dispelling Lisp myths. The dead trees version is out-of-print, but the ps/pdf versions are available for download. Also check out his Articles page.

Re:Try Common Lisp by alispguru · 2002-08-08 02:26 · Score: 2 · on Is FORTRAN Still Kicking?

I apologize for my tone, but this kind of misinformation is understandably a sore point with Lisp people. Paul Graham's On Lisp is a great book for explaining modern Lisp style, as well as dispelling Lisp myths. The dead trees version is out-of-print, but the ps/pdf versions are available for download. Also check out his Articles page.

This is flamebait... by alispguru · 2002-08-06 03:01 · Score: 2 · on 10 Reasons We Need Java 3

... but I can't resist it. This laundry list is an instance of "all programming languages evolve toward Lisp, specifically Common Lisp. Of the ten points mentioned in the article, Common Lisp has had answers to almost all of them, ever since about 1985 or so.

10. Delete all deprecated methods, fields, classes, and interfaces.

When CL deprecated things, it did so by creating a new default top-level namespace (a "package" in CL terms) and leaving the deprecated stuff behind. The old namespace and the new one shared most symbols, so old and new stuff could coexist, but in general deprecated stuff would be flagged and had to be specifically requested for it to work.

9. Fix incorrect naming conventions.

CL is in general not case-sensitive, so it ducks the properStudlyCaps problem. CL names have always been unabbreviated except for a few historical symbols.

8. Eliminate primitive data types.

Never had 'em.

7. Extend chars to four bytes.

The exact size of the char datatype is not part of the CL specification. Implementations can and have made it bigger over the years, and programs that care can check at runtime if the implementation has big enough chars for their purposes by making a specified environmental inquiry.

6. Fix threads.

Threads aren't part of the CL language. Every major implementation has them, though, and all of them are easier on programmers than Java's threads (see here - scroll down about halfway to "You can't close over anything but final variables in an inner class!").

5. Convert file formats to XML.

Always had S-expressions as a default universal file format. See my .sig below.

4. Ditch the AWT.

CL doesn't have a specified GUI. The closest thing it has is CLIM, which had a lot of the speed and resource problems Java GUIs have. We had them ten years ago, though. The commercial CLIM implementations are quite useable these days.

3. Rationalize the collections.

CL's collections have always been rational. It mostly comes from #8 above - when objects are typed and variables are not required to be, most of your problems go away.

2. Redesign I/O.

CL's abstract interface to filesystems and pathnames has always been less Unix-centric.

1. Redesign class loading from scratch, this time with human interface factors in mind.

I gather a lot of his complaint here stems from the distinction in Java between an interface and a class. This distinction is there because of the Java designer's allergy to multiple inheritance, which CLOS has had since day one.

There, have I pissed enough people off yet?

Re:That's a really clear book by Furry+Ice · 2002-06-03 14:26 · Score: 1 · on Conceptual Models of a Program?

You should read his book "On Lisp" next. "ANSI Common Lisp" doesn't cover macros in much detail. "On Lisp" spends the majority of its time on them. Unfortunately, it has gone out of print, but Graham has made it downloadable from his site.

the Lisp way.... by Kernel+Corndog · 2002-06-03 13:55 · Score: 1 · on Conceptual Models of a Program?

You might want to check out Paul Graham's site Especially his downloadable book 'On Lisp' The first chapter of that book has thoughts especially about why planning before implementation isn't really suited for building programs like it is for building dams. Instead he recommends planning as you write code. Of course having a language that is best suited for this style of programming is highly recommended :).

I have to admit that I'm a relative Lisp newbie but the more I study it the more I see why people love it so much...And I yearn to see a Lisp Machine for they were already dead before I knew the power of Lisp.(Wouldn't you like to know why people thought Lisp as OS was superior to Unix?) Paul Graham undoubtedly has a more scholarly explanation of this technique than I can give it credit to in the meager submission..

So when you are weighing all the suggestions on how to streamline those flowcharts give a good look to the one that says throw the flowcharts out the window and let 'code evolution' take place!

Another option by jabbo · 2002-06-03 11:22 · Score: 5, Informative · on Conceptual Models of a Program?

I feel like Paul Graham's "ANSI Common Lisp" is more fun to work through (and makes my brain hurt somewhat less) than SICP. SICP is a really stiff book -- using that text for a class is a sure way to weed most people out. Graham's book, while very very intelligent and deep, is also a lot easier to grasp in many respects. Not a bad choice for 'SICP Lite' although that doesn't give it enough credit for what it teaches you about programming in the real world (vs. the computer-linguistics and mental gymnastics that SICP teaches you).

(Read the articles on Graham's site. They're friggin' amazing distillations of experience. If you've been programming (successfully) for long enough, you'll not only be pleasantly surprised, but will find yourself nodding in agreement whilst learning about new topics. Anyways, the book is an implementation of much of what he writes about, into his 'Mother Tongue' of Common Lisp. Hell, this is one of the few good writers who can correctly answer the question:

"If you're so damn smart, why aren't you rich?"

The answer, for anyone whose opinions you'd want to trust, is "I am", and it's BECAUSE of his opinions. :-))

Deja vu by mrdlinux · 2002-05-22 18:46 · Score: 2 · on Wall and Conway Answer Perl 6 Questions

Malleable syntax, closures, better OO, better exception handling, wow...

...who knows, someday Perl may become a Lisp. Just like Python, Ruby, and friends.

CLOS *isn't* OO? by alispguru · 2002-05-16 06:33 · Score: 3, Interesting · on Bitter Java

I suspect you and I have different definitions of OO. The problem is that damn near everyone has a slightly different definition of OO. Go read this article by Johathan Rees, then come back and tell us what you mean by a "real OO system", and why you can't do it properly in CLOS.

Re:Design patterns and Lisp by jaoswald · 2002-05-16 03:36 · Score: 5, Insightful · on Bitter Java

It's not that every Lisp program has a different design, any more than every machine has the same design; however, in Lisp, there tend to be fewer obstacles to expressing a particular program design in the language. There are a wide range of reasons for that.

One is the pervasive nature of intrinsic typing. Variables are not typed, values are. Object-oriented methods, of course, explicitly mention classes, but non-OO code does not need to explicitly type variables, except to improve performance. The flexibility of many built-in Lisp operators helps deal with multiple types transparently. For instance, length of array, length of a string, and length of a list all use the same function: LENGTH.

Another source of flexibility is Lisp macros, which can use the full power of the Lisp programming language to rearrange and process Lisp macro calls into Lisp code. If there is some design pattern that Lisp does not natively support, you can use Lisp macros to create a Lisp "dialect" that cleanly expresses the design.

Paul Graham, in his books, demonstrates, for instance, that if Lisp did not already have CLOS to express object-oriented concepts, that in about a hundred lines of pretty clean Lisp macrology, you can add single-dispatch methods to the language, and it looks just like "real" Lisp, and mixes with the base language transparently.

It took Stroustrup a large effort (cfront) to add objects and methods to C, and it requires explicitly invoking a compiler program to do the translation, with name-mangling and everything else. In Lisp, you would write Lisp macros to do the same thing, and you would still be working in true Lisp. You can also add macros on macros: cfront is basically a monolith, but Lisp macros can work together; you can continuously "build up" from the language foundation, and the various layers can be overlapped.

Any time you find yourself repeating a pattern, it suggests a Lisp macro. If you have an example of the pattern already written, it is pretty much cut-and-paste to create the general macro from the specific pattern instance.

That kind of flexibility, which allows the programmer to mold the language to fit his (and his tasks) needs, is really what makes Lisp great to work with.

It's something like the difference between working with Legos and clay. If you're missing a Lego part to serve a particular function, you're pretty much stuck, unless you want to injection-mold your own custom blocks. Therefore, Lego models tend to use "design patterns" where the standard blocks or parts fit together a certain way that solves a certain class of problems. Lego models, although they can be amazing achievements, all tend to look like Lego models.

With clay, however, the medium is fluid. You can mold it to just about any shape you want. Sculptures usually look like their subject, not like clay.

Common Lisp does every last thing you mention by NewOldGuy · 2002-04-30 03:05 · Score: 1 · on Downsides to the C++ STL?

I'm looking forward to somebody starting over some day and coming up with a language that supports generic programming as well as C++, but which doesn't have the terrible syntax of C++ templates. It must be possible.

Yup. Common Lisp does all that plus everything you reference below... To keep this short(er), search slashdot for Kent Pitman and read his two-postings interview about Lisp. Go to www.paulgraham.com and download his free book On Lisp. Download GCL, CLISP, CMUCL, or Xanalys' or Franz's personal editions and work through every example in Paul's book, typing it in running it until you understand.

Common Lisp compiles to very fast code, Xanalys offers unlimited runtime distributions and, I've been told, very flexible support for what's included in the runtime.

On Lisp changed my programming worldview. I've been programming STL for years but now see large parts of it as an attempt to bring a small part of Lisp to C++. STL succeeds in that, and I do enjoy STL programming. However, why not just use Common Lisp which has all that and much, much more?

...templates can can be used to create programs that run at compile time to do some very clever optimizations

Lisp does that...

But the code to make this stuff happen is ATROCIOUS!

Not in Common Lisp, it's not. Define a macro instead of a function and selectively add backquotes and commas. Otherwise, it's plain old normal CL.

I think what is needed is a new language that will put compile-time and run-time code on equal footing. It would be great if they had the same syntax. ...

Lisp does that.

...say something Lisp-like...

You mention Lisp but you don't mention that Lisp does everything you're asking for. Hope I'm not boring you, and there's probably someone else who didn't know Lisp does all this. In addition, I know that Xanalys in particular (as probably do all the others, with whom I have less direct experience) makes calling OS functions nearly trivial. I've not yet tried callback functions under Windows. Your mileage may vary. I am not associated with Xanalys although I did just buy their Lisp because of the unlimited runtime distribution. I learned Lisp using GCL under Linux. I am not a lawyer. I ....

Sounds to me like it's time for some new language stud to come and save us.

Sound to me like it's time to pay attention to the old language studs. Seriously, with GPL implementation, commercial implementations with unlimited runtime distributions, etc., very fast compiled code.... it seems to me that unless you:

are doing real-time apps where garbage collection is unacceptable (and you're unable to write Lisp code that avoids the GC)
really need to pay attention to the final object code's size (critically need - as noted before, STL doesn't cause template bloat in non-debug compiles).
hmmmmm I'm running out of reasons here
Human factors - "nobody uses Lisp", "we'd never find programmers", "all those parenthesis"

Note: modern editors make the parenthesis comfortable. They are the key to making Lisp extensible because anything following an open parenthesis is a function to be called. Define a function, you just added new syntax to Lisp. You can redefine existing functions, including those in the base package such as addition:

(defun + (* a b))

and addition is broken everywhere. Lisp is a power tool and should be kept away from children. Use it if you really need to build something incredible.

What other reasons are there not to use Lisp? Lisp has had the features you named as important. Lisp has had them for years. And, speaking as one who has experience with STL, you simply don't need an STL in Lisp. Lisp is truly a giant STL. I don't have to define and name all the miscellaneous little structures I need, I just construct and use them on the fly. Not to mention closures, functions as first-class objects, lambda's (i.e. unnamed functions defined even in parameter lists), macros, run-time typing... the read-eval-print loop for debugging, the ability to replace a function in the middle of a running system with no giant compile/link... geeze Louise it's phenomenal. All those things combined seem to obviate the need for 98% of the things I use classes for in C++/STL. I'll know more after I build something really big in Lisp and have a lot of people using it. I'm working on that...

I enjoy C++ and STL a lot. I'm really looking forward to a lot more finger time with Common Lisp. Don't want to give either one up. But my sense at the moment is that Lisp is by far the more powerful environment. It certainly does everything you mention in your post.

Lisp: the Meta-Programming Shangra-Language by SimHacker · 2002-04-29 11:35 · Score: 2, Interesting · on Downsides to the C++ STL?

The Meta-Programming Shangra-Language for which you yearn has been around for many years, and it's called Lisp.

Check out the Common Lisp Macro System, which is deeply explored in Paul Graham's free downloadable book On Lisp.

On Lisp is a deep, wonderful, mind-expanding book, originally published by Prentice Hall. It's earned five stars on Amazon. The book is out of print, but fortunately thanks to Paul Graham and Alan Apt of Prentice Hall, you can now download On Lisp for free !

-Don

====

On Lisp

Synopsis: Written by a Lisp expert, this is the most comprehensive tutorial on the advanced features of Lisp for experienced programmers. It shows how to program in the bottom-up style that is ideal for Lisp programming, and includes a unique, practical collection of Lisp programming techniques that shows how to take advantage of the language's design for highly efficient programming in a wide variety of (non-AI) applications.

KEY TOPICS: Contains comprehensive presentations of key Lisp features: functions, macros, symbols and interning, variables, scope and lexical closures; object-oriented programming, data structures, and Lisp style. For experienced Lisp programmers.

TOC:

1. The Extensible Language.
2. Functions.
3. Functional Programming.
4. Utility Functions.
5. Returning Functions.
6. Functions as Representation.
7. Macros.
8. When to Use Macros.
9. Variable Capture.
10. Other Macro Pitfalls.
11. Classic Macros.
12. Generalized Variables.
13. Computation at Compile-Time.
14. Anaphoric Macros.
15. Macros Returning Functions.
16. Macro-Defining Macros.
17. Read Macros.
18. Destructuring.
19. A Query Compiler.
20. Continuations.
21. Multiple Processes.
22. Nondeterminism.
23. Parsing with ATNs.
24. Prolog.
25. Object-Oriented Lisp.
Appendix: Packages.
Notes.
Index.

From The Publisher: Starting in the 1980s, Lisp began to be used in several large systems, including Emacs, Autocad, and Interleaf. On Lisp explains the reasons behind Lisp's growing popularity as a mainstream programming language. On Lisp is a comprehensive study of advanced Lisp techniques, with bottom-up programming as the unifying theme. It gives the first complete description of macros and macro applications. The book also covers important subjects related to bottom-up programming, including functional programming, rapid prototyping, interactive development, and embedded languages. The final chapter takes a deeper look at object-oriented programming than previous Lisp books, showing the step-by-step construction of a working model of the Common Lisp Object System (CLOS). As well as an indispensable reference, On Lisp is a source of software. Its examples form a library of functions and macros that readers will be able to use in their own Lisp programs.

====

Lisp: the Meta-Programming Shangra-Language by SimHacker · 2002-04-29 11:35 · Score: 2, Interesting · on Downsides to the C++ STL?

The Meta-Programming Shangra-Language for which you yearn has been around for many years, and it's called Lisp.

Check out the Common Lisp Macro System, which is deeply explored in Paul Graham's free downloadable book On Lisp.

On Lisp is a deep, wonderful, mind-expanding book, originally published by Prentice Hall. It's earned five stars on Amazon. The book is out of print, but fortunately thanks to Paul Graham and Alan Apt of Prentice Hall, you can now download On Lisp for free !

-Don

====

On Lisp

Synopsis: Written by a Lisp expert, this is the most comprehensive tutorial on the advanced features of Lisp for experienced programmers. It shows how to program in the bottom-up style that is ideal for Lisp programming, and includes a unique, practical collection of Lisp programming techniques that shows how to take advantage of the language's design for highly efficient programming in a wide variety of (non-AI) applications.

KEY TOPICS: Contains comprehensive presentations of key Lisp features: functions, macros, symbols and interning, variables, scope and lexical closures; object-oriented programming, data structures, and Lisp style. For experienced Lisp programmers.

TOC:

1. The Extensible Language.
2. Functions.
3. Functional Programming.
4. Utility Functions.
5. Returning Functions.
6. Functions as Representation.
7. Macros.
8. When to Use Macros.
9. Variable Capture.
10. Other Macro Pitfalls.
11. Classic Macros.
12. Generalized Variables.
13. Computation at Compile-Time.
14. Anaphoric Macros.
15. Macros Returning Functions.
16. Macro-Defining Macros.
17. Read Macros.
18. Destructuring.
19. A Query Compiler.
20. Continuations.
21. Multiple Processes.
22. Nondeterminism.
23. Parsing with ATNs.
24. Prolog.
25. Object-Oriented Lisp.
Appendix: Packages.
Notes.
Index.

From The Publisher: Starting in the 1980s, Lisp began to be used in several large systems, including Emacs, Autocad, and Interleaf. On Lisp explains the reasons behind Lisp's growing popularity as a mainstream programming language. On Lisp is a comprehensive study of advanced Lisp techniques, with bottom-up programming as the unifying theme. It gives the first complete description of macros and macro applications. The book also covers important subjects related to bottom-up programming, including functional programming, rapid prototyping, interactive development, and embedded languages. The final chapter takes a deeper look at object-oriented programming than previous Lisp books, showing the step-by-step construction of a working model of the Common Lisp Object System (CLOS). As well as an indispensable reference, On Lisp is a source of software. Its examples form a library of functions and macros that readers will be able to use in their own Lisp programs.

====

Re:the STL is imporperly named by Anonymous Coward · 2002-04-29 09:30 · Score: 0 · on Downsides to the C++ STL?

I would like to see optional garbage collection (with fitting restrictions to legal programs) introduced into C++. That's the no. 1 thing holding back (advanced/modern) OOP in C++.

Why not just use Common Lisp? It has a lot of users, and it has garbage collection, and macros (like templates done right). It's object oriented, too.

Re:It is hard to learn well by Anonymous Coward · 2002-04-29 09:02 · Score: 0 · on Downsides to the C++ STL?

To sum it up, C++ with the STL is the only language that meshes (not always prettily) performance computing with high level concepts.

Only? Them's mighty strong words, bubba!

You might want to check out Common Lisp. See these links before you make a fool of yourself.

You could also qualify the statement to be something like: `` ... only buzzword-compliant language ... ''

p.s. Notice that I've accepted the proposition that c++ is a high-level language. I probably should have pointed out that that's a questionable assertion. Roll-your-own garbage collection is not high-level!

OO means different things to different people by alispguru · 2002-03-25 03:44 · Score: 2 · on Most Outrageous Vendor Lie Ever Told?

The best article I've seen on this subject is by Jonathan Rees - go look at it on Paul Graham's web site here.

People who say "Java isn't OO" really mean "Java doesn't have the features I like in other OO languages". Please say what you mean.

For the record, I'm a Lisp/CLOS hacker and I don't like the style of OO Java promotes.

Re:Get rid of C! by jacobm · 2002-03-05 09:14 · Score: 2 · on C

I'm not sure what you're arguing ... that C deserves a gold star? Sure. C deserves a gold star. (Though I'm not happy with C's happy-go-lucky attitude towards program safety.) That C is the most relevant important skill for programmers to have today? No. Definitely not.

Unlike buildings, we shouldn't start from scratch every time we write a new program; we ought to build up and only program the new stuff that's specific to our program and nothing else. C is terrible at that, which is why God gave us Lisp and the wisdom to use it. I have yet to hear anyone make a cogent argument as to why Lisp is inferior to C for general-purpose application coding (not systems-level stuff; e.g., why Excel, Word, Notepad, the calculator, Netscape, etc ought to be coded in C or C++ instead of CL or Scheme). And it's not like I haven't asked.

Re:Well.. what I DO know is this.. by Cardhore · 2002-03-04 03:40 · Score: 3, Interesting · on Will CS Students Switch From Microsoft?

Good point :)

Re:that's what I said .. by jacobm · 2002-02-26 17:01 · Score: 2 · on The Problem Of Developing

Scheme doesn't have for / next, while / do, or records/structures in its standard (though records are implemented in every useable implementation). Besides, high-power Lisp programming is all about macros, which don't even exist in any serious way in any other language (C macros are a joke in comparison; read On Lisp by Paul Graham for good reasons why). Your usual functional programming suspects -- Haskell, ML, etc -- as well as hard-core OO languages eschew most uses of the control operators you list in general.

Perl OO with Encapsulation, and other comments by n1vux · 2002-02-12 10:07 · Score: 2, Informative · on What Makes a Powerful Programming Language?

Firstly, comparing the core standard of one language with the latest extensions of another is a very old troll, and older than the USENET; probably dates to the DARPA lists, if not before in the IEEE and ACM paper journals. (I was using this troll back when PL/I was cool.) Nothing, not even Perl or or it's blood-brother PL/I, can be all things to all people. I hope the list of needed features actually addresses the next project's needs, we can't judge that from here.

Secondly, Perl OO is conforming with Perl's TIMTOWTDI (There Is More Than One Way To Do It) design goal. While native Perl OO is pretty casual in its encapsulation, if you want Bondage-And-Discipline OO, you can use one of Damian's Class::Classes, with Contract programming or Data hiding enforcement or ... there are at least 6 choices. At least one should have multiple inheritance grafted on, although I can't recommend actually using multiple inheritance of implementation (except maybe in CLOS); multiple inheritance of interface (like in Java or COM) seems safe enough.

Likewise, anything else Perl is missing can be added via other modules -- many of which probably already exist, but can be custom crafted on demand. This includes Operator Overloading, which can be added, for whatever cases are required, using Inline::Filter -- using the full power of Perl as a macro-language for Perl, to enhance the syntax as desired. Not for the faint of heart, but a good Perl consultant can whip it up for you.

GUI's -- Yes, it is true development of GUI's isn't built into Perl, unless you count the TCL modules as "built in". Ability to do GUIs does seem to run counter to portability (at compile time, whenever that is); this requirement may force your choice on Java. Perl has Gnome, TK/GTK, and Curses interfaces already. See CPAN

Thirdly, Perl6 will likely be mostly functional before .NET this summer, and _will_ be all things to all people, thanks to the modular bolt-on accessories. (Operator overloading will apparently be a part of the PARROT runtime for Perl 6, as well as in Perl6.)

Fourthly, Reality Context: Did The Boss specify that you had to be able to hire programmers in this language? Cheap or expensive? With lots of experience or not? Here or offshore? Eiffel's a great language, if you don't mind all your staff speaking French.

Regarding the evils of Lisp ... see the story of Yahoo!Stores Paul Graham: Beating the Averages or /. #1539239 for a real world $ucce$$ story with Lisp and why; amusingly, he turned up just last week /. #1917202.

-- Bill

I had a sigfile ... back when sigfiles were cool

Re:for starters by Ivan+the+Terrible · 2002-02-11 12:28 · Score: 2, Interesting · on What Makes a Powerful Programming Language?

In general I agree with your comment, but there is one significant aspect where choosing a language is important:

People seem to be limited in what they can conceive by their choice of language.

Paul Graham discusses this in an article called Beating the Averages that was posted on /. a while back (here)

Look at it this way: All the common languages are Turing complete, so they are all fundamentally equivalent. Do you then conclude that your choice of language is irrelevant? I think most people would disagree. Some things are a lot easier in some languages than in others.

So, although you're certainly partially justified in your rant, there is a germ of rationality in the original query.

Extensibility, e.g., Lisp or Scheme by Broadcatch · 2002-02-11 11:23 · Score: 1 · on What Makes a Powerful Programming Language?

It always amuses me that so many languages love to tout their object-orientedness that allows for language extensions. Lisp is inherently extensible, and by its very nature enables the programmer to design the language to fit the application. As far as debugging facilities go, Lisp is the gold standard. And WRT portability, I think Scheme runs just about everywhere.

People always think about AI when they think of Lisp, but don't forget that some everyday applications are written in Lisp, such as Yahoo! Store.

Yahoo Store is coded in Lisp... by Anonymous Coward · 2002-02-09 20:18 · Score: 0 · on One Runtime To Bind Them All

... as explained by Paul Graham.

FYI, It was sold for quite a bit of money.

Yahoo Store is coded in Lisp... by Anonymous Coward · 2002-02-09 20:18 · Score: 0 · on One Runtime To Bind Them All

... as explained by Paul Graham.

FYI, It was sold for quite a bit of money.

Issues with Lisp and .NET... by Anonymous Coward · 2002-02-07 04:23 · Score: 1, Insightful · on Functional Languages Under .NET/CLR

Some of the issues are business related, and others are technical. The Lisp vendors don't see what the CLR buys them except a new-found slowness and a lack of portability. This may change with Mono, but there are some severe architectural issues to address.

The CLR is based on the concepts of classes and single-dispatch, calling methods that "belong" to a class. Lisp's CLOS is built on multiple dispatch, and can cleanly support prototype object systems. It's hard to retrofit these capabilities onto a class and single-dispatch system, but it's easy to go the other way. Emulating multiple dispatch without the ability to re-compile on the fly leads to slow code.

And, socially, many Lispers see Java, .NET, etc. as shallow attempts to mimic what they've had for over a decade: A portable, reflective, dynamic environment. Java and many of the .NET languages leave out key portions of Lisp. Lisp allows programmers to control how the code is read, translated, and then compiled without leaving the language. You can build infix Lisp in Lisp, with all the tools of Lisp at your disposal. Or you can eschew many of the tools in Lisp, all from Lisp.

Re:Lisp books needed! by TimoT · 2002-02-06 20:41 · Score: 1 · on What Kind of Books do You Want?

There's plenty of lisp books available on the net for learning e.g.

Successful Lisp
Common Lisp Hyperspec(ANSI Standard Text on CL)
Common Lisp The Language
Common Lisp: A Gentle Introduction to Symbolic Computation
On Lisp(great book on lisp macros among other things)

you probably knew these but I put them there for the benefit of people looking to learn lisp. With ilisp you get an emacs mode, where you can look stuff up hyperspec while you write.

As for programming sound and games, I've done some stuff on sound programming, but the biggest problem is access to platform dependent libraries (i.e you have to write the bindings yourself) and the other problem is that the garbage collector is not real time (at least in CMUCL) so you may get clicks in the sound, if the GC starts doing its thing while playing. But you can get around that using a C-library running in another thread doing the playing. It's too complicated for my tastes though. I'd imagine game programming has similar problems. So to sum up: Multimedia in lisp sucks mostly due to lack of libraries and realtime support. Also trying to avoid consing in realtime code is painful at times (code all littered with declare, the and coerce), because the memory allocation is implicit (e.g. imagine boxing and type-checking x*44100 floats per second when doing realtime audio calculations).

Paul Graham said it best about Java... by Anonymous Coward · 2002-02-06 07:56 · Score: 0 · on De Icaza Responds on Mono and GNOME

take a look at this Java article

Re:Java's Cover by bugbear · 2002-01-31 05:35 · Score: 1 · on Java Native Compilation Examined

Though I did write this, I didn't post it here, and would not have. I wrote this to figure out for myself why Java seemed suspicious. Posting it on a forum like slashdot amounts to a troll.

I think this sort of article is barely worth writing (if something does suck, time will take care of it), and that's why on the site I put it near the bottom.

Re:Java's Cover by rusti999 · 2002-01-30 15:37 · Score: 1 · on Java Native Compilation Examined

This comment can also be viewed here.

Another large Lisp project by Syre · 2002-01-16 09:24 · Score: 3, Interesting · on Common Lisp: Inside Sabre

Yahoo shopping, was mainly written in Lisp too, as this article by one of the original authors of Viaweb (which is now Yahoo Shopping) details.

Re:My experience with Common Lisp by foote · 2002-01-16 07:18 · Score: 1 · on Common Lisp: Inside Sabre

Your story, and the Paul Graham article, are fascinating. But what does it mean when a Slashdot reader says: "I was never a serious programmer before I was introduced to Lisp..."

Were you low level like me, in that you know a bit of C and spend most of your time with Perl and Javascript? Or are you like a professor of mine, who said he was not much of a programmer, really, but who turned out to have a Master's from the University of Pennsylvania in computer language development, and a PhD from Georgia Tech in computer science (with an emphasis on databases, so maybe that's why he said he's not much of a programmer and more of a theorist.)

I'm going to start experimenting with Lisp, but I would like to know what kind of education and experience you had that helped you pick it up so quickly.

Re:Rule 1 of Efficient Lisp: Lisp is not functiona by ToLu+the+Happy+Furby · 2002-01-16 06:10 · Score: 5, Informative · on Common Lisp: Inside Sabre

I'd like to see somone post a couple of brief examples of things that were well-suited to Lisp (and would be much more difficult in C) - anyone have anything handy?

If you're interested is LISP, you should take a look at Paul Graham's excellent ANSI Common LISP, a wonderfully written introduction to LISP which is nonetheless a decent resource which can almost replace the much heftier Steele. If you're not sure you want to spend the cash, the first couple chapters are online.

In this very small, very chatty book for beginners with not too much code, Graham nonetheless manages to include examples such as a ray tracer (90 lines of code); a program to dynamically generate HTML pages (119 lines of code; this program (very much expanded, but without a single rewrite) now powers Yahoo! Stores); and a complete, seperate object-oriented language with multiple inheritence (89 lines; but a much more powerful OO language, CLOS, is already included with Common LISP). The last two in particular would be impossible to do as quickly or easily in C.

A much bigger LISP book I happen to have at the moment is Peter Norvig's Paradigms of Artificial Intelligence Programming : Case Studies in Common Lisp, which includes a whole lot of impressive and/or historically interesting examples, including ELIZA, STUDENT (solves algebraic word problems) MACSYMA (symbolic integration ala Mathematica), a Prolog interpreter and compiler, a Scheme interpreter, an optimizing LISP compiler, a natural language grammar parser, and a couple other things. I just finished (well, turned in...) a project which extended Norvig's code to play the game Othello, also from this book, to use trained neural nets (which unfortunately didn't train all that well). The coding part of this was made darn easy by the fact that Norvig's Othello function takes as inputs two functions which provide the move-selection strategies for black and white respectively--something that can't be done in a language without functional closures.

I certainly wouldn't want to do any of these in C; although all of them could be so done, it would only be at the cost of a good deal of length, functionality and elegence.

In general, LISP is great for anything involving GOFAI (good old fasioned AI, i.e. non-stochastic), anything that needs to generate hierarchically nested text (e.g. HTML, XML, or LISP programs), anything that needs to be written quickly (or LISP can be used as a rapid-prototyping language), any sort of interpreter, or for any time you wished you could modify the available programming languages to build one that really suits your problem. LISP is also great for extending existing programs, which is why almost every user-extensible application uses a dialect of LISP to do the job. (e.g. emacs, AutoCAD, etc. No, VB macros for Word don't count, although it is noteworthy that LISP is useful over such a wide range of programming tasks as to be a replacement for VB and C.)

What is LISP bad at? Well, its libraries can be rather weak and nonstandard (although ANSI Common LISP itself comes with a large array of useful functions); GUI stuff, multithreading, and networking all fit in this category and are often implementation specific. (Of course, this is nothing to do with the language itself but just with what tools are available.) Its use for really low level bit-twiddling stuff is somewhat awkward. Iteration in LISP suffers somewhat from being only a little bit more powerful than iteration in C; the upside is you can still combine it with all the other great stuff in LISP, but the downside is that the parenthisis-style syntax, which is so much better for writing macros and functional code, only clutters up iterative code.

And, certain of the most powerful features of LISP, like macros and closures-as-first-level-objects, take a bit of experience to wrap your mind around, as does the functional programming paradigm. (LISP does not in any way require functional programming; it's just that while there are other languages as good as LISP at iterative code and arguably as good as LISP at OO code, there is nothing as good for functional code.) This is usually taken to mean that LISP is only suitable for CS students and AI researchers, because ordinary programmers are too dumb to get this stuff. I'm just a CS student, and I haven't had much experience with how dumb ordinary programmers are or aren't, but intuitively I think this argument is bunk.

Personally I think these techniques are just new things to learn; subtle and powerful, sure, but so is simple recursion the first time you learn it and every programmer knows how to use that. Indeed, once you understand recursion well, functional programming and function closures are not very large conceptual leaps at all. Sometimes the mechanics of lambda closures can be slightly tricky, but no more so than referencing and dereferencing pointers in C, and with a lot greater payoff. Hell, the most complicated uses of functions as objects in LISP are a lot easier to get right IMO than even simple uses of templates in C++, and "templates" (i.e. generic funcions) come for free in LISP, due to runtime type checking. (Of course, this is why no one uses C++ templates, but whatever.)

Macros are difficult to write. But then again, they are incredibly powerful, and not "necessary" very often. And it's usually *extremely* easy to understand someone else's macro code, which is all a novice would have to do anyways.

Plus there are lots of features of LISP which make it incredibly easy for beginners. Debugging in LISP is ridiculously easy, at least for programs which don't use too many functional closures or complex objects. Instead of the C paradigm where you only have one big executable main(), LISP programs are made up of lots of little functions, all of which are callable (and thus extraordinarily easily debuggable) from the top-level evaluator. There's no write-save-compile-test-debug loop; it's all together, and all very fast. Immediate feedback means more willingness to take chances, try out things, and make mistakes.

Plus, because there's no main(), your programs are always extensible. If you want to, once you're done with a function it's trivial to make a larger function which calls the other function, takes it as an input, etc.

There is no need to manage memory, no need to futz around with pointers, and no way to cause a segfault until you start optimizing. Buffer overflows are impossible. You can start with a skeleton of a program, gradually add functionality, and only add optimizations at the end when you have tested your code; and you can test every new function or optimization, so you know exactly what goes wrong when something does.

And it's fast: once you put in proper optimizations, compiled LISP is nearly as fast as C. Of course this wasn't always the case, and it's not the case for LISP before you put in type declarations. And a compiled LISP file will probably be bigger than compiled C code, especially when you add the LISP top-level eval to it. On the other hand, C is usually not as fast or small as well optimized assembly code, but there is a good reason very few people program in that anymore: because programming in C makes your code less buggy and much faster to develop. Similarly, programming LISP will almost always make your code less buggy and much faster to develop than using C. Now that compiler technology and computer hardware have made those differences almost moot, it probably makes much more sense to use LISP than C.

Of course, the result of this change has not been to drive more people to LISP, but instead to drive LISP's features into other languages. Thus we have C++ with attempts at generic functions; Java with decent OO and automatic garbage collection; Python showing the usefullness of an interactive top-level. Nowadays Perl and Python are getting functional closures and the list datastructure, although their functions are not quite first-level objects and so not quite as powerful. Plus it will probably take another prefix-syntax language for macros to be copied properly.

Whether the world will realize that LISP already exists (and indeed has since the late 50's) or continue to reinvent it, I dunno. Probably the latter so long as LISP remains short of libraries that tie it down to modern computers. (Again, GUIs, multithreading, networking.) Still, it's probably worth learning LISP just so that when the same ideas come out in more "mainstream" languages years from now you'll already know and understand them.

Re:Rule 1 of Efficient Lisp: Lisp is not functiona by ToLu+the+Happy+Furby · 2002-01-16 06:10 · Score: 5, Informative · on Common Lisp: Inside Sabre

I'd like to see somone post a couple of brief examples of things that were well-suited to Lisp (and would be much more difficult in C) - anyone have anything handy?

If you're interested is LISP, you should take a look at Paul Graham's excellent ANSI Common LISP, a wonderfully written introduction to LISP which is nonetheless a decent resource which can almost replace the much heftier Steele. If you're not sure you want to spend the cash, the first couple chapters are online.

In this very small, very chatty book for beginners with not too much code, Graham nonetheless manages to include examples such as a ray tracer (90 lines of code); a program to dynamically generate HTML pages (119 lines of code; this program (very much expanded, but without a single rewrite) now powers Yahoo! Stores); and a complete, seperate object-oriented language with multiple inheritence (89 lines; but a much more powerful OO language, CLOS, is already included with Common LISP). The last two in particular would be impossible to do as quickly or easily in C.

A much bigger LISP book I happen to have at the moment is Peter Norvig's Paradigms of Artificial Intelligence Programming : Case Studies in Common Lisp, which includes a whole lot of impressive and/or historically interesting examples, including ELIZA, STUDENT (solves algebraic word problems) MACSYMA (symbolic integration ala Mathematica), a Prolog interpreter and compiler, a Scheme interpreter, an optimizing LISP compiler, a natural language grammar parser, and a couple other things. I just finished (well, turned in...) a project which extended Norvig's code to play the game Othello, also from this book, to use trained neural nets (which unfortunately didn't train all that well). The coding part of this was made darn easy by the fact that Norvig's Othello function takes as inputs two functions which provide the move-selection strategies for black and white respectively--something that can't be done in a language without functional closures.

I certainly wouldn't want to do any of these in C; although all of them could be so done, it would only be at the cost of a good deal of length, functionality and elegence.

In general, LISP is great for anything involving GOFAI (good old fasioned AI, i.e. non-stochastic), anything that needs to generate hierarchically nested text (e.g. HTML, XML, or LISP programs), anything that needs to be written quickly (or LISP can be used as a rapid-prototyping language), any sort of interpreter, or for any time you wished you could modify the available programming languages to build one that really suits your problem. LISP is also great for extending existing programs, which is why almost every user-extensible application uses a dialect of LISP to do the job. (e.g. emacs, AutoCAD, etc. No, VB macros for Word don't count, although it is noteworthy that LISP is useful over such a wide range of programming tasks as to be a replacement for VB and C.)

What is LISP bad at? Well, its libraries can be rather weak and nonstandard (although ANSI Common LISP itself comes with a large array of useful functions); GUI stuff, multithreading, and networking all fit in this category and are often implementation specific. (Of course, this is nothing to do with the language itself but just with what tools are available.) Its use for really low level bit-twiddling stuff is somewhat awkward. Iteration in LISP suffers somewhat from being only a little bit more powerful than iteration in C; the upside is you can still combine it with all the other great stuff in LISP, but the downside is that the parenthisis-style syntax, which is so much better for writing macros and functional code, only clutters up iterative code.

And, certain of the most powerful features of LISP, like macros and closures-as-first-level-objects, take a bit of experience to wrap your mind around, as does the functional programming paradigm. (LISP does not in any way require functional programming; it's just that while there are other languages as good as LISP at iterative code and arguably as good as LISP at OO code, there is nothing as good for functional code.) This is usually taken to mean that LISP is only suitable for CS students and AI researchers, because ordinary programmers are too dumb to get this stuff. I'm just a CS student, and I haven't had much experience with how dumb ordinary programmers are or aren't, but intuitively I think this argument is bunk.

Personally I think these techniques are just new things to learn; subtle and powerful, sure, but so is simple recursion the first time you learn it and every programmer knows how to use that. Indeed, once you understand recursion well, functional programming and function closures are not very large conceptual leaps at all. Sometimes the mechanics of lambda closures can be slightly tricky, but no more so than referencing and dereferencing pointers in C, and with a lot greater payoff. Hell, the most complicated uses of functions as objects in LISP are a lot easier to get right IMO than even simple uses of templates in C++, and "templates" (i.e. generic funcions) come for free in LISP, due to runtime type checking. (Of course, this is why no one uses C++ templates, but whatever.)

Macros are difficult to write. But then again, they are incredibly powerful, and not "necessary" very often. And it's usually *extremely* easy to understand someone else's macro code, which is all a novice would have to do anyways.

Plus there are lots of features of LISP which make it incredibly easy for beginners. Debugging in LISP is ridiculously easy, at least for programs which don't use too many functional closures or complex objects. Instead of the C paradigm where you only have one big executable main(), LISP programs are made up of lots of little functions, all of which are callable (and thus extraordinarily easily debuggable) from the top-level evaluator. There's no write-save-compile-test-debug loop; it's all together, and all very fast. Immediate feedback means more willingness to take chances, try out things, and make mistakes.

Plus, because there's no main(), your programs are always extensible. If you want to, once you're done with a function it's trivial to make a larger function which calls the other function, takes it as an input, etc.

There is no need to manage memory, no need to futz around with pointers, and no way to cause a segfault until you start optimizing. Buffer overflows are impossible. You can start with a skeleton of a program, gradually add functionality, and only add optimizations at the end when you have tested your code; and you can test every new function or optimization, so you know exactly what goes wrong when something does.

And it's fast: once you put in proper optimizations, compiled LISP is nearly as fast as C. Of course this wasn't always the case, and it's not the case for LISP before you put in type declarations. And a compiled LISP file will probably be bigger than compiled C code, especially when you add the LISP top-level eval to it. On the other hand, C is usually not as fast or small as well optimized assembly code, but there is a good reason very few people program in that anymore: because programming in C makes your code less buggy and much faster to develop. Similarly, programming LISP will almost always make your code less buggy and much faster to develop than using C. Now that compiler technology and computer hardware have made those differences almost moot, it probably makes much more sense to use LISP than C.

Of course, the result of this change has not been to drive more people to LISP, but instead to drive LISP's features into other languages. Thus we have C++ with attempts at generic functions; Java with decent OO and automatic garbage collection; Python showing the usefullness of an interactive top-level. Nowadays Perl and Python are getting functional closures and the list datastructure, although their functions are not quite first-level objects and so not quite as powerful. Plus it will probably take another prefix-syntax language for macros to be copied properly.

Whether the world will realize that LISP already exists (and indeed has since the late 50's) or continue to reinvent it, I dunno. Probably the latter so long as LISP remains short of libraries that tie it down to modern computers. (Again, GUIs, multithreading, networking.) Still, it's probably worth learning LISP just so that when the same ideas come out in more "mainstream" languages years from now you'll already know and understand them.

I have known about this for a bit by Anonymous Coward · 2002-01-16 00:42 · Score: 1, Interesting · on Common Lisp: Inside Sabre

As Paul Graham said at Beating The Averages, anyone who wants to run a business can say whatever they want in publicity, but they have to tell you their technology in their job ads.

Yahoo Stores uses Lisp by niola · 2002-01-15 21:33 · Score: 4, Interesting · on Common Lisp: Inside Sabre

I did some research a few months ago on Lisp since I am not very familiar with it and I discovered that Yahoo stores uses Lisp.

It would seem to me that if it can power 14,000 e-commerce sites for the largest web network that it must be pretty scalable.

Lisp, due to its recursive nature is often used in AI because it can perform operations with lower overhead.

--Jon

Re:I make a prediction... by Furry+Ice · 2001-11-28 05:28 · Score: 2, Insightful · on Lightweight Languages

Anyone who's a lisp fan (and those who'd like to be converted) should really read Graham's writeup of his LL1 presentation at http://www.paulgraham.com/arc.html

I'm really excited about this language. They're going to give an honest shot at making a lisp that will have more general appeal (read the part about onions: they're taking the "onions" out of common lisp), yet still maintain the raw power of macros. It should be very exciting.

McCarthy and Foderaro said it best by alispguru · 2001-10-26 08:47 · Score: 2 · on Ask Kent M. Pitman About Lisp, Scheme And More

John McCarthy said this in 1980:

LISP has survived for 21 years because it is an approximate local optimum in the space of programming languages.

More recently, John Foderaro said:

Lisp is a programmable programming language.

For my money, these two together cover Lisp's enduring advantages over newcomers.

Yes, you can get many advantages with strongly typed functional programming languages. But, you can get most of their abstraction power with Lisp's first-class functions and macros, without the pain and suffering of adhering to formality. Most Lisp hackers acknowledge the utility and power of functional programming, but use Lisp anyway because it doesn't force them to do everything functionally

Yes, Java, Python and Ruby have many of Lisp's features without Lisp's syntax. But, they don't have Lisp macros, so the abstraction power of designing your own language is not available to them. I use Lisp because it allows me to take FileInputStream infile = null; try { infile = new FileInputStream("foo") // Do stuff with infile } catch (Exception e) { // Report error munging infile } finally { infile.close(); }

and replace it with:

(with-open-file (infile "foo" :direction :input) ;; Do stuff with infile )

and get the same level of safety, with a lot less repetitious code.

Stop Complaining! by DroningDromedary · 2001-09-15 11:21 · Score: 3, Informative · on Artificial Intelligence Coding - Perl or Lisp?

If you've really only been programming in Lisp for a week or so then you really haven't had time enough to appreciate what its strengths and weaknesses are. It sounds to me as though you have acquired a disease that is all too common amongst programmers - the desire to want to specialise in one language too early on.

I simply cannot emphasise enough how valuable it is to learn as many programming languages as possible. Even if you don't really like it at first, a language can grow on you in ways you would have never imagined. No language is perfect, so knowing a selection of different languages will give you the opportunity to choose a tool that is appropriate to the job in hand. If the only tool you have is a hammer, then every problem you come across starts to look like a nail.

By keeping your horizons broad, most especially by learning languages that might seem strange, counter-intuitive or even downright annoying at first, I can assure you othat you will become a much, much better programmer in the long run. The ways in which languages differ can often give you an insight into the ways that different programmers might solve the same problem.

FWIW, the presence of closures and eval are not the only things that make Lisp distinctive from other languages. The one truly unique (not to mention incredibly powerful) feature of Lisp is macros. You will not be able to find these in Perl. Also, in Perl the standard way to solve problems is with an iterative, procedural style, where Lisp more often employs recursion and an applicative programming style, both of which are techniques well worth the effort to learn about.

Whether Lisp is better than Perl for AI is debatable. I'd argue in favour of Lisp for the following reasons: one is the fact that Lisp is extremely good at knowledge representation (and the subsequent manipulation of that knowledge), but more important is Lisp's ability to generate code with macros, effectively meaning that you can write programs to write other programs. It's also probably worth noting that Lisp is quite a lot faster than Perl, given a decent enough compiler. See The Programming Language Shootout if you don't believe me. Lisp is also a very mature language, with an ANSI standard, so unlike Perl you can be certain that it won't be pulling any carpets out from underneath your feet any time soon.

If I haven't done a enough good job of convincing you that learning Lisp is worthwhile (and I probably haven't) then try checking out Paul Graham's Beating the Averages. Also, be sure to check out Richard Gabriel's Good News, Bad News and How to Win Big. And have a read of Paradigms of Artificial Intelligence Programming by Peter Norvig for some more specific examples of Lisp as an AI programming language. Particularly relevant might be the section in the preface entitled Why Lisp?.

And when you're done with Lisp, I'd recommend a look at Ocaml, SML, Ruby and Smalltalk (particularly the delightful Squeak)!

Some hopefully useful points by dlakelan · 2001-09-08 07:20 · Score: 2, Informative · on Lisp as an Alternative to Java

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.