[Ocaml-biz] The strategic future of OCaml for 2..4 years

[Brian Hurt]

On Mon, 6 Sep 2004, Brandon J. Van Every wrote:

> I say 'random' because I see so many OCaml technologies in an early
> adopter stage, with like 10 different home-brewed tools to do the same
> job.  

You know, I had an interesting experience recently, apropos the maturity
of tools.  Having gotten more or less sorta test infected in Java and
Ocaml, I went looking for unit testing tools for C.  A couple of home-brew
solutions sorta exist.  The documentation comment processing tools are
almost usable (not quite), but the unit testing tools are crude at best.  
By the standards of Java and Smalltalk, both Ocaml and C are laughable.
Almost no one in the C world uses either.  C++ does a little bit better.

This got me to thinking about tool cultures.  What we expect of our tools 
is more a function of what culture we come from, not some absolute 
standard.  Ocaml comes from the C/Unix world.  This shows not only in the 
tool set, but also in language features (printf is, IMHO, a questionable 
feature in C- but notice Ocaml adopted it, while Java and C++ have very 
different "native" I/O libraries). 

There are at least three major "programming cultures" out there that I can 
identify.  The first, as mentioned, is the C/Unit world.  The second is 
the C++/Windows world, and the third Java.  Or, should I say, the Make, 
VS, and Ant worlds.

When discussing tool maturity, what culture you are aiming at becomes very 
relevent.

Which is one of the reasons why I feel aiming at the open source
community- still by and large from the Make culture- easier than aiming at
other cultures.  I would rate the toolset for this culture as sufficient,
even superior.  I'd love Ocaml to become dominate in all three spaces (I 
think the Java/Smalltalk/Ant communities will, actually, be the hardest to 
crack).  But I think short-term, open source/Unix/Make/C is the place to 
target.

It also explains, I think, the friction between you and the INRIA people.  
They are definately from the Make culture, you're from the VS culture.  
For the record, I'm from the Make culture, although I'm familiar with all 
three.

Note that the culture Ocaml grew out of has it's advantages and 
disadvantages.  It gave Ocaml a mature and power set of tools from the 
get-go.  But it also saddled Ocaml with a set of tools with some serious 
shortcommings.

> We're not talking about a company that develops and mandates a
> tool, nor any kind of official standards effort.

This, IMHO, is an advantage.  It's a free market of ideas and 
implementations, not a demand economy dictated by one central authority.


> I think the strategic reality is clear.  Python *WILL* achieve
> performance before OCaml ever becomes popular, if Python performance *IS
> POSSIBLE AT ALL*.  Only if Python is heading for some kind of
> fundamental brick wall, will it be otherwise.

Unless they are giving up intepreting, they are headed for a brick wall.  
Intrepreting will always be dog slow.  Virtual machines have possibilities 
(witness the various benchmarks around showing Java about as fast as C++), 
but they require one hell of a development effort- we're talking five, 
maybe ten years for open source to push one out.  This isn't to write one, 
this is to write one that can really compete with native code.  

The obvious solution is to drop a Python front end onto the GCC backend.  
A small team could do this easily in 12 months or less.  The question is 
wether the community would a) think of it, or b) accept it.  I'll thank 
the people on this list for not spreading the word :-).

> I wish it were possible to doll up OCaml and then sell it like hotcakes,
> but that is sheer fantasy.  It is but a language, determined by the
> slow, lugubrious nature of the language market.

Large, application level projects tend to be few and far between.  And by
their nature, they tend to be conservative.  It's one thing to waste a
couple of weeks only to discover the language won't work for the project,
another to waste months or years to discover the same thing.  Perl,
Python, Ruby, all succeeded (to the extent that they succeeded) initially
in the scripting market- short, low-risk programs.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian