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.4 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE autolearn=disabled version=3.1.3 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 08709BC69 for ; Wed, 16 Jan 2008 14:48:17 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0KABqajUdDWxLC/2dsb2JhbACBWKw/ X-IronPort-AV: E=Sophos;i="4.24,293,1196636400"; d="scan'208";a="6739340" Received: from ip67-91-18-194.z18-91-67.customer.algx.net (HELO server1.bertec.net) ([67.91.18.194]) by mail1-smtp-roc.national.inria.fr with ESMTP; 16 Jan 2008 14:48:16 +0100 Received: from kuba.bertec.net (kuba.bertec.net [192.168.2.16]) by server1.bertec.net (Postfix) with ESMTP id 06571CDFE8 for ; Wed, 16 Jan 2008 08:48:15 -0500 (EST) From: Kuba Ober To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: Hash clash in polymorphic variants Date: Wed, 16 Jan 2008 08:48:14 -0500 User-Agent: KMail/1.9.6 (enterprise 0.20071123.740460) References: <200801140956.25449.ober.14@osu.edu> <1200424809.2564.95.camel@flake.lan.gerd-stolpmann.de> <200801152204.45376.jon@ffconsultancy.com> In-Reply-To: <200801152204.45376.jon@ffconsultancy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801160848.14280.ober.14@osu.edu> 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 bindings:01 cheers:01 in-house:98 richest:98 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. In fact, after some initial thinking and looking around it seems that the only "sane" GUI for OCaml, at this time, is Qt, but someone has to write a machine translator to port it from C++ to OCaml. Qt is reasonably well designed, and has the richest feature set of all GUI toolkits, even if you combined all the competition and treated it as one "other" toolkit. Using Qt with some machine (or not!) generated bindings is just a huge waste -- it's a nice, clean design, which has recently been tweaked for performance (some Qt4 apps start in 50% of the time just by having been ported to Qt4 from Qt3). Cheers, Kuba