Re: When functional languages can be accepted by industry?

From: William Chesters (williamc@paneris.org)
Date: Sun Apr 16 2000 - 00:29:27 MET DST

  • Next message: Ohad Rodeh: "Calling C++ from Caml"

    John Max Skaller writes:
    > > Wrong. You have references, which are quite better than pointers
    > > (they are typed, and necessarily initialized)
    >
    > .. which is a serious problem.

       We've talked about this before ... Yes, initialising a value
    sometimes means a certain number of clock cycles "wasted", but it
    seems to me that any program in which those cycles are non-negligible
    compared with the cycles you are going to spend on actually using the
    value in question is probably a poorly written program. It's only if
    you construct a huge array of zeroes and then discard it that
    initialisation can have a serious impact (?).

    > Oh come on. Have a look at a real library before making
    > such non-sense claims. Considerable functionality is missing,
    > the library is inconsistent, the documentation is incomplete,
    > and it is less generic than C++ STL, which is also probably
    > more efficient on almost every operation.

       STL-completeness is not the touchstone of a library's value. I
    think most people who used Java for real work found that we hardly
    ever missed it (pre-1.2, Java's libraries were very unpretentious),
    and enjoyed not having to spend time explaining it to co-workers ...
    The STL is yet another manifestation of the terribly 80s
    more-is-better (and cleverer-is-better) philosophy which permeates the
    world of C++.

       To put it succinctly: have a look at what is really used (and
    useful) before making such claims. Having said that I agree the
    ocaml library could usefully be grown a bit.

    > Show me a functional programming language that is as fast
    > as C++ and I will give up C++. :-)

       It's perfectly true that C++ is the only language in which there is
    often a way to code your solution in such a way that (a) the source is
    written in concise high-level terms, and (b) the object code is as
    fast as it can possibly be. Leaving aside the fact that there are
    also dozens of much slower ways to code your solution---onto which all
    but the most expert C++ programmers are bound by Sod's law to
    light---that's wonderful and impressive. I agree, sometimes C++ is
    the only way. But how much of the code that gets written fails to
    meet the following conditions:

       -- it can run 50% (or 3 times, whatever) slower than C and it just
    doesn't matter (think Java, Perl, VB, ...); or

       -- it can be written as easily, with less palaver, in plain old C; or

       -- if it's written in C++, it's done quickly and defensively, so
    there's little danger of it ending up unmaintainably clever or
    unstable, but also little danger of it running fast.

       I honestly don't think it's raw speed relative to C++ that's
    standing in the way of the acceptance of functional languages in
    industry. However, ...

    > One barrier to acceptance of ocaml in industry: lack of
    > programmers.

    ... is surely spot on.



    This archive was generated by hypermail 2b29 : Mon Apr 17 2000 - 20:52:22 MET DST