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, Jon Harrop wrote:
> On Tuesday 15 January 2008 19:20:09 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."
> > > - http://cufp.galois.com/CUFP-2007-Report.pdf (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.
>
> I believe many more companies would migrate to OCaml if it had
> well-documented GUI APIs and rich libraries. Indeed, Microsoft are gambling
> on people migrating to F# in exactly the same way.
>
> > 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).
>
> But the companies you know were already self-selected to be the ones who do
> not care about OCaml's limitations, so it is a biased sample?
>
> > GUIs are seen as standard tools where nothing new happens where OCaml
> > could shine.
>
> I have no doubt that OCaml would shine in GUIs just as it does elsewhere.
>
> > If you need one, you develop it in one of the mainstream languages.
>
> Actually I would either choose F# on Windows or give up on any other OS.
>
> > IDEs aren't interesting right now because OCaml is mainly used by
> > (computer & related) scientists (and I include scientists working for
> > companies outside academia).
>
> Many of the world's most sophisticated IDEs are targetted solely at
> technical users. Look at Mathematica's notebook interface, for example. I
> believe that is a great example to aspire to.
>
> > 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).
>
> I couldn't disagree more. Pharmaceuticals are a trillion dollar industry
> where many scientists would benefit enormously from being able to use a
> tool like OCaml without knowing anything about how it works in order to
> create their next generation products (drugs). The same is true of most
> industries where scientists and engineers work and there are many such
> industries and there are extremely profitable.
>
> > > 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?
>
> General Electric, Microsoft, Wolfram Research and various bioinformatics
> institutes for example.
>
> Look at General Electric. They build some of the world's most sophisticated
> medical scanners and that large-scale embedded market is ideal for using
> languages like OCaml for its high-performance numerics because you have
> complete control over the environment. However, they desperately need GUI
> toolkits to provide a front-end for users.
>
> I'd like to know what Alex Barretta makes of this, for example. His glass
> cutters must have the same characteristics in this respect...
>
> > 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 still think OCaml has the best chance of any FPL to become a mainstream
> tool in technical computing.
>
> Indeed, I recently tried to quantify how far OCaml has already come and I
> believe it is already as popular as C# among technical users, for example.
> That is quite an achievement!
>
> > (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.)
>
> Yes. I do not believe OCaml will make significant inroads into displacing
> COBOL and relatives but there are a lot of other big opportunities out
> there for such a language.
>
> > > 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 :-)
>
> Indeed. Even after the announcement that Microsoft are productizing F#,
> OCaml for Scientists continues to be our biggest earning product.
> Consequently, I am very tempted to write a "sequel" that covers many of the
> important aspects of the language that I did not cover in the original,
> including GUI programming, XML, parallelism and so forth. If anyone has
> ideas for subjects they would like to see covered, please e-mail me!
>
> > 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.
>
> Yes. I'm really not sure what the best course of action would be here.
> Would Qt bindings be preferable? Is it worth the hassle? How long would it
> be before they reached the maturity of GTK?

Making bindings for Qt is basically putting a beautiful architecture to waste.
Qt's architecture is good enough to be actually machine-translated into OCaml. 
This would be an involved project, but not impossible.

Using Qt from OCaml via a set of bindings can be a short-term stop-gap measure 
for trivial applications, I would never deploy a Qt application written in 
OCaml if the application was any bigger on the GUI side than a couple simple 
dialog boxes. There is a binding generator (forgot its name) which can 
generate OCaml bindings for Qt, but you have to give it a list of 
classes/methods/signals/slots to generate bindings for. So perfect for 
trivial applications, but not much else.

Qt, when you start to think of its API in how it may look in OCaml, becomes 
pretty cool, and I'm sure there are a few improvements to it you can make to 
leverage the power given to you by OCaml, once you loose the shackles of C++. 

Cheers, Kuba