Re: [Caml-list] ocaml complexity

["Jonathan Coupe" <jonathan@meanwhile.freeserve.co.uk>]

----- Original Message -----
From: <leary@nwlink.com>
To: "Jonathan Coupe" <jonathan@meanwhile.freeserve.co.uk>
Cc: <caml-list@inria.fr>
Sent: Friday, June 08, 2001 10:41 AM
Subject: Re: [Caml-list] ocaml complexity


> On Thu, Jun 07, 2001 at 07:29:27PM +0100, Jonathan Coupe wrote:
> > 1. Perl was perceived by the adopters who gave it critical mass as being
> > fundamentally like the languages they already knew (bash, C, Awk) It was
a
> > low risk, low effort, low fear choice.
>
> A Hitchhiker's Guide to type theory (and all the other alien things my
eyes
> glaze over at on this list) aimed at the unwashed masses would go a long
> way to making OCaml (and functional programming in general) more
> accessible.  Did I pass over one somewhere?
>
> > 2. Perl is aimed most of all at small projects. The risk of trying new
tools
> > in this space is low - throwing away a 200 lines of code is annoying,
but
> > not job threatening. And benefits are quickly perceiveable. Ocaml's best
use
> > is probably larger projects beyond the scope of scripting languages.
> > Throwing a way an even quarter completed project is likely to mean the
loss
> > of several thousand lines of coding effort, and you're unlikely to have
> > proveable benefits until the end of the first project, which is more
likely
> > to be months, not days or hours, after starting work.
>
> How much time and money do development teams spend creating and tracking
> down memory management errors in C and C++ starting on day one?  At least
> some of the benefits are immediate and ongoing.
>

If this was the decisive issue, people would just use C++ with GC. It's as
simple as doing a search for Boehm or Great Circle. I think the memory leak
issue for C++ is overstated (except possibly for very large projects.) For
competent teams, memory management is rarely an issue. C++'s real problems
are elsewhere: compiler breaking language complexity, poor generics, lack of
interpretive systems, no widely supported block\closure equivalent, nasty
type system, appalling phyical dependency issues, and bottom of the line
syntax for function calls.

Finally, you don't really know the cost/benefit ratio for a technology until
the day you manage to ship. You certainly won't be able to convince any
sceptical colleagues or managers of it, and that's what governs the adoption
rate for new technologies.


> > 4. Its easy to perceive Perl's strengths from an initial examination,
and
> > perhaps harder to pick up on its weaknesses.
>
> I can say exactly the same of OCaml.

Then you should say what these easy to percieve strengths are. The major
strengths of OCaml I'm aware are definite and considerable, but take time to
appreciate.

For Perl it's easy - great regexp, decent ability to wrap C, lots of
libraries, fast coding (as evidenced by the number of lines of code to write
a demonstration program - the easiest to perceive test for potential
adopters), improved file handling and loops compared to the languages it
took over from, an error tolerant runtime machine.

The point here isn't that Perl is a better or even good language. I don't
*like* Perl. The point is that it's benefits are easily communicated to
potential users:  communicating the potential benefits of Perl takes no more
than showing a 200 line C-program that's been re-written as a 17 line Perl
program.

This is not the case for OCaml. It's much hard to convey the benefits of its
support for functional programming. Many programmers don't know what fp is;
more are positively allergic to it because of bad academic intoductions.
It's not easy conveying the benefits of the OCaml type system to an
industrial C programmer either. Claiming benefit here is easy. Persuading
someone else that it exists requires real intellectual effort on your part
and theirs. I don't think anyone could this better than Mark Dominus did
with his article, which is probably a good hour's read. If the benefits
Ocaml provides here were obvious, I don't think you'd have written that
trying to understand the type system makes your eyes "glaze over."

Perl is widely used. Ocaml, Scheme, CLOS and Smalltalk aren't, despite being
better languages. The reason why is partly that Perl is a more marketable
language - it fits into niches where new tools can spread more easily, and
because its benefits are easily communicated, potential users can easily be
persuaded to try it out.

Jonathan Coupe


-------------------
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