Re: [Caml-list] Whither the Caml Consortium?

["Benjamin C. Pierce" <bcpierce@saul.cis.upenn.edu>]

> However, not so many people need syncronization.

It's a little difficult to tell precisely, but we estimate the current
size of the Unison user community at between 1000 and 3000.  My sense is
that the latent demand is much larger -- we have grown to this size with
very little advertising of any kind.  I don't know if this qualifies as a
killer app for you, but it's clearly moved beyond the ivory tower at this
point.

(One thing that has surprised me is how many windows-only users we seem
to have.  Since there are several pretty good commercial synchronizers
for Windows, I'd have expected a smaller demand from this community.)

> > But even if you have a killer-app written in OCaml you will still have to explain 
> > to your manager (and even more your colleagues) why you would not have 
> > been able to write this app in C++ or Java (or why it would have been much
> > more effort to do it in another language). I think that because competing 
> > languages are advertised with buzzwords and their list of "advantages" 
> > OCaml should be advertised too. 

An early version of Unison was written in Java.  In many ways, this was
fine (Java is a pretty nice language, if you don't mind the fact that
your code gets about 10x longer than an equivalent ML version), but there
were several serious problems with Java:

[Disclaimer -- we switched to OCaml three years ago, and some of these
points have undoubtedly gotten somewhat better in the interim.]

   - poor run-time performance (huge memory footprints, poor GC, etc.,
     etc.) 

   - poor portability (despite all the "write-once-run-anywhere" hype, we 
     had neverending hassles with this -- different Swing bugs on
     different platforms, Linux implementation always a year behind
     Windows and Solaris, etc., etc.)

   - poor system-level APIs (in particular, no support for critical
     filesytem operations like fstat)

   - poor distribution support (RMI is a nice design, but the
     implementation was unbelievably heavy and expensive)
   
When we switched to OCaml, all these hassles vanished.  The one technical
downside was that going to OCaml involved doing a certain amount of work
ourselves that was done for us in Java.  In particular, we had to roll
our own RPC package.  However, once this was done, we had something that
was right for the job, and that we could understand and control.
Moreover, it was fun. :-)

There is also, of course, a social downside of using OCaml rather than
Java: the developer pool is *much* smaller.  However, I don't think this
has really made much of a difference for the success of the project --
although the code is GPLed, most of it is pretty intense, and I suspect
that there are not that many people even in the bigger Java community
that would be capable of picking it up and contributing to the effort
without significant help from us (e.g., spending a summer at Penn, or
whatever).  Conversely, switching to OCaml has made a huge difference for
the core development team, and this has contributed significantly to the
overall success of the project.

All things considered, switching to OCaml was a huge win for Unison.

    -- B
    
P.S...

> Unison could be a killer application, but it lacks all user friendliness.

I'd be interested to hear more about what you meant by this (perhaps
off-list).

-----------------------------------------------------------------------------
BENJAMIN C. PIERCE
Associate Prof., Computer & Information Science        bcpierce@cis.upenn.edu
University of Pennsylvania                                    +1 215 898-2012
200 South 33rd St.                                       Fax: +1 215 898-0587
Philadelphia, PA 19104, USA                http://www.cis.upenn.edu/~bcpierce
-----------------------------------------------------------------------------





    
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr