Re: RAD vs. performance

Robbert Haarman wrote:
On Mon, Jun 19, 2006 at 11:59:13AM +0100, Jon Harrop wrote:
Very true. However, it is not uncommon to write thousands of lines of ML
code and, as soon as it passes the type checker, have it work properly
first time. No need to waste your time unit testing...

I don't know...I'd never interpret the fact that a program passes the
compile-time checker as a guarantee that it works correctly.

I agree.

There's no substitute for actual testing.

I disagree. Static checking is a substitute for some "actual" testing.

Then don't use the shootout.

Every time someone says that, I have to ask them: do you have anything
better?

Yes:

http://www.ffconsultancy.com/free/ray_tracer/languages.html

I know the Shootout is flawed all over, but it's the only source
of performance data that compares a lot of more or less recent
implementations of various programming languages on various benchmarks,
using various criteria. I'd love to see a lot of effort that goes in
discussing whether or not the Shootout is good as it is to be put into
actually improving it. I, at least, am convinced that it can be very
useful.

Many people, including myself, have already described in detail what is
wrong with the shootout, explained how to fix it, actually fixed it and
then been ignored. Indeed, my ray tracer benchmark was originally on the
shootout but they removed it. I submitted dozens of improved programs
before giving up.

For non-trivial examples, Lisp certainly seems to be a lot slower (e.g.
2x). I'm not sure why. Slow GC was one reason that came up.

Maybe it's just that you don't litter non-trivial examples with type
declarations, and Lisp implementers don't spend their efforts optimizing
every part of their implementation (Common Lisp is a lot of work to
_implement_, let alone optimize).

Lisp is slow because it was not designed with performance in mind.

Or perhaps there _is_ something
fundamental about Lisp that makes it slow. I just don't know what it
would be.

Dynamic typing for one thing.

I also don't really care - it's fast enough for me.

What if Lisp is also more verbose, error-prone and slower to develop in than
other languages? To be honest, I can't think of a single practical use for
Lisp.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
.

Relevant Pages

  • Re: RAD vs. performance
    ... Just because the type checker accepts a program ... dynamically typed language. ... Java is statically typed, but most Java implementations ... the Shootout allows everyone to see what they want to see. ...
    (comp.lang.misc)
  • Re: How to change peoples minds about LISP?
    ... >>within Lisp itself, or more precisely, the type of available ... > [implementations?] that so sabotages lisp? ... than compiled, statically typed languages. ... It's still much faster than CLISP, ...
    (comp.lang.lisp)
  • Re: Whats the best language to learn...
    ... consider the merits of the typical implementations. ... on processors designed to run Lisp and Lisp OSes. ... level programming language such as Lisp. ... lisp, java, ruby, etc. ...
    (comp.programming)
  • Re: constantp values always available at macro expansion time?
    ... or is the cross-compilation mostly geared toward the compilation ... I guess it depends on what you mean by "standard". ... language for expressing Common Lisp implementations is precisely ANSI ...
    (comp.lang.lisp)
  • Re: Modernizing Common Lisp
    ... The Lisp code I run on my Mac won't work on any Lisp ... Perhaps the GUI is the One Thing keeping you on MCL. ... Most of the "threading" implementations seem very similar to the CLIM model ... Does it affect casual porting of the code? ...
    (comp.lang.lisp)