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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 64E0DBC6C for ; Fri, 18 Jan 2008 06:19:18 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FABrFj0dDWxLC/2dsb2JhbACBV5ASnB8 X-IronPort-AV: E=Sophos;i="4.25,214,1199660400"; d="scan'208";a="21459931" Received: from ip67-91-18-194.z18-91-67.customer.algx.net (HELO server1.bertec.net) ([67.91.18.194]) by mail4-smtp-sop.national.inria.fr with ESMTP; 18 Jan 2008 06:19:17 +0100 Received: from kuba.bertec.net (kuba.bertec.net [192.168.2.16]) by server1.bertec.net (Postfix) with ESMTP id 3D484CDF92 for ; Fri, 18 Jan 2008 00:19:16 -0500 (EST) From: Kuba Ober To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: Hash clash in polymorphic variants Date: Fri, 18 Jan 2008 00:19:15 -0500 User-Agent: KMail/1.9.6 (enterprise 0.20071204.744707) 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-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801180019.15434.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 vastly:01 lablgtk:01 lablgtk:01 gtk:01 gtk:01 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." > > - 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. > > 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