Re: When functional languages can be accepted by industry?

From: Chris Tilt (cet@webcriteria.com)
Date: Mon Apr 24 2000 - 04:36:43 MET DST

  • Next message: Xavier Leroy: "Objective Caml 3.00 released"

    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 <mottl@miss.wu-wien.ac.at> 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 <Xavier.Leroy@inria.fr> 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/pub/old_caml_site). 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.



    This archive was generated by hypermail 2b29 : Tue Apr 25 2000 - 19:10:09 MET DST