From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA18536 for caml-redist; Tue, 25 Apr 2000 19:08:21 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA10164 for ; Tue, 25 Apr 2000 13:23:26 +0200 (MET DST) Received: from mail.rdc1.wa.home.com (ha1.rdc1.wa.home.com [24.0.2.66]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id NAA16337; Tue, 25 Apr 2000 13:22:47 +0200 (MET DST) Received: from webcriteria.com ([24.7.138.216]) by mail.rdc1.wa.home.com (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <20000424023502.BJCT2606.mail.rdc1.wa.home.com@webcriteria.com>; Sun, 23 Apr 2000 19:35:02 -0700 Message-ID: <3903B33B.C30F7E5D@webcriteria.com> Date: Sun, 23 Apr 2000 19:36:43 -0700 From: Chris Tilt Organization: WebCriteria, Portland, OR X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: John Prevost CC: Markus Mottl , Julian Assange , OCAML , Xavier Leroy Subject: Re: When functional languages can be accepted by industry? References: <200004171506.RAA11695@miss.wu-wien.ac.at> <87wvlwjydi.fsf@isil.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: weis Ok, if I may please add my rambling thoughts. XL posted a reponse from myself regarding our industrial success with CAML. In fact, I am thrilled with the core language and user/supplier community. With respect, my wish list is as such: 1. consistent expressiveness in .mli files as .ml files for functors 2. agreed upon/blessed modules (library?) format 3. work bench (IDE) tool On 1, I was stumped until MM showed me a trick for using .ml files as interface files with functors. However, it is tricky and difficult to document. I understand that there are problems with functors over interfaces, but I emplore the authors to find a compromise. This would facilitate larger projects and code reuse. On 2, the included note describes this problem very well. I will please request that we adopt some standard; I will happily code to it and share my miserable functorized graph theory module. On 3, I have always used emacs. It is great for one developer. However, we are also spoiled by Visual Age for Java (from IBM), which uses the old Envy database from SmallTalkV and is brilliant. We love this IDE because it supports excellent team programming. I can not (sadly) convince others in my office to use emacs on their WinNT/Win2000 computers. I understand their position. Also, I know it is very difficult to produce an IDE for a language as a research work. It is not so interesting, but a lot of work. However, perhaps someone could develop a model of team development for ML as a research project. VA for Java has a clear model that I think is far superior to other Java tools. It is the OO development paradigm and Envy that make it so powerful. There is probably such a model for our functional languages (sorry if it's obvious and I just don't see it). I will do whatever I can to support such development. Has there already been a thread of discussion on the topic of development model that I can study? Thank you all very much for this excellent language and discussion group. Best regards, Chris Tilt John Prevost wrote: > > >>>>> "mm" == Markus Mottl writes: > > mm> There are certainly a few "social" technologies that could > mm> significantly boost the usability of OCaml in real-world > mm> projects, a good version management tool for third party > mm> sources probably ranking among the "most missing" ones. > {...} > mm> Taking a look at the Hump and Gerd's link database, I have the > mm> impression that there is already enough "critical mass" of > mm> contributors, but most of the contributions are > mm> "one-man-efforts", i.e. nice, but they don't have enough > mm> "punch". Maybe we should really think more about ways to > mm> "unleash the forces of cooperative development". As it seems: > mm> easily said, difficult to do... > > I agree that this is the most significant "hump" in the way of O'Caml > at the moment. Whenever I become enthused about working on a major > interesting project in O'Caml, I first start looking at what other > people have done. I go to the hump, and the link database. There, I > discover that I could perhaps reuse code from three other people. > > But what's this?--one of them uses findlib, one of them has a Makefile > they rolled by hand (which is broken), and one of them just gives you > source code, no library at all. > > So I sort of sit there and stare at these three useful libraries, > thinking about how I can build my system/library in such a way that > it'll work with all three, and... it's just a mess. I eventually > sort of roll over and take a big sigh, then leave to do something > else. > > Needless to say, I don't get much code written. > > Perl has it's problems, and the quality of modules varies > immensely--but when I find a module, I can install it and try it out > in about 20 seconds. That lets me get on to the more important > problems of writing code. > > While this sort of thing might, by a number of arguments, not be the > sort of thing that should be considered part of the "core language", > I'd like to argue that such an official blessing would be enough to > get people to start using the tools consistantly, rather than > everybody doing things their own way. And it's only when everybody's > working in approximately the same way that this kind of simplicity of > working with third-party modules becomes possible. > > >>>>> "xl" == Xavier Leroy writes: > > xl> In OCaml, you have excellent I/O (better than Java's in my > xl> opinion) in the standard library, TK and GTK bindings for > xl> GUIs, and a couple of bindings to existing database libraries > xl> (see the Caml hump at http://caml.inria.fr). I agree the > xl> database stuff needs more work and the GUI stuff needs more > xl> documentation, but it's a start. > > Mmm. I actually have one minor gripe about the I/O stuff--not being > able to turn a set of functions into an in_channel or out_channel has > bit me a number of times. It's not so bad, until you want to do > something like implement an encrypting network stream and then use > stuff from Printf to write to it. > > (This could also simplify the code somewhat, since things like bprintf > and sprintf could be written in terms of such a primitive. This would > probably lose some speed, though.) > > xl> I certainly can't disagree with you. The main problem here is > xl> human resources. But we are looking at ways for big > xl> industrial users to help fund that kind of developments. > > I think that if you took something like, say, Findlib, and asked if > you could integrate it into O'Caml, you'd discover at least a few > people who would make time to go over things looking for issues and > warts to clean up. It's hard to be enthused if it's not going to be > "official". > > Even though I've been waiting for a good solution for consistent > handling of third party modules almost as long as I've been using > O'Caml, the fact that only a few people use findlib cuts down on its > usefulness to me. If Findlib were accepted into O'Caml, I would go > out of my way to send findlibifying patches to authors of various > packages, instead of just getting depressed. > > John.