Slashdot Mirror

I've been trying to get the fascination with Lisp for twenty years, and consistently fail. APL was the first high level language I enjoyed using. It was beautiful and ugly at the same time and I found it instructive. As an array language R sucks in a way that APL never did. The beauty of APL lies in its regularity. The mathematical identities are wired so that you rarely code a special case in an elegant formula.

In either the APL or Lisp case you run into this little difficulty that the human brain has a parsing stack not much bigger than the 8087 coprocessor. Top level programmers are supposed to be different because we can store nine working objects in short term memory instead of five to seven. Maybe the reason only the four sigmas ever liked the Lisp language is that you need an eleven element parenthesis mental stack to get to the point where those damn parentheses aren't the only thing you think about.

The story I like about this was some HOF baseball player (whom I remember as Mays) tried to become a hitting coach, but had little success. When his charges asked for advice, he suggested "just watch the seams as the pitcher releases the ball; if the seam is here, it's a curveball, if it's there, it's a fastball". Some people have trouble reading the seams in the blink of an eye on a baseball from 60 feet as released at 90 MPH, even your average MLB cleanup hitter. It wasn't a coachable skill, so his advice was useless.

I suppose we could inject a drug to show the four sigma Lisp programmer what those damn things look like to your one sigma script monkey. Ethanol might work. You should be able to erase three sigmas with one bottle of Jack. When the Lisp person returns to sobriety, the response will most likely be "How can you live!" not "Humanity is unfit for S-expressions!" Intelligence is a weird thing, you get to a certain point, you become so smart you're stupid.

You think I'm exaggerating?

From Lisping at JPL

At one point the software integration engineer was giving his presentation and listing all of the things that were going wrong. Someone (I don't know who) interrupted him and asked if he could change only one thing to make things better what would it be. His answer was: get rid of Lisp.

The integration manager is clearly in a world of hurt, and somehow the golden child was at the nexus of pain. I perked up waiting for this brilliant JPL Lisp programmer to dig into how this could be. But no. Integration manager is daemon spawn, and we return to the original blind devotion. Yet again, I wander deep into the campfire of the illuminated, and come back having learned nothing. In the Lisp world, ripe for a teaching moment equates to "you don't get it already, clearly you're not one of us".

For the record, J makes my eyes bleed, but if I put in the work, I'm sure I would learn something. I think what Lisp has to teach me is that fundamentally syntax is a liability and not an asset. Except when it isn't. I got that long ago. When Kurzweil unveils Vitamin Booster Dust, this amazing nugget of truth will suddenly become useful to me.

You think I'm joking?

[With Javascript] given the difficulty in changing simple things like making 010 parse as 10 and not 8 indicates that at some point it will stagnate.

That's a neat compensation. Since we can already guess at the wise things we'll all say after Vitamin Booster Dust hits the store shelves near you, just start saying them already. Or, for bonus points, solve two equations of compensation simultaneously: if we're suddenly that smart, our big mess will be refactored faultlessly in no time, so why are we wasting our time projecting a future that will take care of itself?

He cites the Javascript with statement for special scorn. Check out the guy with 185 up-votes demonstrating an interesting use case.

Google has released a research paper (PDF) that suggests C++ is the best-performing language on the market.

No, they didn't. They compared four languages (C++, Go, Java and Scala) using a single algorithm, and two implementations (initial and improved) per language. Out of those, the optimized C++ turned out to be the fastest and the least memory hungry, whereas the improved Scala version used the least source code, and the improved Go version compiled the fastest.

None of this allows generalization to "best-performing programming language on the market".

It's not for everyone, though. They write, '...it also required the most extensive tuning efforts, many of which were done at a level of sophistication that would not be available to the average programmer.'

This is a very important point. If you are Google, you probably have developers who can do this kind of tuning, and you will probably benefit from it (the developer effort is expensive, but inefficient software may well be more expensive at Google's scale).

In general, though, what you want to consider is not only the best performance that has been produced by the world on a single problem, but also the performance on different problems, the variation in performance between implementations, the average performance, and the development time.

In 2000, Erann Gatt (now Ron Garret) published a paper (PDF) that showed the results of comparing 16 implementations written by 14 programmers, in C or C++ (lumped together), Java, and Common Lisp or Scheme (lumped together). These results show that the fastest programs were written in C or C++, Lisp produced the fastest programs on average, and offered the least variation in performance. Lisp also offered the shortest development time on average.

Of course, this is old data. If anyone has performed a similar study more recently, or including different problems to be solved rather than a single one, I would be very interested.

Meanwhile, the Computer Language Benchmarks Game compares many language implementations across several different tasks, with multiple programs for each task, and shows that the results differ depending on exactly how you measure.

Apparently, if you want the fastest programs, you should go with C, C++, Ada, ATS (Fortran, Common Lisp, and Python also produced fast programs, but weren't as good on average). If you want short programs (which may be expected to correlate with short development time), you might want to go with Ruby, Python, Perl, Lua, or JavaScript. If you want short development time, but also reasonable performance, then Go, Scala, or Haskell may be good choices (or you could go the time-tested route of writing what you can in rapid development languages, and the parts that need to be fast in high-performance languages).

...automatically updating any program while its running without any interruption (which would be quite a feat if accomplished...

Depends on the program I suppose, but there would be nothing remarkable about accomplishing such feats in running Lisp programs. There's an amusing example of what is possible in this general area here:

http://www.flownet.com/gat/jpl-lisp.html

``You're assuming that it really will be faster to do a project in $newLanguage.''

I am assuming that the development time isn't equal for all languages. I find the contrary assumption (there is no difference in development time among all languages) absurd.

``I have never in my life seen a problem made simpler by changing languages rather than downloading a library.''

That may be so, but this requires that said library exist. That won't always be the case. And what if you actually wanted to write such a library?

``If you want to dispure my point you need to prove the assertion that it isn't so, not just throw some pseudomath in a post.''

I agree that pseudomath doesn't prove anything. On the other hand, the burden of proof isn't on me; you were the one making the original assertion, so the burden of proof is on you. Having said that, there are studies that compare development time across programming languages. One example is "Lisp as an Alternative to Java" (PDF), which finds that development time differs among Lisp, Java, and C++.

TFA refers to the Zeno effect, which I hadn't heard of before. This turns out to be an effect whereby the decay of a particle can be suppressed by continuous observation of the particle.

The thrust of the argument is that dark energy could spontaneously decay, resulting in a new big bang. The probability of decay decreases with time, and by observing dark energy the decay probability is reset back to its value at time zero due to the Zeno effect.

Being a very very amateur reader of quantum mechanics, all I can say to this is, OK if they say so. One thing I did run across is that wikipedia's entry for the Zeno effect claims it only applies to microscopic particles, not macro systems.

My question would be, wouldn't dark energy as a whole be considered a macro system? Surely an individual quantum of dark energy is not what humans observed. I would have no idea to whom I should address that question.

Relatedly, I find this paper to be very helpful.

A little rebellion now is a good thing.
        -- President Thomas Jefferson. 1743-1826

He who has lost freedom has nothing left to lose.
        -- Unknown.

From: http://www.flownet.com/gat/freedom.html

In support of your point, I want to share the followind PDF: Lisp as an Alternative to Java. The study compares programs written in Java, C/C++ (they lump these togeter), and Common Lisp / Scheme (again, lumped together). The findings are basically:

1. The fastest programs are written in C/C++
2. On average, Lisp/Scheme programs are fasted, followed by C/C++ programs, and Java programs are way behind.
3. Development time is shortest for Lisp/Scheme, with Java and C++ being more or less equal.
4. C/C++ programs used the least memory, with Lisp/Scheme and Java being about equal.
5. There was very little variation in the run time and development time of Lisp/Scheme programs, and a lot of variation everywhere else.

The PDF contains some nice graphs illustrating all this.

The author was indeed responsible for this comparison between Lisp and Java which will be in line with your "real academic/Lisp-lover" crack.

Please note that he was also responsible for this paper describing a Lisp-based system that successfully flew a NASA spacecraft. He knows exactly how difficult it is to make things work from an engineering standpoint.

In terms of writing software that deals with real-world problems, Ron Garret is a lot closer to the Paul Graham end of the spectrum than he is to the pointy-headed academic end.

The author was indeed responsible for this comparison between Lisp and Java which will be in line with your "real academic/Lisp-lover" crack.

Please note that he was also responsible for this paper describing a Lisp-based system that successfully flew a NASA spacecraft. He knows exactly how difficult it is to make things work from an engineering standpoint.

In terms of writing software that deals with real-world problems, Ron Garret is a lot closer to the Paul Graham end of the spectrum than he is to the pointy-headed academic end.

"Ron" is Ron Garrett, nee Erann Gat. He used to work at JPL, where he created an autonomous spacecraft control system which was named NASA Software of the Year. His homepage has a list of his publications, and you can find his Usenet postings with Google Groups, if you like (he used to post quite frequently in comp.lang.lisp).

His Blogger profile even links to his homepage. Xooglers is not some anonymous blog; it's written by people using their real names and at least one of them has a decent track record as a software developer. I haven't even seen any particularly negative remarks in Xooglers posts, except for self-deprecating remarks by the authors! Why don't you actually try reading TFB instead of spewing bile?

"Ron" is Ron Garrett, nee Erann Gat. He used to work at JPL, where he created an autonomous spacecraft control system which was named NASA Software of the Year. His homepage has a list of his publications, and you can find his Usenet postings with Google Groups, if you like (he used to post quite frequently in comp.lang.lisp).

His Blogger profile even links to his homepage. Xooglers is not some anonymous blog; it's written by people using their real names and at least one of them has a decent track record as a software developer. I haven't even seen any particularly negative remarks in Xooglers posts, except for self-deprecating remarks by the authors! Why don't you actually try reading TFB instead of spewing bile?

Here's a paper that explains why FTL communications with entangled photons is not possible:

http://www.flownet.com/ron/QM.pdf

It has some hairy-looking math in it, but the mathematical details don't really matter to the explanation.

LOL. Yes. Lisp. How about APL? or some other equally retarded language only mathematicians, washed-up AI people & other various people who never got past just being a programmer (vs designer vs software engineer) could love...

I love people who don't know what on earth they're talking about. Lisp has little to do with AI except as an accident of history. Today people use Lisp to write 3D games for the Playstation, complex business applcations, robot controllers for NASA and just about anything in between.

Because LISP scales *so* well.

Well spotted - it does. Steel Bank Common Lisp on my AMD64 compiles to wickedly fast native x86_64 code - actually faster than gcc in some cases.

And has all kinds of useful features like ... eval!!!!

From http://www.flownet.com/gat/jpl-lisp.html:

(Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem. The story of the Remote Agent bug is an interesting one in and of itself.)

Yes! the way of the future! RPN & expressing yourself in syntax trees!

Yeah Lisp is the way of the future actually - heh. All other actively-developed languages have only recently added things that have been in Lisp for decades: closures, GC, macros et al. Lisp isn't RPN by the way which shows me how much you really know about Lisp. And you don't typcially write code in syntax trees - you write a domain-specific language in Lisp and then write your problem in that. Reply as yourself if you feel the need - I'd like a good laugh at your previous cluelessness.

Lisp is "elegant"? It has all the elegence of porridge with toenail clippings.

Just because you're not productive in another language isn't out fault. And I've yet to see anyone provide an objective comparison of productivity in LISP vs. other languages.

But it's really "the eternal dynamic/productive/high-level/faster (LISP) vs static/unproductive/low-level/slower (Java) debacle."

References: Lisp as an Alternative to Java[HTML] or Lisp as an Alternative to Java[PDF]

Perhaps not surprisingly for anyone who has heard about the management at NASA, C++ was selected for the successors to the Remote Agent on the grounds that it is supposed to be more reliable (this despite the fact that the Remote Agent was originally to be developed in C++, an effort that was abandoned after a year of failure). This caused more than a few people to be upset (including a very personal account by one of the aforementioned designers). Clearly the debugging facilities of Common Lisp are far superior to static systems like C++, something which is very useful in diagnosing unexpected error conditions in spacecraft software (read the first question on p. 3 of the interview to see what pains the JPL staff went through to adapt similar, ad-hoc methods to VxWorks). It's also clear from this interview (question: "How is application programming done for a spacecraft?" Answer:"Much the same as for anything elsesoftware requirements are written, with specifications and test plans, then the software is written and tested, problems are fixed, and eventually its sent off to do its job.") that NASA has in no way tried to adapt formal verification methods for it's software, prefering instead to rely on the "tried and true" (at failing, maybe) poke-and-test development "methods."

Clearly, formal verification methods to eliminate bugs before critical software is deployed, and deployment in a system with advanced debugging facilities is a clear win for spacecraft software, and should be adapted as the standard model of development. Unfortunately, like in many other software development enterprises, inertia keeps outdated, inadequate systems going despite a strong failure correlation rate.

It's because of the mean skill of Java programmers. "Lisp as an Alternative to Java"

Bringing objects to the masses, Java is the COBOL of object orientation. Java may be practical, but it's un-hip & un-fun.

Another interesting thing about the RA experiment is the way the error was found and fixed. Because the RA was written in Lisp, it had interactive debugging and loading features, and the race condition was diagnosed without having to stop the experiment, and patched without having to reload the whole system. The same project team member (Erann Gat) said it "proved invaluable in finding and fixing the problem."

There was an interesting study done comparing the performance and productivity of C++ vs Lisp vs Java programmers. Results are here.

One very interesting thing they found was that while the best C++ programs were faster, the average Lisp program was faster. Programmer experience could not account for this, since the C++ programmers were much more experienced than the Lisp ones.

In retrospect, its easy to see why. When you write clean, straight-forward code like you would in a production environment, its much easier for the compiler to optimize high-level code than low-level code. Compilers for languages like Lisp/Scheme/Haskell/etc do all sorts of optimizations that existing C/C++/Java compilers either don't do (forgotten technology) or can't do (pointers cause lots of problems).

My point is that programming at a higher level, in general, allows the compiler to do more optimization than programming at a lower level. Given infinite time, an asm programmer will always be able to crank out faster code than a C++ programmer, who will always be able to crank out faster code than a Lisp programmer. However, in the real world, it may very well be the case that giving the optimizer more meat to work on will result in a program that is ultimately faster over all.

There was an interesting study done comparing the performance and productivity of C++ vs Lisp vs Java programmers. Results are here.

One very interesting thing they found was that while the best C++ programs were faster, the average Lisp program was faster*. Programmer experience could not account for this.

In retrospect, its easy to see why. When you write clean, straight-forward code like you would in a production environment, its much easier for the compiler to optimize high-level code than low-level code. Compilers for languages like Lisp/Scheme/Haskell/etc do all sorts of optimizations that existing C/C++/Java compilers either don't do (forgotten technology) or can't do (pointers cause lots of problems).

My point is that programming at a higher level, in general, allows the compiler to do more optimization than programming at a lower level. Given infinite time, an asm programmer will always be able to crank out faster code than a C++ programmer, who will always be able to crank out faster code than a Lisp programmer. However, in the real world, it may very well be the case that giving the optimizer more meat to work on will result in a program that is ultimately faster over all.

I and others disagree. Here's two:

Consider Paul Graham: Beating the Averages. Considering that he's the kind of guy that gets invited to MIT as a language wizard (along with Guy Steele, David Detlefs, Martin Rinard, Jonathan Rees, and David Moon), and considering that he has a net worth in the (hundreds of) millions, I'll go with his choice: abstraction rules.

Consider Erann Gat from JPL (the guys who get to send robots to Mars and build autonomously controlled space probes) disagrees and empirically proves it.

Diamond Walker emphatically endorses LISP - his story is very compelling.

The list goes on and on: Dan Friedman, Mitchell Wand, Shriram Krishnamurthi, Christian Quiennec ...

But, to paraphrase Graham, if you don't know these people I guess I don't have to worry about you.

Here's a rant by a JPL guy about appropriate technologies for software on deep space probes. He recounts one story of a failed probe "100 million dollars, and 100 million miles away".

They fixed it. The fact there was a lisp REPL running on the spacecraft helped.

That's cool:

(unwind-protect
(progn (do-science)(talk-to-earth))
(wait-in-repl-for-earth))

I'm not talking about Python. Python is positioned as a scripting language, and hence doesn't have a powerful compilation infrastructure. Although, Pysco does some very cool dynamic optimizations for Python.

In contrast, there are many high-level languages like Common Lisp, Dylan, Scheme, ML, Ocaml, etc, that have very powerful native compilers. They do optimizations that C/C++ compilers simply cannot do, because of the low-level C memory model. Literally decades of research has gone into making these compilers, and they have optimizations that (while not quite magical) are very impressive.

Variously:

- There are type-inference optimizations that eliminate the overhead of dynamic dispatch.
- There are heap-analysis optimizations that stack-allocate objects whenever possible, to avoid heap allocation.
- There are analysis that avoid heap-allocating closures.
- There are analysis that eliminate type checking and array bounds checking.
- There are analysis that perform large-scale optimization of class heirarchies, to eliminate the over head of OOP.
- There are memory allocation analysis that reduce the overhead of garbage collection (region inference).
- They do method specialization, allowing the C++ template advantage of generic functions optimized for a given type, without actually having to deal with explicit type parameters.

Some useful pointers:

Apple Dylan Wiki
Lisp vs Java vs C/C++ performane
Bigloo Scheme Compiler
Gwydion Dylan compiler
CMU Common Lisp Compiler
UW Vortex Compiler
MLKit ML Compiler
Ocaml Compiler

Yes, it was written in Common Lisp and ran on a special verson of Xanalys LispWorks runtime with realtime garbage collector. The experiment intended to demonstrate the approach on test set of problems; however, the Remote Agent software found and helped to fix one very real unanticipated bug on the spacecraft.

Nowdays, the project is under rewrite to C++ for political reasons. You can read the story from one of the RAX developers here.

Here. Previously mentioned on Slashdot here.

The memo may or may not be a fake, but many of the peformance issues mentioned in it are real.