Re: [Caml-list] (Mostly) Functional Design?

[Alex Baretta <alex@barettadeit.com>]

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)
<http://www.asxcaml.org/>

The FreerP Project
<http://www.freerp.org/>