Re: When functional languages can be accepted by industry?

From: John Max Skaller (skaller@maxtal.com.au)
Date: Fri Apr 07 2000 - 17:44:49 MET DST

  • Next message: Pierre Weis: "Re: cyclic value construction ("let rec")"

    "Dennis (Gang) Chen" wrote:

    > Functional languages have not been very successful in industry. Why?
    >
    > When writing database applications, we use Access, Oracle and languages
    > which support interfeaces to these database systems.
    >
    > When writing an application which needs user friendly interface, one can use Delphi,
    > or Java, Visual Basic, Visual C++, C++ Builder etc.
    >
    > When writing text manipulation programs, perl is a good choice.
    >
    > For internet application, one use Java, perl, Deplhi, Visual C++ etc.
    >
    > When higher order functions are required, we can use any OO language, because
    > an object with one method can be viewed as a function, so if a function can accept
    > objects as inputs and output an object, then this function is a higher order function.

            This is not really the case, in my opinion.
    We can do polymorphism with higher order functions in C. By following
    a protocol. But it is truly laborious. :-)
     
    > To write polymorphic functions, one can use templates in C++.

            C++ templates provides superior performance, but less
    functionality. More precisely, they don't scale well.
     
    > For data structures which require dynamic memory allocation, one can consider
    > Standard Template Library (STL) in C++. From STL, you can choose list, set,
    > map, tree templates, which are sufficient for most purposes.
    >
    > The templates in STL are more efficient than list in functinal languages.

            No. For list operations -- as understood in functional languages,
    functional lists are MUCH faster than C++ STL. In particular,
    'applicative'
    data structures such as lists provides superb performance in functional
    languages. The problem comes when one wants mutable structures: then
    STL provides superb performance.

    >For example,
    > if you use list to implement set, then a deletion of an element from a set will require
    > reconstruction of a part of the list, which has significant memory cost. In STL
    > templates, this is a simple pointer operation.

            Of course, and the same is true if you are silly enough to use
    an STL vector to implement a set. Have a look at ocaml's Set module:
    it provides efficient applicative sets. Hashtables provide reasonable
    mutable sets.

    > To write a parser, I prefer to use ocaml as I'm aware of its adavantage
    > in this aspect. But I've learnt that there are other compiler tools available.
    >
    > Functional languages in ML family are equiped with a much better type system
    > than C++, this reduce errors in programs, but industry has its own procedure to
    > ensure the reliability of program. So the weakness in C++ does not bother too
    > much.

            The weaknesses in C++ worry the smart people in
    industry I know a lot. My current job is to design a language which
    allows safer, more convenient writing of a certain class of programs
    which requires ultra lightweight threading. I would not have been
    asked to do this in a C++ shop if C++ were thought to be adequate
    (at least, the hand coding of it).

    > Module in ocaml is an attractive feature. Large applications are built in a refinement
    > way,
    > and different implementations for a given interface will be experimented. Module
    > should be good for this, and it is not available in C++.

            As usual in C++, one can obtain just about any effect you want,
    with the right combination of tools. The problem, as I see it, is that

            1) you must design some kind of architecture supported by a
    certain protocol of usage (not enforced by the type system)

            2) You must write code accoring to this protocol (which is difficult
    without tools to check protocol adherence).

            For example, an ordinary module is easily emulated by a C++
    namespace -- but while with care you can define 'modules' this way,
    you cannot force clients to use them correctly.
     
            This is like memory management in C++: it is possible to design
    protocols (and supporting tools) which if used correctly assure correct
    memory management -- but not so easy to enforce correct usage.
    [This is easy in ocaml .. just don't use Obj or any C, and GC will do
    the
    job automatically]

    > Are there other features of functional language which will attract industry?

            In many cases, it is NOT the language itself which is the obstacle.
    It is often 'meta-lingual' problems: compilation model, performance,
    ability to interface to other systems, library, etc.

            Ocaml scores fairly well on these counts, but despite the
    nasty problems with the C++ compilation model, ocaml's is still more
    limited.

            Note that ocaml ISN'T a functional language, but an 'simula like'
    language just like C++ is: a mix of functional, procedural, and object
    oriented features.

    ---------------------------------------------------------------------------

            I'll be generating C++ using a tool written in ocaml.
    This has some advantages -- many of the advantages of C++ are retained,
    whereas one of the applications that ocaml shines at: developing
    language translators -- will be put to good use.

            I have no interested in 'promoting' functional languages
    as a better alternative than, say, C++: rather of finding ways to
    use tools together, to be able to build better software.

    -- 
    John (Max) Skaller, mailto:skaller@maxtal.com.au
    10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
    checkout Vyper http://Vyper.sourceforge.net
    download Interscript http://Interscript.sourceforge.net
    



    This archive was generated by hypermail 2b29 : Mon Apr 10 2000 - 01:43:32 MET DST