From: Gerd Stolpmann <Gerd.Stolpmann@darmstadt.netsurf.de>
To: STARYNKEVITCH Basile <Basile.Starynkevitch@cea.fr>, caml-list@inria.fr
Subject: Re: convincing management to switch to Ocaml
Date: Fri, 30 Jul 1999 20:49:00 +0200
Message-Id: <99073022222600.00491@schneemann>
On Wed, 28 Jul 1999, STARYNKEVITCH Basile wrote:
>Hello,
>
>Does any one have clues or positive experience about convincing
>management to switch to Ocaml?
>
> I'm working for an European Community ESPRIT project [TWO] for static
>code analysis -with testing in mind- using abstract interpretation
>techniques.
>
>But I failed to convince my management to switch to a good language
>such as Ocaml.
I'm still trying the same, but my (industrial) project has different
prerequisits. It is already a multi-language implementation, at least
Perl, C, C++, and Java code exists. Currently, only two relatively small
Ocaml programs exist, one is a semi-automatic structure mapper that
tries to track the users' structure changes, one a parser/generator.
Both communicate with other programs only by file exchange; this is
important to get a new language integrated into projects.
>
>My manager's arguments are:
>
>* There is an existing (important) code base (a static C code
>analyser) coded in C and C++ and it is unreasonable to recode it.
This is of course a hard argument. But: Managers never want to pay for
recoding anything even if recoding is reasonable. There must be some
additional profit from recoding, such as a better program structure,
performance improvements, features that can ONLY be implemented after
the program has been recoded. It must be a dramatic story.
Possibly some parts can be reused by the C interface.
>
>* Ocaml is an academic langage
An ESPRIT project would be a chance that ocaml leaves the universities.
It is one of the tasks of a public project to transfer knowlege from the
academic world to the industry.
If the argument would count, we all would have to program in COBOL; many
wide-spread languages have their roots in the universities. Think of procedural
languages and object-oriented languages, both coming from the academic world.
I think Ocaml is actually only academic in the sense that most users can
be found at the universities. It is truly not the case that Ocaml addresses
academic problems. Ocaml avoids some of the Lisp errors:
- it is an "open world", i.e. well-integrated into the existing operating
systems
- it has a rich syntax
>* Ocaml is a slow implentation
This is not true; speed depends on the mainly used data structures. I expect
that abstract interpretation mainly works with term structures, and Ocaml is
fast on them. Possibly you need some benchmarks.
There are of course other technical features besides speed:
- Ocaml has a garbage collector, C and C++ don't have. Memory management is one
of the important advantages of OCaml, because the search for memory leaks
usually takes a considerable amount of time in C/C++. Note that memory leaks
slow down programs.
- Ocaml does not know NULL or bad pointers. This is a matter of stability, and
C/C++ programs almost always crash because of bad pointers.
- Ocaml is portable across platforms.
- Ocaml has a good string implementation (if this counts)
- Ocaml has exceptions, C does not have, C++ sometimes.
- Ocaml has scripting. This often reduces the time for tests.
- Ocaml has small memory footprints compared with C++.
>* Ocaml is hard to learn for people (fluent in C++) with less than a PhD
>in computer science (unfortunately for me, I do hold a PhD in
>Artif. Intel.)
People how really CAN C++ should have no problems in learning OCaml, as C++
is one of the most complicated languages currently available. (Does anybody
know a CORRECT C++ compiler?) Ocaml is much simpler (in the sense that it is
more systematic).
Many people coming from imperative languages have in deed problems learning
Ocaml because there is much more recursion, there are closures, iterators, and
other features they do not like or they have not seen yet at all. But:
- These constructs, once learned, are very productive. You can often express
the same more consisely.
- There are imperative constructs, too, and they look like as one expect (i.e.
the ";" denotes statement sequencing, there are "for" and "while" loops and
so on). You need not to jump into the cold water: you can start with an
imperative style and adopt step-by-step the functional constructs.
I think that functional constructs are not academic, there are many examples
of them but most people do not recognize them:
- Explain your boss that the Unix commands "find" and "xargs" are higher-order
functions.
- Every program generator is a closure (but inefficiently implemented)
- CGI programs are often purely functional (because you do not have a
background state)
- ...
The difference is that these applications of functional constructs are
exceptions from the usual way, and that Ocaml uses them systematically.
NB: I do not have a PhD.
Gerd
-- ---------------------------------------------------------------------------- Gerd Stolpmann Telefon: +49 6151 997705 (privat) Viktoriastr. 100 64293 Darmstadt EMail: Gerd.Stolpmann@darmstadt.netsurf.de (privat) Germany ----------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:24 MET