From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA08863 for caml-redistribution; Thu, 12 Aug 1999 11:56:17 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id XAA14361 for ; Fri, 30 Jul 1999 23:08:44 +0200 (MET DST) Received: from beach.frankfurt.netsurf.de (beach.frankfurt.netsurf.de [194.64.181.2]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id XAA22587 for ; Fri, 30 Jul 1999 23:08:43 +0200 (MET DST) Received: from schneemann.darmstadt.netsurf.de (board-89.darmstadt.netsurf.de [194.163.86.217]) by beach.frankfurt.netsurf.de (8.8.5/8.8.5) with ESMTP id XAA07745; Fri, 30 Jul 1999 23:08:35 +0200 (MET DST) Received: from localhost (localhost [[UNIX: localhost]]) by schneemann.darmstadt.netsurf.de (8.8.8/8.8.8) id WAA12037; Fri, 30 Jul 1999 22:22:28 +0200 From: Gerd Stolpmann Reply-To: Gerd.Stolpmann@darmstadt.netsurf.de Organization: privat To: STARYNKEVITCH Basile , caml-list@inria.fr Subject: Re: convincing management to switch to Ocaml Date: Fri, 30 Jul 1999 20:49:00 +0200 X-Mailer: KMail [version 1.0.17] Content-Type: text/plain References: <14239.6150.864319.797849@gargle.gargle.HOWL> MIME-Version: 1.0 Message-Id: <99073022222600.00491@schneemann> Content-Transfer-Encoding: 8bit Sender: weis 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 ----------------------------------------------------------------------------