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

[Paul Snively <psnively@mac.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jul 18, 2005, at 2:27 PM, skaller wrote:

> On Mon, 2005-07-18 at 12:15 -0600, Robert Morelli wrote:
>
>
>> 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.
>>
>
> Yes they would .. until they tried it.
>
I'm going to allow myself to be guilty of exactly what I deplored  
about the original e-mail, namely offering personal opinions and  
anecdotes without citations or sources of any kind. :-)

Although I had the great good fortune to learn Scheme as my third  
language after BASIC and Z-80 assembly language and to attend Indiana  
University and hobknob with the likes of Dan Friedman and Douglas  
Hofstadter, by far the majority of my for-pay programming work has  
been in 680x0 assembly language, C, C++, and Java. I've been doing  
this for about 25 years now. I supported Macintosh developers in the  
transition from Object Pascal to C++ in the MacApp 3.0 timeframe,  
roughly 1989-1991, provided background research for a presentation  
that Larry Tesler gave about Apple's approach to supporting dynamic  
linking of C++, and unofficially supported Macintosh Common Lisp,  
which at the time was owned by Apple. More recently, I spent  
essentially the entirety of the dot-com years working with Java,  
doing everything from what, as far as I know, was the first applet  
used in a movie promotional site (for one of Peter Jackson's earlier  
films, "The Frighteners") to replacing the back-end infrastructure  
for a large multimedia/social site (iFilm.com). I currently develop C+ 
+ for a combined Linux server/set-top box conditional access system  
for the cable/satellite industry.

I found Objective Caml in a rather roundabout way: I first started  
paying attention to distributed programming and data replication  
issues while at Apple, as part of an effort to reduce the tendency  
that any large organization has to construct numerous "data silos,"  
the left hand not knowing what the right hand is doing. As this was  
about 1990, my investigations led me to Ken Birman's work on the  
Horus project at Cornell. While we never did anything with Horus, I  
continued to pay some attention to it, off and on, over the years.  
Fast forward about a decade, and I was thinking about distributed  
programming again, in the context of the game industry (I've had a  
couple of game programming jobs before). By this time, Birman's group  
had moved on to create the Ensemble system, which was written in  
Objective Caml.

I'd never really cottoned to the ML family before, finding the syntax  
to be too unlike Pascal or C and not being able to really see the  
benefit over, say, Common Lisp or Scheme. O'Caml seemed a bit  
different: it was object-oriented as well as functional, was  
apparently reasonably fast, and the Ensemble team seemed to put great  
stock in being able to prove certain tricky bits of their system  
correct by virtue of having access to a formal semantics for the  
parts of O'Caml that they used. This made for an intriguing  
combination, with Ensemble as a compelling proof-by-demonstration.  
Fast forward again, because I'm still doing this on my own free time,  
but I have enough experience now to suggest that John is correct: the  
ML family in general, but O'Caml in particular, provides extreme  
productivity benefits over the currently popular languages. I find it  
to be on a par with Common Lisp in expressive power, and in fact I  
find the factors in Common Lisp and O'Caml's productivity enhancement  
to be roughly similar:

* Both are functional, in the sense of supporting the use of higher- 
order functions
* Both are imperative. Sometimes the judicious use of state is the  
most efficient, along a number of dimensions, approach to solving  
your problem
* Both are object-oriented. Sometimes the judicious use of inclusion  
polymorphism, etc.
* Both are geared towards programming-in-the-large: package/module  
systems, documentation-construction tools, sophisticated steppers/ 
debuggers/inspectors, etc. make structuring systems easier
* Both recognize that a software development ecosystem needs more  
than just a core language: reasonably comprehensive libraries are  
also important

and here's what I think of as the kicker, the above being necessary,  
but not sufficient, properties of a productive development environment:

* Both are interactive, encouraging a playful, exploratory, discovery- 
oriented programming style.

I can't emphasize enough how crucial O'Caml's provision of a  
toplevel, bytecode compiler, and native compiler are. There is no  
substitute for being able to type in some code and see what happens  
without a whole edit/compile/link/test/crash/debug cycle. Of course,  
it's also important to be able to commit to an implementation and  
have it perform acceptably. Modern Lisps and O'Caml have these bases  
covered. You can get close-ish with a good Standard ML, but there's  
no one system that ties it all together like O'Caml does (you have  
to, e.g. mix and match something like Moscow ML with something like  
MLton to get both the interactivity and the final performance out of  
Standard ML). This is the key. The Lisps and O'Caml let me have a  
thought and be playing with that thought instantly; they don't yank  
me out of the thought while I'm waiting for my compiler/linker,  
either the first time, or whenever I make a mistake. I don't know how  
to put this any better: as a programmer, I get into a rather fluid  
state of analysis/synthesis with respect to my problem domain. Lisp  
and O'Caml sustain that fluid state; virtually all other language  
environments shatter it. And yes, the difference, in my experience,  
is roughly an order of magnitude in productivity. But because this  
productivity comes from sustaining this fluid analytical/synthetic  
process, it can't be described in any meaningful way; it can only be  
experienced, and this is a real burden to impose upon those who are  
quite rightly skeptical about such claims, which is why, apart from  
this e-mail, I don't generally bother trying; I limit my advocacy to  
saying "Why not take O'Caml for a spin some weekend? What have you  
got to lose?"

> -- 
> John Skaller <skaller at users dot sourceforge dot net>
>
>

Best regards,
Paul Snively

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iEYEARECAAYFAkLcKl4ACgkQO3fYpochAqLIywCfcvn6l/UrazIK3d7Wxm9RTt0T
qmwAoNADqJErYWaC3m3oxUx0ZxOlWciX
=rkZl
-----END PGP SIGNATURE-----