Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <99073022222600.00491@schneemann> (raw)
In-Reply-To: <14239.6150.864319.797849@gargle.gargle.HOWL>

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




  parent reply	other threads:[~1999-08-12  9:56 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-07-28 14:47 STARYNKEVITCH Basile
1999-07-30  9:00 ` Markus Mottl
1999-08-13 10:32   ` John Skaller
1999-08-25  1:51     ` Frank A. Christoph
1999-08-25  3:50       ` John Skaller
1999-08-25  6:34         ` Frank A. Christoph
1999-08-26 18:36         ` Stefan Monnier
1999-08-29  6:08           ` John Skaller
1999-08-27 10:00         ` Andreas Rossberg
1999-08-28  6:24           ` John Skaller
1999-08-30 15:59             ` Sylvain BOULM'E
1999-08-31  5:50             ` Brian Rogoff
1999-08-28 19:51           ` Dave Mason
1999-08-30 19:05             ` Xavier Leroy
1999-08-30  8:02           ` Pierre Weis
1999-08-30 19:35             ` John Skaller
1999-08-31 17:10               ` Pierre Weis
1999-09-03  6:56                 ` John Skaller
1999-08-31 19:03               ` Stefan Monnier
1999-09-03  7:28                 ` John Skaller
1999-08-31  0:13             ` John Prevost
1999-08-31  5:19               ` John Skaller
1999-08-31  6:35                 ` John Prevost
1999-09-03  5:42                   ` John Skaller
1999-08-31 16:24           ` Gerard Huet
1999-07-30 14:42 ` John Skaller
1999-07-30 18:49 ` Gerd Stolpmann [this message]
1999-07-30 21:30 ` Francois Rouaix
1999-08-12 10:36 ` Reply to: " Jens Olsson
1999-08-16 18:33   ` Chris Tilt
1999-08-12 12:15 ` Frank A. Christoph
1999-08-15  8:14   ` Friedman Roy
  -- strict thread matches above, loose matches on Subject: below --
1999-09-07  7:24 TommyHallgren
     [not found] <John Skaller's message of "Tue, 31 Aug 1999 15:19:48 +1000">

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=99073022222600.00491@schneemann \
    --to=gerd.stolpmann@darmstadt.netsurf.de \
    --cc=Basile.Starynkevitch@cea.fr \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox