From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 18161BC69 for ; Tue, 15 Jan 2008 23:12:00 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4HAPe+jEfUnw7UhWdsb2JhbACCNo1VAQEBCAQGDxMHgRQBmis X-IronPort-AV: E=Sophos;i="4.24,290,1196636400"; d="scan'208";a="6090029" Received: from ptb-relay01.plus.net ([212.159.14.212]) by mail2-smtp-roc.national.inria.fr with ESMTP; 15 Jan 2008 23:11:59 +0100 Received: from [80.229.56.224] (helo=beast.local) by ptb-relay01.plus.net with esmtp (Exim) id 1JEu0k-0002xW-5a; Tue, 15 Jan 2008 22:11:58 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: Gerd Stolpmann Subject: Re: [Caml-list] Re: Hash clash in polymorphic variants Date: Tue, 15 Jan 2008 22:04:45 +0000 User-Agent: KMail/1.9.7 Cc: caml-list@yquem.inria.fr References: <200801140956.25449.ober.14@osu.edu> <200801151817.33017.jon@ffconsultancy.com> <1200424809.2564.95.camel@flake.lan.gerd-stolpmann.de> In-Reply-To: <1200424809.2564.95.camel@flake.lan.gerd-stolpmann.de> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200801152204.45376.jon@ffconsultancy.com> X-Spam: no; 0.00; hash:01 variants:01 gerd:01 stolpmann:01 guis:01 ocaml:01 rewrites:01 ocaml:01 rewriting:01 guis:01 ocaml's:01 vastly:01 lablgtk:01 lablgtk:01 parallelism:01 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