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: jean-marc alliot <alliot@r...>
Subject: 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

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