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
Hash clash in polymorphic variants
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-01-15 (19:20)
From: Gerd Stolpmann <info@g...>
Subject: Re: [Caml-list] Re: Hash clash in polymorphic variants
Jon Harrop wrote:
> Incidentally, Xavier made a statement based upon what appears to me to be a 
> similar logical error in the CUFP notes from last year that I read recently:
>   "On the other hand, certain features seem somewhat unsurprisingly to be 
> unimportant to industrial users. GUI toolkits are not an issue, because GUIs 
> tend to be built using more mainstream tools; it seems that different 
> competencies are involved in Caml and GUI development and companies "don't 
> want to squander their precious Caml expertise aligning pixels". Rich 
> libraries don't seem to matter in general; presumably companies are happy to 
> develop these in-house. And no-one wants yet another IDE; the applications of 
> interest are usually built using a variety of languages and tools anyway, so 
> consistency of development environment is a lost cause."
> - (page 3)

An interesting thesis, right? Although I wouldn't get that far, there is
some truth in it. The point, IMHO, is that OCaml will never replace
other languages in the sense that a company who uses language X for
years in product Y rewrites the code in OCaml. For what reason? The
company would run into big educational problems (learning a new
environment), would have high initial costs, and it is questionable
whether the result is better. Of course, for rewriting existing software
the company would profit from GUIs, from rich libraries etc. But I think
this does not happen.

What I see, however, is that OCaml is used where new software is
developed, in ambitious projects that start from scratch. It is simply a
fact that GUIs are not crucial in these areas (at least for the
companies I know). GUIs are seen as standard tools where nothing new
happens where OCaml could shine. If you need one, you develop it in one
of the mainstream languages.

IDEs aren't interesting right now because OCaml is mainly used by
(computer & related) scientists (and I include scientists working for
companies outside academia). IDEs are nice for beginners and for people
who do not want to know what's happening inside. They are not
interesting for companies that invent completely new types of products,
because they've hired experts that can live without (and want to live

> Xavier appears to have taken the biased sample of industrialists who already 
> use OCaml despite its limitations and has drawn the conclusion that these 
> limitations are not important to industrialists. I was really horrified to 
> see this because, in my experience, companies are turning away from OCaml in 
> droves because of exactly the limitations Xavier enumerated and I for one 
> would dearly love to see them fixed.

Which companies?

I fully understand that OCaml is not well-suited for the average
company. But it is not because of missing GUIs and IDEs, but because the
language itself is too ambitious. Sorry to say that, but this is not the
mainstream and it will never be.

(I have a good friend who works for an average company, so I know what
I'm talking of. They program business apps for a commercial platform
from CA. A horrible language, but they can manage it. They are experts
for the models they use, and simply take a platform from industry.)

> OCaml will continue to go from strength to strength regardless but its uptake 
> would be vastly faster if these problems are addressed. To take them point by 
> point:
> . GUIs are incredibly important (LablGTK is the world's favorite OCaml 
> library!) and tens of thousands of OCaml programmers are crying out for 
> proper LablGTK documentation as a first priority, many of whom are in 
> industry.

See this as opportunity for your next book :-)

GTK is already poorly documented, so this is not only the problem of the
LablGTK creators. Nevertheless, GTK is widely used. I don't think it's a
real problem.

> . Rich libraries are incredibly important and OCaml has the potential to 
> become a hugely successful commercial platform where people can buy and sell 
> cross-platform libraries but OCaml needs support for shared run-time DLLs (or 
> something equivalent) this before this can happen.

Do you dream or what?

I don't think that selling libraries in binary form is that important...
It is difficult anyway to do that, and why do you expect you could be
successful in a niche language? As customer I would demand to get the
source code - to lower the risks of the investment into a small

> . An easy-to-use IDE would be an excellent way to kick-start people learning 
> OCaml even if an industrial-strength IDE is intractable.
> > Also, one might want to make code generation automatic, particularly
> > for C wrappers, to allow adding cases to functions easily. This should
> > be doable, but there is no infrastructure for that currently
> > (using CPP macros was simpler to start with...)
> Yes. A better FFI could also be enormously beneficial. Improving upon OCaml's 
> FFI is one of the most alluring aspects of a reimplementation on LLVM, IMHO.

A general question to you: When you are complaining about so many
aspects of OCaml, why don't you invest time & money to fix them? We
would all be very thankful.

Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany
Phone: +49-6151-153855                  Fax: +49-6151-997714