Re: RAD vs. performance

On Mon, Jun 19, 2006 at 11:59:13AM +0100, Jon Harrop wrote:
Robbert Haarman wrote:
Of course, there are counterarguments as well: static typing as a
measure of correctness is both an overapproximation and an
underapproximation. Just because the type checker accepts a program
doesn't mean it's correct,

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. There's no
substitute for actual testing.

and type checkers will also make it
impossible to write programs that would have worked flawlessly in the
absence of static typing (of course, these programs aren't _correct_,
because they violate the typing rules).

Your statement is a little vague. You can write any program in a statically
typed language, but not necessarily in the same way that you could in a
dynamically typed language. Polymorphic recursion is the obvious example.
However, these situations are rare in practice.

There's an example that's supposed to clarify my statement:

(* Suppose that foo and bar are instances of two different classes,
but both support the print method. *)
let rec print_all xs = match xs with
[] -> ()
| x::xs -> x#print; print_newline (); print_all xs
in
print_all [foo; bar];;

Most type checkers will reject this program, because they won't allow
you to put objects of different types in a single list. However, under
dynamic typing, this program would have worked fine.

The print_all function already works in OCaml:

Ok. I knew Haskell handled this, but I didn't know that Ocaml did as
well.

Yet CLs performance is far worse than that of most modern,
statically-typed languages (e.g. MLs). Putting more effort into
optimisation is no substitute for designing a language that will run
fast.

What is "far worse"? According to the Shootout, the difference in speed
between the fastest open source Common Lisp implementation and the
fastest C compiler is about a factor 2 (or so it was last I checked). Is
that a lot? Java is statically typed, but most Java implementations
score a lot worse. On the other hand, a lot of effort and money has been
put into optimizing the C compilers and Java implementations at the top
of the ranking. Maybe optimization matters more than you think. Of
course, the Shootout allows everyone to see what they want to see.

Then don't use the shootout.

Every time someone says that, I have to ask them: do you have anything
better? 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.

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). Or perhaps there _is_ something
fundamental about Lisp that makes it slow. I just don't know what it
would be. I also don't really care - it's fast enough for me.

Regards,

Bob

---
"Common sense is not so common."

Attachment: pgp8ViD3gBRQg.pgp
Description: PGP signature

Relevant Pages

  • Re: RAD vs. performance
    ... code and, as soon as it passes the type checker, have it work properly ... implementations of various programming languages on various benchmarks, ... discussing whether or not the Shootout is good as it is to be put into ... and Lisp implementers don't spend their efforts optimizing ...
    (comp.lang.misc)
  • Re: RAD vs. performance
    ... Pretending that if a program gets through the type checker, ... SBCL-compiled Lisp is severely ... Provided it is a popular enough language that there's a Debian package ... there is no substitute for careful design. ...
    (comp.lang.misc)
  • Re: Python from Wise Guys Viewpoint
    ... >> typed language that can still be statically checked if one wants to do ... * an increase in expressive power is related to a decrease of the set of ... The invariants that you write, or that are inferred by the type checker, ... here is where Lisp comes into the game: ...
    (comp.lang.python)
  • Re: Python from Wise Guys Viewpoint
    ... >> typed language that can still be statically checked if one wants to do ... * an increase in expressive power is related to a decrease of the set of ... The invariants that you write, or that are inferred by the type checker, ... here is where Lisp comes into the game: ...
    (comp.lang.lisp)
  • Re: Python from Wise Guys Viewpoint
    ... In a language such as Haskell, there are no constructs that 'would run ... In Lisp too, there are no programs that 'would run correctly' after ... failing type-checking, because a type checker for Lisp would have to ...
    (comp.lang.lisp)