>>>>> "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 : Wed Apr 19 2000 - 14:31:08 MET DST