Browse thread
When functional languages can be accepted by industry?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Julian Assange <proff@i...> |
| Subject: | Re: When functional languages can be accepted by industry? |
"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.