Re: [Caml-list] Re: productivity improvement

[John Carr <jfc@MIT.EDU>]

> >Looking at Halo [1] credits, one can see that it was developed by about 10 
> >programmers (there were also testers and artists involved). A single O'Caml 
> >programmer capable of developing such a game alone should certainly stand to
> >make tons of money. Then why don't we see much software written in O'Caml?
> >
> >I'm not buying the argument that "O'Caml isn't used in the industry because 
> >investors and project managers are stupid". 
> >
> Two major reasons.
> 
>     (1) licence uncertainty
>     (2) lack of programmers
> 


As a new OCaml programmer let me describe the other barriers to entry:
    (3) programming style
    (4) development environment
    (5) grammar, semicolons, and other quirks

(3) programming style

This is related to (2).

Leaving out classroom use, the majority of the target audience for a
general purpose language consists of C/C++ programmers.  (Some are
recent CS graduates -- see below -- and maybe Microsoft Visual-whatever
drones should be counted as a separate category.)

At my last job we switched from C++ to Java.  We had a few experienced
Java programmers and an MIT professer with her new Java textbook.  Two
weeks were sufficient to learn the new language sufficiently well to
start writing real code.  Java is designed to look like C with classes
and garbage collection.  As a result, it is easy to find or create
Java programmers.

OCaml is not related to C.  It doesn't look like C (see below) and it
doesn't work like C.  The object oriented features are harder to learn
than those in C++.  Moving from C to a functional language is not
natural.  Retraining software engineers will take longer and some will
not be able to make the transition.

Recent CS graduates may do better than established C programmers.
They should have had recent experience with functional languages.
(I hear many students have trouble with "lambda" in introductory
CS courses.  I assume those who graduate understand.)  However,
few students will come out of school knowing OCaml.

This is a fundamental barrier and managers are right to be wary.


I did use a non-mainstream language once in a commercial software
product.  I wrote the test suite for my program in Scheme.  This
was feasible because the group was very small and my boss liked
Scheme.  For the particular application it was a good choice.


(4) development environment

I wanted to compile the HTTP client tool from one of the ocaml web
sites.  Doing this required finding, compiling, and installing three
or four other ocaml libraries plus a C library which I had to search
elsewhere for.

The core language -- the tarball from the OCaml web site -- is well
packaged and seems reliable, but the surrounding chaos feels more like
a hacker project than a solid development platform.  A developer using
C on a Unix system has more software in a standard installation.

(Is it possible to do Java-style hierarchical naming or C++ namespaces
in OCaml?  One of these is probably essential in the long run.)


(5) quirks

If OCaml is to be taken seriously it needs a compiler with better
error messages.  I remember switching 15 years ago from pcc (the
"Portable C Compiler" that came with BSD 4.2) to Metaware High C and
gcc.  pcc emitted a single unhelpful error message followed by a
cascade of secondary messages.  The newer compilers generated helpful
error messages and had error recovery so any later messages were
likely to be related to further code errors.  My productivity
substantially increased as I was able to understand what errors meant
and fix more than one error per edit-compile cycle.

ocamlc is like pcc, but without the cascading errors.

A tool like "lint", that parses a file and looks for problems, might
be adequate for this purpose.  The ideal solution would be two
independent language implementations.

The use of semicolon as an optional statement separator rather than a
mandatory statement terminator causes a lot of extra work for me.  I
understand the C rules about where a statement begins and ends.  The
OCaml rules are confusing and I often must resort to trial and error
to resolve compilation errors.  I want to know WHY the compiler thinks
my exception handler expression should have type unit.  It should tell
me "the inferred type for the value expression of the try clause at
line 120 (unit) does not match the inferred type for the value
expression of the with clause at line 130 (string)".

The lack of operator overloading makes the transition from C to OCaml
harder.  (I understand why type inference and overloading are
difficult to reconcile, but the omission is still annoying.)



Having said all that, my personal goal for this summer is to learn
a new language and write a useful program in it.  I chose OCaml and
I will reserve judgement until I have completed that task, or failed.


    --John Carr (jfc@mit.edu)
-------------------
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