Re: When functional languages can be accepted by industry?

[Julian Assange <proff@iq.org>]

"T. Kurt Bond" <tkb@tkb.mpl.com> writes:

> Note that what I am about to say is *not* intended as a criticism of
> OCaml; I use OCaml every day, and enjoy using it.
> 
> Jean-Christophe Filliatre writes:
> > > 1. Current functional languages do not have enough library support:
> > 
> > Please. ocaml has  the most wonderful standard library  that any other
> > language  has ever had.  Have a  look in  the reference  manual before
> > stating such non-sense.
> 
> As much as I enjoy using OCaml, I think that this may be overstating
> the case.  OCaml has a very good standard library that is very well
> documented; however, it does not have everything.  Just a few examples
> of things that are missing from the standard library:
> 
> * Parsing and manipulating RFC 822 mail headers
> * Parsing and manipulating MIME documents
> * Parsing and downloading URLs
> * A FTP client
> * An HTTP Server
> * An HTTP Client
> * An IMAP Client
> * An SMTP Client
> * A POP Client
> * A NNTP Client
> * A Telnet Client
> * Parsing, manipulating, and generating HTML
> * Parsing, manipulating, and generating SGML
> * Audio data creation and manipulation
> * Image data creation and manipulation
> * High-level file operations (copy file, copy directory tree, 
>   delete directory tree)

If these things ever end up in the standard library, I will pack my bags and
go home.

If you read the links of The Hump, you will see that there are indeed
libraries to do most of these things in ocaml. The problem is that The
Hump is poorly organised, and the 3rd party library code is often
poorly documented. A lot could be done to mitigate this situation, by
making the 3rd party libraries look much closer to caml.inria.fr, than
the brief reference we see on The Hump. python.org's indexing of 3rd
party libraries is an excellent example of this. 

That said, one excellent catalytic change, would be to bring in
seperate compilation library version dependency analysis (i.e an ocaml
3rd party package manager) into the main ocaml distribution. I believe
there is an ocaml package to do this already, although I'm not sure
how sound it is.

As the number of inter-dependent ocaml packages increases, I'm
increasingly hit by version conflicts.

A library calculus system which was URL name space aware would be
particularly interesting. NetBSD and FreeBSD take this approach in
their own package source dependency system for instance. Compiling one
package recursively pulls in, uncompresses, patches, compilies and
installs the dependencies.

Such technology strongly fosters co-operative community.