English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
(Mostly) Functional Design?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-07-19 (00:44)
From: Jonathan Bryant <jtbryant@v...>
Subject: Re: [Caml-list] (Mostly) Functional Design?

On Mon, 2005-07-18 at 15:16 -0700, Paul Snively wrote:
> 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
> Version: GnuPG v1.4.1 (Darwin)
> iEYEARECAAYFAkLcKl4ACgkQO3fYpochAqLIywCfcvn6l/UrazIK3d7Wxm9RTt0T
> qmwAoNADqJErYWaC3m3oxUx0ZxOlWciX
> =rkZl
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
|Jonathan Bryant          |
|Valdosta State University|
|Information Technology   |
|System Operations        |
|jtbryant@valdosta.edu    |
|x6358                    |