Version française
Home     About     Download     Resources     Contact us    
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: -- (:)
From: Kuba Ober <ober.14@o...>
Subject: Re: [Caml-list] Re: Hash clash in polymorphic variants
On Tuesday 15 January 2008, Gerd Stolpmann wrote:
> 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
> without).
> > 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
> platform.

Yeah, I wouldn't be using Qt if there was no source code for it. Quite a few 
times over the years I had to tweak away at the implementation details.

In fact, I would never specify *any* mission-critical libraries or frameworks 
if they didn't come with full sources.

Cheers, Kuba