Re: What do you LISPers think of Haskell?

On 14 Sep, 16:46, Tamas K Papp <tkp...@xxxxxxxxx> wrote:
For example, he quotes me as saying "Lisp is as fast as Fortran for
scientific computing", and the quotation marks imply that it is a
verbatim quote.  But I never said that, what I said is "the speed of
modern CL implementations is in the same league as C and Fortran".  
Distorting someone's statements and then arguing with them is not
something that should be taken seriously.

Anyhow, to clarify my statement: in the kind of scientific computing I
do, I write code to solve economic models numerically.  A lot of time is
spent developing and tweaking the code.  First, I usually solve a
simplified version of my model, then if the results are interesting, I
think of extensions, and solve them too.  If some result looks
interesting, I try to figure out where it is coming from.

My guess would be that for every hour spent running the code, I devote
5-20 hours to programming.  This is where Lisp has a spectacular
advantage to C or Fortran.  I can build up a quick and dirty version of
my algorithm, then modify it on the fly.  If a numerical solver does not
converge because the objective function is nasty (eg not smoothly
differentiable), I can step into a debugger and explore it.  I can even
automate this process with advanced condition handling of Lisp: for
example, if I find that Powell's minpack (which I packaged as cl-minpack,
fast but not too robust) does not converge, I signal a condition, and let
Nelder-Mead (more robust, slow, does not use derivatives) take over from
there.  I could cite countless other examples.

Numerical solutions are not crisp and clean, sometimes they get downright
messy.  The important thing is to organize computation well, and have
good debugging facilities if something goes wrong.  Lisp does a superb
job in both respects.

Now what about runtime speed?  Runtime speed is important, of course.  
What I find is that the big divide is between 'interpreted' and
'compiled' languages: the former are slow, the second are fast.  Of
course there are differences within groups, but they don't matter that
much.  Would it be nice if my programs ran, say, twice as fast?  Yes.  
Would I switch to Fortran or C for that?  Hell, no, I would spend ages
writing and debugging code, and I would hate it, because I know I would
be doing things manually that I could automate in Lisp.  I switched to CL
from R (which is a nice, friendly but interpreted language), mainly for
reasons of speed (I found out about macros and condition handling later).

I find that those who care about differences in speed that are below a
factor of 2 (or even 5) are missing the point.  If you want speed and
care about nothing else, you would code in assembly, that is the
"fastest" by definition.  For some projects, that is the way to go, but
not for most -- programmer time is far more valuable, and correctness of
results (which comes from debugging and testing) is invaluable.

Also, these days I find that I don't even optimize my Lisp code, if it is
fast enough.  And with SBCL, it is, so why would I care?

In other words, your work has not been performance intensive enough
for Lisp's performance to be an impediment and you believe that you
would hate Fortran. That's fine and, in fact, is the buy-in for using
Mathematica.

However, that is completely different from your claim that "the speed
of modern CL implementations is in the same league as C and Fortran".
In particular, you have apparently not even attempted to use Fortran,
let alone produced or even cited any verifiable benchmark results to
substantiate your claim.

Cheers,
Jon.
.

Relevant Pages

  • Re: What do you LISPers think of Haskell?
    ... "Lisp is as fast as Fortran for scientific computing" claims economics ... His published software includes a sparse matrix library written in Lisp ...
    (comp.lang.lisp)
  • Lisp as a tool for the mind
    ... "Lisp is as fast as Fortran for scientific computing" claims economics ... His published software includes a sparse matrix library written in Lisp ...
    (comp.lang.lisp)
  • Re: Optimizing for fast floating-point numerical code
    ... the closest analogs to Fortran 95's very fast vectorized operations. ... say, however, that in Lisp they don't compete well with looping? ... (defun example (y l) ... (declare (inline attach)) ...
    (comp.lang.lisp)
  • Re: Freepascal rocks!
    ... I've been experimenting with a few programming languages lately: Assembler, Lisp, Forth, Smalltalk. ... A language powerful enough to simply implement another language is damn powerful. ... The other day I joked to my colleagues that we should be writing more stuff in FORTRAN; my contention being that FORTRAN doesn't really do much, so you *have* to keep things simple. ... CurRow, CurCol: Integer; ...
    (comp.lang.pascal.misc)
  • Re: Optimizing for fast floating-point numerical code
    ... intrinsic function like `random' in a given Lisp implementation to be ... different from the one in your Fortran implementation. ... they're called pseudo-random for a ... statistical properties. ...
    (comp.lang.lisp)