Browse thread
[Caml-list] Completeness of "Unix" run-time library
-
Vasili Galchin
- james woodyatt
-
Richard Jones
-
Shawn Wagner
-
Eric Stokes
-
Vasili Galchin
-
Eric Stokes
-
Vasili Galchin
-
Matt Gushee
-
Richard Jones
-
Nicolas Cannasse
- Diego Olivier Fernandez Pons
- Wolfgang Müller
-
John Carr
-
Richard Jones
-
oliver@f...
-
John Carr
-
Richard Jones
- Jacques Garrigue
- Benjamin Geer
- Michael Vanier
- Sven Luther
-
Richard Jones
- Sven Luther
-
John Carr
-
oliver@f...
-
Richard Jones
-
Nicolas Cannasse
- Shawn Wagner
- Vasili Galchin
- Vasili Galchin
-
Richard Jones
-
Matt Gushee
-
Vasili Galchin
-
Eric Stokes
-
Vasili Galchin
-
Eric Stokes
-
Shawn Wagner
- Stefano Zacchiroli
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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