I'd like to mention the merits of not having a large standard library. Consider the evolution of OCaml. Many of the paradigms with which OCaml was born, such as using exceptions everywhere, have gone out of favor. Hopefully, sometime in the near future, we'll have Modular Implicits integrated into the language. Assuming this happens, it will almost certainly impact what would be expected to belong in a standard library. The official standard library already carries around with it vestigial organs, such as the Stream module. This will only get worse if we add to it.

At the same time, I recognize a need for a library to represent a large collection of data types and the functions over said types. It cannot all be miniature libraries in opam IMO -- for basic programming, there should be a curated source of basic and even some extended functionality.

What seems to me better than a built-in standard library, though, is a reference to the best currently available libraries in each area, including a 'standard' collection of utilities/data structures. Such a reference could include space for the community to debate the pros and cons of various libraries, and perhaps even a voting system to indicate to potential users what the community thinks about said libraries. This is something I currently have trouble with in opam, since I have no idea if a given library is a) ancient and unmaintained b) the best in its class c) rising in popularity d) written by a pro and solid, even if not used much. The closest I have to that in opam is number of downloads, but given how much the ecosystem now relies on opam, I think a more advanced display is needed.

-Yotam

On Thu, Aug 27, 2015 at 3:55 PM, Martin DeMello <martindemello@gmail.com> wrote:

On Thu, Aug 27, 2015 at 3:35 AM, Romain Bardou <romain.bardou@inria.fr> wrote:

I agree about smaller, independent packages. This is a very general API design principle: avoid coupling (the fact that using a module implies using another). This may be the main reason I avoid external libraries. For instance, Martin Jambon's Yojson depends on biniou, cppo and easy-format. I believe Martin is an awesome programmer but this particular point just baffles me as there is absolutely no need for *any* external dependency to solve such a simple problem (JSON parsing, pretty-printing and AST constructors). I understand that Martin wants to reuse its own code and be able to integrate Yojson easily with other libraries of his, and that is great. For him and users of his other libraries. Not for those who just want a JSON parser and have had to install all dependencies manually on Windows.

Part of the promise of an ecosystem of small libraries is that you should be able to use them for any code you write, including other libraries. This is not the same thing as API coupling; as an end user of library C you should be able to use it without caring about whether it is self-contained in terms of code or whether it uses libraries A and B internally. The fact that dependencies need to be installed manually on windows is a failure of the ocaml windows ecosystem (which I'm definitely sympathetic towards; I once had to manually copy a bunch of code from batteries into my own project just to avoid depending on it); it is not a sign that libraries need not to depend on each other.

martin