Re: When functional languages can be accepted by industry?

From: jean-marc alliot (alliot@recherche.enac.fr)
Date: Mon Apr 17 2000 - 14:51:31 MET DST

  • Next message: Markus Mottl: "Re: When functional languages can be accepted by industry?"

    John Max Skaller wrote:

    >
    > > > 1. Current functional languages do not have enough library support:
    > >
    > > Please. ocaml has the most wonderful standard library that any other
    > > language has ever had. Have a look in the reference manual before
    > > stating such non-sense.
    >
    > 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++

    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.

    >

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

    CAML becomes slow when you use some of the nice functional features of the
    language. But if you write CAML as you write C code you won't lose much
    speed. Over the years, students and development programmers have developped
    thousand of lines of code in many different languages in my team and
    writing or rewriting in CAML had a limited impact on the speed of the
    program.

    Again, I don't like religious opinions, but I am anyway going to explain a
    few things. I am sorry to use personal examples, but I know them very well
    -:)

    I understand that for highly time critical fragment of codes that are
    extremely closed to machine architecture, C is a reasonable choice. I am an
    old game programmer, and once had a program (otage) based on pattern
    recognition, who had its 15 minutes of glory on the Internet Othelo Server
    and entered the top 5 list. It is written in C and assembly language, it is
    using each and every bit of every byte of memory; it is fast indeed, and C
    is efficient.
    But I stopped maintaining it, because it has become a real pain. Even when
    the code is documented, the program is extremely complex, and when I stop
    working on it for a few months, it is almost impossible to re-enter the
    code. I am too old and too busy now to work on it anymore. And I don't like
    programs core dumping anymore either.
    C should be only used by experienced programmers, who are extremely careful
    of everything they write, with unitary tests for each and every function,
    and only for time critical functions.
    On the opposite, I wrote a chinese checkers program in CAML this year in a
    few days (it was a challenge with some friends). It is in no way
    ridiculous, and is extremely easy to maintain.

    I understand also people using ADA for programs that need to be highly
    portable, easy to maintain and whose life span will be long. The ADA code I
    wrote with ALSYS and VERDIX compiler for my PhD thesis 15 years ago (an
    extension of PROLOG to modal logic) is still compiling without any
    modification on the gnat compiler today. ADA includes representation clause
    that makes it almost independant to anything including machine
    architecture.
    ADA is not as fast as C or as easy to use as CAML, but it is definitely a
    decent compromise for many industrial applications. It suffered from a very
    bad integration with UNIX (always worked well with VMS) at the beginning,
    especially when I/O and multi-tasking were both involved. This is quite
    solved now (thanks to clone()...)

    I am extremely sorry to say that I don't understand people using C++when
    they have a choice.
    This language is, according to me, a collection of every little thing that
    should never be done. Templates are, from a theoritical point of view, a
    matter of laugh, and generally not compatible between different compilers
    (I have examples every year with students coming back from training periods
    with programs written in C++, and who speend hours to make them compile
    with the University compilers and machines). For people knowing object
    theory and its EIFFEL implementation, the C++ object system looks at least
    shaky. Operators overloading has been pushed to its ugliest limit (it does
    exist in ADA, but WITH and USE clauses give at least meaningfull
    informations) : I saw once an experienced programmer who was using a
    library developped by someone who had left the development team spending
    two days to find a "core dumping" bug in the C++ library left by this
    former developper. The fragment of code looked like this:
    void f(foobar *ival)
    {
    foobar *l;
    for (l=ival; l<>NULL;l++) {...}
    }
    Unfortunately, the ++ operator had been overloaded for type foobar
    somewhere else and was no more a pointer incrementation, but was in fact:

    l = l->next
    where next was a field of the foobar structure : the problem was an
    incorrectly initialized field and not an "incorrectly" terminated pointer
    array.
    I could write endlessly about C++ problems ; I had to use it for a few
    years for development purpose, and, if I first began to like it, I soon
    learned to hate it.
    JAVA has corrected many problems, such as memory allocation or the infamous
    core dumping behaviour. But it is not that fast...

    I love programming. I began when i was 15 (almost 25 years ago) on small
    machines, I learned assembly language, BASIC, FORTRAN and C before learning
    anything about computer science theory. To summarize, I did mathematics at
    the University and hacking at home ; I went back to University to learn
    computer science when I was 26, and I had then lot of bad programming
    habits.
    It took me a long time to understand that there were more proper ways to
    write programs.
    I also had to realize that speed is far from being the only concern, and
    that fast but buggy/unmaintanaible programs are useless in team
    development. Functional programming is painful to learn (and it was painful
    for me) when you are used to imperative programming. You have to learn to
    think differently before you can really master the language. But it is
    worth the effort.

    JMA



    This archive was generated by hypermail 2b29 : Mon Apr 17 2000 - 21:04:51 MET DST