Re: RAD vs. performance

On Mon, Jun 19, 2006 at 11:05:16PM +0100, Jon Harrop wrote:
There's no substitute for actual testing.

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

If you had said: formal verification, I would have agreed. But then,
only on the parts that are being formally verified. If that's only the
type-safety, I wouldn't see that as a substitute for functional testing.
Pretending that if a program gets through the type checker, it must be
correct is foolish; at least when the type checker doesn't verify
dependent types.

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

Very nice! I'll read it in more detail later. For now, I have a number
of questions. Which parts of a language does this actually benchmark?
What about memory consumption? How do I add my favorite language?

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.

That sounds like there is a problem with the maintainers of the
Shootout. Which always makes me wonder: why don't people fork it? Which
is what you've started on, apparently. Good job!

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

Lisp wasn't designed with classes and objects in mind, either, and yet
it supports them nowadays. Lisp got many things right by accident,
others by clever design, and yet others by fixing what was wrong
initially. In that light, the fact that it wasn't designed with
performance in mind doesn't seem a good reason for not having
performance. IMO, when it's about performance, it's always down to
features and implementation: if the features rule out certain
optimizations, performance is going to suffer. Likewise, if the
implementation is inefficient, performance is going to suffer. So, the
question is, is the poor performance of Common Lisp due to features or
implementation?

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 don't think so. If you write your program in such a way that types can
be determined statically, it's possible to elide all run-time type
checks and method dispatches, completely eliminating any overhead from
dynamic typing. If the compiler doesn't do that, it's an implementation
issue.

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.

That would be a lot more serious, seeing that Lisp's main claim to fame
is that it's supposed to be nice to developers. If it's verbose, error
prone, and slow to develop in, that claim obviously doesn't fly. It
could still be useful if it had lots of useful libraries, but I'm
doubtful that Lisp does better there than, say, Java or Perl; at least
in today's environment.

Regards,

Bob

---
That that is is that that is not not.

Attachment: pgp7lMERninsB.pgp
Description: PGP signature

Relevant Pages

  • Re: Building a framework in lisp for testing and feature documentation?
    ... > Having used lisp and java for a couple of years now, ... > dynamic and static elements of an application. ... > interactions of a set of features, with features being a set of ... only be able to get a few folks, probably some support folks who are ...
    (comp.lang.lisp)
  • Re: Paul Grahams teaching style is bad
    ... > remaining distinctive features of lisp are a good thing. ... > languages have been picking up from lisp for so long was the big deal, ... > and that macros are only marginally important by comparison, ...
    (comp.lang.lisp)
  • Re: Building a framework in lisp for testing and feature documentation?
    ... > place to map features to customers and tests to features. ... > Having used lisp and java for a couple of years now, ... > static elements of an application. ... necessarily different than the developer, ...
    (comp.lang.lisp)
  • Re: Comparison of merits between newLISP and Clojure?
    ... Lisp dialects few years, mostly because of few code=data related ... That may be because newLisp is interpreted and everything must be slow ... These features are not emphasized in the introductory materials, ...
    (comp.lang.lisp)
  • Re: C++ sucks for games
    ... The previous poster is talking about Lisp macros; C and C++ support ... distinguished by a startlingly large number of features, ...
    (comp.lang.cpp)