> > > 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. > Actually, even getting to know the list of libraries in a given area would already be great. The OPAM repo has a search functionality which is already helpful for that. Having a more systematic and principled [1] use of the "tag" field could help too. > 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. > Another indicator of the popularity of a library is the number of reverse dependencies. This is something that can be checked on the OPAM repository (see [0] for instance). I guess having this information summarized in a table (possibly filtered with tags) could already give a hint. [0] http://opam.ocaml.org/packages/batteries/batteries.2.3.1/ [1] I mean choosing tags from a controlled vocabulary. > > -Yotam > > On Thu, Aug 27, 2015 at 3:55 PM, Martin DeMello > wrote: > >> On Thu, Aug 27, 2015 at 3:35 AM, Romain Bardou >> 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 >> > >