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: Jon Harrop <jon@f...>
Subject: Re: [Caml-list] Re: Hash clash in polymorphic variants
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?

I think we would really need more high-profile open source programs with 
hundreds of thousands of users testing the bindings (as GTK has had) before 
you could really gamble on it.

> > . 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?

One man's reality is another man's dream. :-)

> I don't think that selling libraries in binary form is that important...

If it were possible then it would be important to me because I could earn a 
living from it. I'm sure the same is true for many other people.

> It is difficult anyway to do that, and why do you expect you could be
> successful in a niche language?

Because I already am. :-)

> As customer I would demand to get the source code - to lower the risks of
> the investment into a small platform.

Nobody ever got fired for buying IBM.

Historically, we've made a lot more money from sales of binaries than from 
sales of source code. Consequently, I would be more than willing to gamble on 
selling shared run-time DLLs for OCaml users if it were possible.

> > 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?

An excellent idea!

So I wrote to Xavier Leroy and asked about contributing to INRIA's OCaml 
distribution. Xavier explained that French copyright law makes it 
prohibitively difficult for him to include my code contributions so this will 
never be possible. The best I could think of was to suggest that they make it 
possible for users to pay to get certain bugs fixed or functionality 
implemented. I'm not sure that will happen though.

I wrote to Pierre Weis and asked what the likelihood of getting some tweaks 
into the language was. He said that it is unlikely I could even get a "try .. 
finally" construct put in.

So there's no way I can improve INRIA's OCaml distribution. Next, I thought 
perhaps a complete fork of OCaml would be a viable alternative. This is 
complicated by OCaml's license which requires variants to be distributed with 
the core sources intact and everything else as patches to it. This is not an 
insurmountable problem, of course, you just distribute the core and a giant 
autogenerated patch instead. So I asked Sylvain about getting Debian to adopt 
the fork rather than INRIA's upstream. He said this will almost certainly not 
happen.

So I can't develop or contribute to INRIA's OCaml implementation and I can't 
fork it without starting with zero users. What about reimplementing it?

So I wondered what I could build upon that would make this as painless as 
possible. This led me to the Smoke VM, Mono, the JVM and LLVM. I enumerated 
each of these in turn and came to the conclusion that LLVM is preferable, not 
least because several other people had already drawn the same conclusion and 
started work on similar projects themselves.

That's when I wrote my 100LOC test program calling LLVM from OCaml. Since 
then, Gordon has been working hard on the OCaml bindings and example 
programs, which are now nothing short of incredible. Dozens of people have 
e-mailed me expressing their desire to contribute to such an effort.

This will take time, of course, but I believe it is the future of the OCaml 
language.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e