Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Completeness of "Unix" run-time library
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Richard Jones <rich@a...>
Subject: Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)
On Thu, Mar 18, 2004 at 08:12:36AM -0500, John Carr wrote:
> 1. Nobody else knows the language.
> 2. It doesn't run on our platform.
> 3. It will break and we can't get support.

These things will always be a problem until OCaml becomes (to use a
marketing term) a "whole product".  This means that it has a full
suite of supporting skills and documentation.  There are currently two
books, and a few web tutorials.  For OCaml to become a whole product
we'd need to see a few shelves full of books at the local bookstore,
and specialists in each city offering support, and major external
companies signing on.

Nevertheless, these things happen: if no one was ever an early
adopter, then nothing new would ever happen!  Perhaps your company
isn't ready to be an early adopter for risky new technologies.  Others
will adopt, and the whole product may come about eventually from this.

But, the structure of OCaml development might prevent this from
happening in the long run.  The timescales for a product to turn from
early adopter to widely adopted whole product are on the order of ten
years.  [ http://www.joelonsoftware.com/articles/fog0000000017.html ]
(It's no accident that Ruby is about ten years old, and for the first
time there's now a shelf of books on Ruby at Foyles on Charing Cross
Road).  Because of these long timescales, I believe that the process
is very sensitive to small differences along the way.  Potentially, a
small change in the OCaml development process might either kill off
adoption of OCaml, or might make it more rapid.

To give you an example of this thinking: computer languages are in a
constant race with each other to add new features.  In the last decade
I personally have gone from C compilers where the most innovative
feature might have been support for threads, or an ANSI-compatible
string library, all the way to languages like Perl where in a few
lines of code you can download a web page, parse it into a DOM and
insert the results into a database, or display it in an embedded Gtk
Mozilla widget.  The number and range of libraries that you need today
in a new computer language is just staggering to compete with what is
already available in the likes of Perl or Java SDK or .NET (Microsoft
was able to throw thousands of developers at the problem which is why
they created the whole of .NET in relatively few years - no other
company on earth has that luxury).

This means that if OCaml's development process is, on average, just
slightly slower than the average (however that would be measured) then
OCaml will NEVER overtake other languages and become widely adopted.
In this sense, an open, rapid development model is vital, and an
unresponsive team at INRIA could kill adoption, and eventually any
chances the language has of becoming widely used.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
http://www.YouUnlimited.co.uk/ - management courses

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