Re: [Caml-list] We need a rich standard library distributed with OCaml, really

[Philippe Veber <philippe.veber@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3294 bytes --]

>
>
> 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 <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
>>
>
>

[-- Attachment #2: Type: text/html, Size: 4752 bytes --]