From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id E2357BC69 for ; Wed, 26 Sep 2007 20:17:24 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAPs++kbAXQImh2dsb2JhbACOLwEBAQgKJw X-IronPort-AV: E=Sophos;i="4.21,198,1188770400"; d="scan'208";a="1833631" Received: from discorde.inria.fr ([192.93.2.38]) by mail2-smtp-roc.national.inria.fr with ESMTP; 26 Sep 2007 20:17:24 +0200 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l8QIHJiX009305 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 26 Sep 2007 20:17:24 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAPs++kbDuhM9nmdsb2JhbACOLwEBAQEHBAYFChg X-IronPort-AV: E=Sophos;i="4.21,198,1188770400"; d="scan'208";a="1833629" Received: from mail12.bluewin.ch ([195.186.19.61]) by mail2-smtp-roc.national.inria.fr with ESMTP; 26 Sep 2007 20:17:24 +0200 Received: from [192.168.1.58] (85.0.110.234) by mail12.bluewin.ch (Bluewin 7.3.121) id 46F37EFC0011D4C8 for caml-list@inria.fr; Wed, 26 Sep 2007 18:17:23 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <46F95938.7030107@cs.umd.edu> <17487E59-04F2-4509-87B5-24377B051E9E@epfl.ch> <46F961E5.5060302@cs.umd.edu> <55A4E82E-3D05-4F79-A8A6-A87905EB4FC8@epfl.ch> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Subject: Re: Cherry-picking modules (was Re: [Caml-list] [ANN] OCaml Reins 0.1 - Persistent Data Structure Library) Date: Wed, 26 Sep 2007 20:17:26 +0200 To: caml-list List X-Mailer: Apple Mail (2.752.2) X-Miltered: at discorde with ID 46FAA22F.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bunzli:01 buenzli:01 ocaml:01 re-use:01 bazar:01 camomile:01 coupling:01 trade-off:01 orphaned:01 ocaml:01 strive:98 kid:98 blessing:98 caml-list:01 semantic:02 Le 26 sept. 07 =E0 17:32, Michael Furr a =E9crit : >> I think developers of reusable components should try to strive for =20= >> *focused*, independent modules, even if it means functorization =20 >> and convention. Eventually it makes it easier for developers to =20 >> integrate these modules and exchange specific parts if some module =20= >> poses a problem or better alternatives popup. > > But you should start by raising the bar for re-use, not lowering it. I don't know how I should interpret this (I don't understand the =20 meaning). For me the bar is too high for sharing. We need more lightweight ways =20= of doing so, let the real bazar be and eventually good components =20 will be selected. Maybe if there had been a convenient, agreed bupon, =20= module-based, *localized* (in the sense not system wide) and =20 distributed package system you wouldn't be the the xth person to =20 implement avl trees. For example go look into Camomile there's an =20 implementation there. But I agree with you tight coupling can also be beneficial, it's a =20 trade-off. However maybe (I don't know) reins could have been split =20 w.r.t to the different kind of semantic data structure (set, list, =20 map). It depends on the deal of code sharing that actually occurs =20 between them. The unit tests could have been done as a separate =20 project that requires these smaller packages. etc. I strongly believe =20= that smaller components are more manageable in the long term. Because =20= whenever they break or become orphaned it becomes easier for third-=20 parties to understand them and maintain them alive. But hey, I don't want to look like I'm grumling about reins, it sure =20 looks great and usefull. So I think I better stop this discussion here. Le 26 sept. 07 =E0 18:42, Sylvain Le Gall a =E9crit : > It is really strange, everyone seems to look at OCaml as "languages =20= > for > kid" with everything bundle into some kind of nice package... =20 > Please be > more realistic, OCaml is a complicated language -- design for > "discriminative hackers". I don't see any reason why complexity should be introduced for the =20 sake of it. I like simple, elegant, bar-bones, solutions, that's why =20 I like ocaml and I don't think it is a complicated language. I'm =20 interested in developing applications not fiddle around with build =20 and package management systems -- and as such ocamlbuild is a blessing. Best, Daniel