Re: When functional languages can be accepted by industry?

From: Markus Mottl (mottl@miss.wu-wien.ac.at)
Date: Thu Apr 20 2000 - 18:40:38 MET DST

  • Next message: Jean-Christophe Filliatre: "Re: When functional languages can be accepted by industry?"

    > In order to get an STL-like library in OCaml, I think we'd need some form
    > of overloading. This comes up on this list every now and again, and it is
    > clear that the Caml team is working on it, so we'll see. I particularly
    > liked the last discussion here on type classes where Pierre Weis mentioned
    > that he was interested in an overloading scheme which could unify the
    > notations for array and string access; I'd be overjoyed if he is
    > successful!

    Over the time I have adapted to the "lack" of overloading and do not find
    it so missing for arithmetic operations. However, there is one application
    domain where I really feel "bitten" by not being allowed to overload
    operators: monads.

    I would like to use them more often for structuring code and trying out
    some new styles of functional programming, but it's a pain using different
    kinds of monads at the same time: you'd always have to specify module names
    for "bind"-operators, which puts the otherwise very convenient infix
    operators quite out of the question. But I wonder whether this specific
    application justifies a complication of the type system...

    > I presume that a similar compiler for an ML variant could be written. Given
    > that the Caml team has limited resources, I'd rather they spend them
    > elsewhere, as I am satisfied with the performance of OCaml for the problems
    > I apply it to. I realize that others have different priorities.

    What concerns me, I also consider the performance of OCaml programs fair
    enough for nearly all purposes. Since interfacing to C-code is so easy, one
    can always eliminate bottlenecks on a lower level.

    > There are probably other places in the implementation where choosing a
    > different strategy could close the gap with C++ in speed, at the cost of
    > code bloat.

    I do not think that C++ is competing with OCaml in the same niche so there
    is probably no point in addressing differences here. In fact, although it
    was surely not designed for this purpose, I believe that OCaml could be a
    serious threat to some scripting languages: partly due to its high
    performance, partly, because it is much saner = easier to maintain, and
    highly portable! The Unix-library is very complete and would also play an
    important role here.

    > Also, the claim is made that C++ with templates generates code with run
    > time performance comparable to hand coded C. Several studies that I've
    > read call that into question; Richard O'Keefe's usenet comparison of a few
    > years ago, the book by Kernighan and Pike "The Practice of Programming" and
    > Anh Vo's papers on the Cdt library which compare it with the STL.

    Programs on modern architectures depend so heavily on cache behaviour that
    performance claims for code-bloating techniques seem to be rather
    suspicious. I'd also like to see substantial benchmarks that prove the
    merits...

    > > Sorry. You lose HEAPS. Even 10% is significant, CAML can
    > > be over a decimal order of magnitude slower. C++ generics are
    > > generally much faster (being automatically specialised -- which
    > > also causes code bloat :-(
    >
    > I don't think you see an order of magnitude for the most part though...

    Considering the improvements on the hardware side in terms of processor
    performance, 10% seems very insignificant to me (a few months of hardware
    development at most), especially if you take into account that for many
    non-numeric applications the limiting factor is most often I/O-bandwidth.
    Correctness, maintainability and portability are (well, should be) the
    primary concerns in a world that changes fast - not "fast" programs...

    If your employer says that you should switch to lower-level, unsafe
    programming languages to get 10% more performance, tell him that he
    should rather buy new hardware (if you dare to! ;-)
    If he doesn't want, present him an estimate of the costs of more errors...

    Best regards,
    Markus Mottl

    -- 
    Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
    



    This archive was generated by hypermail 2b29 : Fri Apr 21 2000 - 19:23:44 MET DST