Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: [Caml-list] Unix.file_descr -> int ???
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: John Max Skaller <skaller@o...>
Subject: Re: [Caml-list] Unix.file_descr -> int ???
Alessandro Baretta wrote:

> How can customers not realize that improvements in the production 
> technology necessarily translate to reduced costs and improved quality? 

They don't realise it, because it isn't the case. They're right, in 
general -- meaning,
most of the time. Ocaml is high risk. It is unstable, there are few 
programmers
around, and you can't sue the Ocaml team if something doesn't work.
You can't *demand* a fix by saying 'I paid heaps of money for this
product, you better fix it or I'll sue'.

Of course, the reality is that Ocaml team is more likely
to be responsive. But as a counter-example, I found a bug months
ago that was only recently fixed: I couldn't force the ocaml team
to believe me that there really was a bug in the compiler.
I didn't have an expensive maintenance contract either.
So I have had to use Ocaml 3.01 for ages now. (I'm using
the CVS version now the bug is fixed).

I'm currently working on a project using Python.
The 'boss' is a programmer. We're opting for 1.5.2,
a well recognized, widely installed, stable version.
Yet Python 2.2.1 has major improvements, including
lexical scoping (Heh! functional programming in Python).

Why? Because when it comes to small productivity
improvement (maybe) against risk, management --
even technically aware management -- will chose
to minimise risk every time.

It makes sense. They just need the programs to make
their business run. A small increase in costs is less important
than risking a catastrophy.

To see what it takes to overcome this kind of barrier,
just look at how much money Sun has spent to promote
Java. (Oh dear, what a terrible setback for computing).

BTW: I used Ocaml in a heavy industrial setting ..
but it was for writing a compiler -- something Ocaml is
so very good at.  In this case, the timeframe for, say, a C++
solution would have meant they missed the boat entirely.
So sometimes, superior technology does win --
when the risk seems justified or low.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850
-------------------
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