"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