From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id F314F7F168 for ; Fri, 28 Aug 2015 15:24:16 +0200 (CEST) IronPort-PHdr: 9a23:vSl9ehOBKTHez7i6pl4l6mtUPXoX/o7sNwtQ0KIMzox0KPv8rarrMEGX3/hxlliBBdydsKIfzbeH+4nbGkU+or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkItf6KuStWU0pX//tvx0qOQSj0AvCC6b7J2IUf+hiTqne5Sv7FfLL0swADCuHpCdrce72ppIVWOg0S0vZ/or9ZLuh5dsPM59sNGTb6yP+FhFeQZX3waNDUE49HisFHpRBGJ4WpUBnQRjhNNCQHf6hbrdpj0uyr+8OF63X/JE9fxSOUMWTWm7r9zRVfWhS0KLXZt6GHWjs1olK8dvh+rqgZXzIvdYYXTP/17KPCONegGTHZMC54CHxdKBZmxOs5WV7IM Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=philippe.veber@gmail.com; spf=Pass smtp.mailfrom=philippe.veber@gmail.com; spf=None smtp.helo=postmaster@mail-wi0-f196.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of philippe.veber@gmail.com) identity=pra; client-ip=209.85.212.196; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="philippe.veber@gmail.com"; x-sender="philippe.veber@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of philippe.veber@gmail.com designates 209.85.212.196 as permitted sender) identity=mailfrom; client-ip=209.85.212.196; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="philippe.veber@gmail.com"; x-sender="philippe.veber@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wi0-f196.google.com) identity=helo; client-ip=209.85.212.196; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="philippe.veber@gmail.com"; x-sender="postmaster@mail-wi0-f196.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DLAgCGYOBVlMTUVdFeg29pBoMdujKCLIUxSgKBMwc8EAEBAQEBAQEBEAEBAQEHCwsJHzCCHYIGAQEBAwESER0BGx0BAwELBgULDSoCAiEBAREBBQEcBhMIDA6HdgEDCggNoXmBLz4xi0CBbIJ5iggKGScNVoRHAQEBBwEBAQEBFwEFDoZfg3KBA4JPgVNpB4JpgUMFlT2FBoYAgW2CEJEYhW8SI4EXEQaCHhyBVjwzAQEBgkoBAQE X-IPAS-Result: A0DLAgCGYOBVlMTUVdFeg29pBoMdujKCLIUxSgKBMwc8EAEBAQEBAQEBEAEBAQEHCwsJHzCCHYIGAQEBAwESER0BGx0BAwELBgULDSoCAiEBAREBBQEcBhMIDA6HdgEDCggNoXmBLz4xi0CBbIJ5iggKGScNVoRHAQEBBwEBAQEBFwEFDoZfg3KBA4JPgVNpB4JpgUMFlT2FBoYAgW2CEJEYhW8SI4EXEQaCHhyBVjwzAQEBgkoBAQE X-IronPort-AV: E=Sophos;i="5.17,424,1437429600"; d="scan'208";a="175198457" Received: from mail-wi0-f196.google.com ([209.85.212.196]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 28 Aug 2015 15:24:16 +0200 Received: by wiyy7 with SMTP id y7so3578821wiy.0 for ; Fri, 28 Aug 2015 06:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=x1oRdPqbP/8rwAUlvG0QnQVSvcadV80zPSWPXUz+p1E=; b=zlzw2jodf108IuZccK03Hb6vd+0sgBQ7tM70tp5Ze2NPzicoEftoYYKGBAbxBOLN2z kCmNPc0Q+z79gcG3AAY78VOwEZobXXM5/+T84IKJVbLKCbLbCIq+T/Afb7j6S2JN1kuc A8XYSvtE+QaDs0aN9iYtSW1dXMWKtI3MTnjwnw6vCJFlyGCxlW25YkfoooWFECl0SE5A klusc+vovLhd4q5r4vO0/Kha+4LhjHysHm4K7YYF7kNfVp/ksDpN5uwaSow6iyxZ+tje 59DkVB+l+S4v/s45BFXY41dnpjL70CjGc0gEGn8MsFs5znkMXhmKinvMM7OGCqLWJwQK e7FA== X-Received: by 10.180.211.41 with SMTP id mz9mr4658555wic.5.1440768255731; Fri, 28 Aug 2015 06:24:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.214.82 with HTTP; Fri, 28 Aug 2015 06:23:56 -0700 (PDT) In-Reply-To: References: <1C02B1E2-D17D-4008-998E-B17048C62DFA@gmail.com> <55DEE7E5.1020104@inria.fr> From: Philippe Veber Date: Fri, 28 Aug 2015 15:23:56 +0200 Message-ID: To: Yotam Barnoy Cc: Ocaml Mailing List Content-Type: multipart/alternative; boundary=001a11c37b8c162fab051e5f0026 X-Validation-by: philippe.veber@gmail.com Subject: Re: [Caml-list] We need a rich standard library distributed with OCaml, really --001a11c37b8c162fab051e5f0026 Content-Type: text/plain; charset=UTF-8 > > > 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 >> > > --001a11c37b8c162fab051e5f0026 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Wha= t seems to me better than a built-in standard library, though, is a referen= ce 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 a= rea would already be great. The OPAM repo has a search functionality which = is already helpful for that. Having a more systematic and principled [1] us= e of the "tag" field could help too.
=C2=A0
Such= a reference could include space for the community to debate the pros and c= ons of various libraries, and perhaps even a voting system to indicate to p= otential users what the community thinks about said libraries. This is some= thing I currently have trouble with in opam, since I have no idea if a give= n 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 cl= osest 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 popular= ity of a library is the number of reverse dependencies. This is something t= hat can be checked on the OPAM repository (see [0] for instance). I guess h= aving this information summarized in a table=C2=A0 (possibly filtered with = tags) could already give a hint.
[1] I mean choosing tags= from a controlled vocabulary.

=C2=A0

-Yotam

On Thu, Aug 27, 2015 at 3:55 PM, Martin DeMello <martin= demello@gmail.com> wrote:
On Thu, Aug 27, 2015 at 3:35 AM, Romain Bardou <r= omain.bardou@inria.fr> wrote:
I agree about smaller, independent packages. This is a very general API des= ign principle: avoid coupling (the fact that using a module implies using a= nother). This may be the main reason I avoid external libraries. For instan= ce, Martin Jambon's Yojson depends on biniou, cppo and easy-format. I b= elieve Martin is an awesome programmer but this particular point just baffl= es 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 integ= rate 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, i= ncluding 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 wh= ether 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 defin= itely 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


--001a11c37b8c162fab051e5f0026--