Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] mixin modules paper and future?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-09-02 (12:34)
From: Alessandro Baretta <alex@b...>
Subject: Re: What kind of industry do you mean? (Was: [Caml-list] objective caml and industry)
Mattias Waldau wrote:
 > Do you mean by industry that you are going to
 > make commercial software using O'Caml?
 > As I see it there are several typical categories
 > of commercial programs:
 > 1. programs for internal use within an
 >    organization (price = production cost)
 > 2. server software (typical price > $15000)
 > 3. client software (typical price $10 to $1000)
 > and there are essentially two OS out there:
 > a. Windows (hopefully we can soon ignore Windows 9x)
 > b. *nix
 > And unless you have a lot of VC-capital, the only
 > combination where you can make money within a year
 > or so is "client software" on "windows".

I don't agree. My customers pay me to develop server
software on *nix, where the clients just happen to be Linux
boxes but might just as well be windows boxes, for all I
care. And I'm paid pretty well actually.

I am not using only O'Caml. As I am developing a data
centric application, I use SQL and XML tools extensively.
Presently, PXP is a very strong XML parser, but it lacks
support for XSLT (XSchema would be nice, too), so I am
forced to go with Xalan of the Apache foundation.

The bottom line is: 1) you don't need to develop Windows
software to make money, and 2) you'd better focus on writing
high quality code with high quality software development tools.

BTW, I'd gladly give up XSLT and SQL if, respectively, we
had a pseudo-official XML transformation API for Ocaml, and
there were Caml server-side bindings with PostgreSQL. In the
first place, I'd be able to statically typecheck my XML
transformation code. In the second place, I'd be able to
write type safe queries in such complex contexts where
baseline SQL is insufficent and the generality of pl/pgSQL
is needed.


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: