Re: When functional languages can be accepted by industry?

From: Brian Rogoff (bpr@best.com)
Date: Tue Apr 18 2000 - 00:34:08 MET DST

  • Next message: Max Skaller: "Re: When functional languages can be accepted by industry?"

    On Tue, 18 Apr 2000, John Max Skaller wrote:
    > jean-marc alliot wrote:
    > > I don't think there are lot of things missing in the STANDARD library. I
    > > don't see why it is inconsistent. I don't see why documentation is
    > > incomplete. Things might be missing in the general library, yes.
    >
    > The order of arguments is perverse. Obvious functions are missing,
    > such as finding the number of elements in a map. The documentation
    > fails to tell how fast the functions are, and the specifications are
    > sometimes imprecise.

    The standard library is improving though, and additional libraries could
    certainly be written by users. My main concern here is that the best
    libraries make it into the standard distribution. In particular I prefer
    Pcre to the Str library, and would like to see it become the standard
    distribution. Note that I'm not using *distribution* and *library*
    interchangeably.

    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! Until some form of overloading is in OCaml though, I wouldn't
    look to the STL as a library to emulate, though I suppose its most
    important idea, the expression of algorithms in terms of iterators rather
    than specific data structures, doesn't depend on overloading.

    > > > Show me a functional programming language that is as fast
    > > > as C++ and I will give up C++. :-)
    > > >
    >
    > > CAML. Just try programming the fibonacci function in both languages... -:)
    >
    > :-)

    I believe that the Stalin compiler for Scheme, which is a whole program
    compiler (you give up separate compilation) has done better than C on some
    much more significant programs than fibonacci. I suspect that any compiler
    which abandons separate compilation and does aggressive whole program
    analysis may have problems with extremely large programs, but I don't have
    evidence to back this up.

    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.

    Another potential area for performance improvement would be the elimination
    of GC using the region system or something like it.

    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.

    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.

    > > CAML becomes slow when you use some of the nice functional features of the
    > > language.
    >
    > It's one heck of a lot slower using the imperative features,
    > and even slower using object oriented ones.

    Once again, if you're willing to subject your entire program to analysis
    then I bet the OO parts of OCaml could be made to run much
    faster. SmallEiffel seems to be running pretty fast these days.

    Don't get me wrong; I think separate compilation is important, and would
    prefer that the default compiler operate as it does now. I just think that
    some of the performance hits you see could be eliminated without changing
    the language but by changing the compiler.

    > > But if you write CAML as you write C code you won't lose much
    > > speed.

    Huh? What if you write crypto code, or a BDD library, or numerics, or
    a regex library, or ...

    > 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...

    > No dispute. [I'm an 'old' game programmer too]. I'd write
    > the main game play engine of a strategy game in ocaml in preference
    > to C/C++, but there's no doubt I do the graphics in C/C++.
    > There, every ounce of performance is absolutely critical.

    If every ounce of performance is truly "absolutely critical", then go to
    assembler. Even C won't compete :-)

    Also, for numerics, Fortran compilers are still probably better than C,
    though I don't know how much longer that will hold true.

    > >Templates are, from a theoritical point of view, a
    > > matter of laugh,
    >
    > No. They're not perfect. They generate very fast code.
    > On the contrary, it is the boxed values of functional languages
    > which are the laugh: they kill performance.

    See above on templates. I agree that boxed values suck for high
    performance code.

    > What object theory? There isn't one. Object orientation
    > is a mess. Eiffel is every bit as bad as C++ here: the fact is that
    > C++ trades off beauty and correctness for speed and compatibility.
    >
    > It is faster than C though, and much easier to use.

    Faster than C? I doubt that. Where is your evidence?

    > Remember -- I _like_ Ocaml. I do _not_ like C++.
    > I did my best to make it better, with little result.
    > But the fact remains, it is the language of choice for most applications
    > simply because it provides reasonable power, reasonable safety,
    > and there is an assurance that it can be as fast as you can bother
    > to take care to make it.

    I'd say simply because it is perceived as a better C, and C was already
    the language of choice for most applications.

    OCaml is not riding anyone's coattails, so it really has to be better at
    something, or, more likely, we have to create a niche in which OCaml is
    the best language (read "The 22 Immutable Laws of Marketing ;-). I think
    that writing compilers and associated tools is one such niche, since it
    plays off of MLs strengths.

    -- Brian



    This archive was generated by hypermail 2b29 : Wed Apr 19 2000 - 15:09:51 MET DST