Re: [Caml-list] Re: productivity improvement

[Michael Vanier <mvanier@cs.caltech.edu>]

Dave,

I agree with your comments.  I think it's very important that we (ocaml
fans) avoid becoming dogmatic.  I think most of us would agree that we
would rather code in ocaml than in just about any other language.  That
said, the choice of problem is going to make a world of difference in
whether ocaml is really the language of choice.  Some problems are just
going to be more easily solved (or produce better results) in other
languages, and we just have to accept this.  No one tool is perfect for all
tasks.  For instance, trying to use ocaml in domains where C or Fortran
rule (heavy numerical computing on simple data structures) is interesting
but probably doomed to produce inferior results in many cases (unless you
use ocaml as a fancy compiler or partial evaluator that spits out C code,
that is ;-)).  As the ocaml developers have pointed out, when the data
structures become very intricate, then ocaml starts to win in a big way.

As for popularity, I feel that the grassroots approach is best.  Pass the
word about ocaml on to the ten best hackers you know, try to get them
hooked on the language, use it to tackle problems that would be absurdly
hard in other languages (not ones that can be done well in any language),
and publicize your results.  This will work, although it won't work
overnight.  I've already noticed that more and more courses in CS
departments are using ocaml because of its flexibility; this by itself is
going to introduce ocaml to a large number of new students, many of whom
will spread the word to others.

Mike

> Date: Sun, 20 Oct 2002 13:46:47 +0100
> From: Dave Berry <daveb@tardis.ed.ac.uk>
> 
> Eray, I think you misunderstand where I'm coming from.  I would love to see
> more people using ML instead of C++.  I was part of a team that produced
> one of the commercial SML compilers. All three commercial SML compilers
> have failed, partly because it's very difficult to persuade people to
> switch.  People aren't stupid, and they won't switch to a new language
> without some compelling evidence that it gives an advantage.  I believe
> that a 2:1 or 3:1 gain in a meaningful measure -- the best measure being
> overall cost -- would be sufficient to persuade a reasonable number of
> people to switch.  But, we need concrete evidence.  This is hard to obtain,
> because few people have the time to write a project twice, using different
> languages.  What's more, when studies of this sort have been done,
> comparing more conventional languages, the results have shown that the
> choice of language makes little difference to the overall cost of the
> project.  So there's a widespread suspicion of claims that language X or Y
> increases productivity by significant amounts.
> 
> In this context, figures plucked from the air are, at best, not helpful; I
> think they're actually counter-productive.  To an extent, the bigger the
> claims, the more counter-productive they are, because they're easier to
> challenge.  I would rather have one verifiable claim of a 3:1 productivity
> improvement -- which is a pretty big win -- than a hundred unverifiable
> claims of 10:1, 20:1 or even 40:1 gains.  (Given earlier postings on this
> thread, it's worth reiterating that the type of program is also vital --
> e.g. figures for a one-week project may not scale to a ten-year project).
> 
> This thread gave one very useful example: the rewrite of Ensemble.  IIRC,
> this gave a 7:1 gain in LoC over the original C version.  Even if one
> allows for the benefit of writing the program a second time, and for the
> fact that LoC doesn't necessarily correlate directly to development time,
> this is still an impressive figure.
> 
> Way back when this thread started, I quoted another example: Andrew Appel's
> Tiger compiler.  This has three versions, one in C, one in Java, and one in
> SML.  The SML is shorter, but not to such a great extent.  (I need to
> recheck the actual figures).
> 
> Dave.
> 
> 
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> 
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners