From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 128A9BCAE for ; Mon, 18 Jul 2005 20:47:33 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j6IIlW2F018045 for ; Mon, 18 Jul 2005 20:47:32 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA02796 for ; Mon, 18 Jul 2005 20:47:32 +0200 (MET DST) Received: from alex.barettalocal.com (h213-255-109-130.albacom.net [213.255.109.130] (may be forged)) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j6IIlVFF018042 for ; Mon, 18 Jul 2005 20:47:31 +0200 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by alex.barettalocal.com (Postfix) with ESMTP id A4CC42BAA98; Mon, 18 Jul 2005 20:45:45 +0200 (CEST) Message-ID: <42DBF8D9.7060004@barettadeit.com> Date: Mon, 18 Jul 2005 20:45:45 +0200 From: Alex Baretta User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Morelli Cc: Ocaml Subject: Re: [Caml-list] (Mostly) Functional Design? References: <9cc3782b05071411004b27b6a4@mail.gmail.com> <42DB6161.4030507@cs.utah.edu> <42DB74DC.8030201@barettadeit.com> <42DBF1C6.7080005@cs.utah.edu> In-Reply-To: <42DBF1C6.7080005@cs.utah.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 42DBF944.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 42DBF943.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; baretta:01 caml-list:01 morelli:01 baretta:01 ocaml's:01 ocaml:01 tarballs:01 compiler:01 ocaml:01 model:01 syntax:01 event-driven:01 computations:01 api:01 coherence:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.2 X-Spam-Level: Robert Morelli wrote: > Alex Baretta wrote: >> Your points are very simply wrong. Functional design addresses the same >> large-scale design problems that OO tries to address, and, in fact, >> given cognitive compatibility with the mind of the developere, it offers >> a productivity at least an order of magnitude greater on very large >> scale projects (over 100klocs) where the dominant cost factor is code >> maintenance. Ocaml's functional paradigm greatly stresses a priori > > With all due respect, claims of order of magnitude productivity > gains, that OCaml is a far better language than Java, etc. are > exactly the kind of advocacy that I think is counterproductive. > Most programmers would regard such dramatic statements as implausible, > if not preposterous. As of today, I am unable to compute any software metric over my repo, including the banal and meaningless klocs. This is due to the need to develop faster than the tree maintainer--that is, I--can verify changesets and commit them to a repo. Currently, my collegues are working each on his own tree and producing tarballs as backups, which pile up waiting for me to merge them. Since I cannot give you numbers, let me give you ideas about what we did: we have written a compiler for a functional web oriented language--the Xcaml--which is to Ocaml what JSP is to Java; we have written a virtual machine for this language implementing the execution model for an Xcaml application; since Xcaml needs a very strong level of intgration with relational DBs, we developed the Xcaml DataBase Specification language and toolchain, which compiles OO-ER models down to logical, physical and virtual DB schemas--thus supporting design refinement at the intermediate level--and compiles the whole thing to SQL-DDL and to Ocaml database access libraries; the Embedded SQL is a syntax extension to Ocaml which compiles SQL queries to calls to the data access libraries generated by the XDBS, thus delegating static typechecking of SQL queries to the Ocaml type system. Collaterally we have developed Machiavelli: a event-driven asynchronous servlet framework, working behind the scenes of the Xcaml application to perform long running computations that would lock the HTTP user agent for too long. On top of all this we are developing FreerP--a full fledged ERP application. We are almost there: FreerP currently manages sales, stock inventory, logistics, accounting. Besides all this we have developed Schopenhauer, a realtime soft PLC/CNC based on Ocaml, which we use to control industrial equipment such as glass cutting machines or metal sheet cutting machines. Schopenhauer has a seemless integration with the Xcaml system, so that user interfaces can be based on the web, and can easily take advantage of the powerful database API. Schopenhauer is actually our most successful technology commercially, at least this year. Now, how many man years have gone into this: about 5. I can guarantee that with Java this would not be feasible. >> correctness via static type-checking, which we take advantage of to >> achieve static verification of the Embedded SQL queries in our FreerP >> suite of business applications. It is only thanks to the rich type >> system in Ocaml that we are able to maintain coherence between a >> database schema counting hundreds of relations and hundreds of Xcaml >> server pages containing at least as many embedded SQL queries. Java >> simply would not scale. > > The use of type checking is a point where the FP community > has not reached consensus, as there are widely divergent views from > the Scheme community and the ML and Haskell communities. Even between I am not advocating FP languages. I am advocating type-checking over everything else and Ocaml as the most productive language I have ever seen. > I am not familiar with your FreerP technology and its use of Xcaml, > but I will not dispute your claim of great success. It just seems > likely to me that you've taken advantage of uncommon insight to > cast your problems into a new sort of niche application. Relational > algebra is after all not so far from category theory. Perhaps you've > found an approach that could be used in many more applications to > business. If so, I wish you success. Thank you. I wish ourselves as much. I might have had some clever ideas, but mainly I have taken advantage of what the type system gives me: deferred binding of recursive calls, extensional polymorphism and recursive types, a tiny bit of OO (I miss Javascripts delegation so much!), a couple of recursive modules, iterators, high level datastructures such as sets, maps and real-time deques. We have also used an old-time Obj.magic hack to achieve polymorphic recursion in one function which simply could not be done without it. But I have a correctness proof ;) Alex -- ********************************************************************* http://www.barettadeit.com/ Baretta DE&IT A division of Baretta SRL tel. +39 02 370 111 55 fax. +39 02 370 111 54 Our technology: The Application System/Xcaml (AS/Xcaml) The FreerP Project