Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
When functional languages can be accepted by industry?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Dennis (Gang) Chen <Dennis.G.Chen@m...>
Subject: Re: When functional languages can be accepted by industry?
> Don't forget that there is (almost) no restriction on side-effects in
> Caml: if this is crucial for your program, you can implement lists as
> an imperative data type of your own, and then use destructive update
> to perform the deletion operation in the required complexity. Just be
> aware that list sharing will be difficult as for any other imperative
> implementation of lists.

This is true. But such an approach does not make ocaml

more attractive than C++. In ocaml, there are arrays, structures

and objects etc, but no such things like pointers in C.

For a company or an ordinary programmer,

a simple and safe solution could be just

to pick up the set template from C++ STL.

The purpose of my original message:

"When functional languages can be accepted by industry?"

is not to ignore the advantages of functional languages. I only

want to point out the current challenges to FL. These challenges

can be classified in three groups:

1. Current functional languages do not have enough library support:

so it is not convenient to use FL for database management, programming

friendly user interface etc. Without industry support, these libraries

 would take a long time to implement

2. Functional languages do not well support the use of dynamic

data structures which requires mutable operations for achieving the


3. Morden imperative languages are equiped with certain functional

features, e.g. higher order functions can be simulated by objects,

a certain level of polymorphism can be achieved by using templates,

common dynamic data structures have been built in STL etc.

What are the implications of these challenges?

Neither functional languages nor imperative languages are perfect.

A language designer can choose to add imperative features into a functional

language, and to develop smart algorithms to improve the efficiency;

Alternatively, he can choose to add functional features into an imperative

language, and to develop a better type checker for all or a subset of

of the imperative language, or he can, as described by John Max,  put a functional

language on top of, say C++, and permitting the user to use C++

when necessary.

It is no doubt that functional languages will continue to succeed in

eduacation, research, high level specification, formal program verification,

fast prototyping, etc. But, it appears to me that, in industry, the second approach might

succeed in most cases.

Best regards.

Dennis Gang CHEN    Senior Software Engineer
Motorola Australia Software Centre, Electronic Design Automation
2 Second Avenue, Mawson Lakes, SA 5095, Australia
phone: +61 8 8203 3560,  mailto: