caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: John Max Skaller <skaller@ozemail.com.au>
To: Alessandro Baretta <alex@baretta.com>
Cc: Ocaml <caml-list@inria.fr>
Subject: Re: [Caml-list] Unix.file_descr -> int ???
Date: Thu, 20 Jun 2002 02:22:53 +1000	[thread overview]
Message-ID: <3D10AFDD.5050908@ozemail.com.au> (raw)
In-Reply-To: <3D0FB722.6000009@baretta.com>

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


  reply	other threads:[~2002-06-20  6:52 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-18 13:38 Alessandro Baretta
     [not found] ` <000101c21705$d9f23640$0501a8c0@lexifi01>
2002-06-18 22:41   ` Alessandro Baretta
2002-06-19 16:22     ` John Max Skaller [this message]
2002-06-20 11:23     ` Xavier Leroy
2002-06-20 11:52       ` Markus Mottl
2002-06-20 13:14       ` Alessandro Baretta
2002-06-20 13:23         ` Stefano Lanzavecchia
2002-06-20 16:22           ` Alessandro Baretta
2002-06-20 14:42         ` YAMAGATA yoriyuki
2002-06-21 16:16           ` [Caml-list] proposal for library Christophe Raffalli
2002-06-22 11:56             ` Nicolas Cannasse
  -- strict thread matches above, loose matches on Subject: below --
2002-06-20 12:24 [Caml-list] Unix.file_descr -> int ??? Ohad Rodeh
2002-06-12  9:53 Damien Doligez
2002-06-12  9:57 ` Jacques Garrigue
2002-06-12 11:04   ` Jacques Garrigue
2002-06-11 14:31 Max Kirillov
2002-06-11 15:40 ` Bruno.Verlyck
2002-06-11 15:45 ` Xavier Leroy
2002-06-11 19:26   ` Max Kirillov
2002-06-11 23:12     ` Berke Durak
2002-06-12  0:10     ` Jacques Garrigue
2002-06-12  8:08     ` Xavier Leroy
2002-06-12  7:42   ` Basile STARYNKEVITCH
2002-06-12  8:21     ` Xavier Leroy
2002-06-12 16:06       ` Max Kirillov
2002-06-13 10:24       ` Jean-Marc Eber
2002-06-12 13:09     ` Bruno.Verlyck
2002-06-12 15:44   ` John Max Skaller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D10AFDD.5050908@ozemail.com.au \
    --to=skaller@ozemail.com.au \
    --cc=alex@baretta.com \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).