Re: Cherry-picking modules (was Re: [Caml-list] [ANN] OCaml Reins 0.1 - Persistent Data Structure Library)

["Daniel Bünzli" <daniel.buenzli@epfl.ch>]

Le 26 sept. 07 à 17:32, Michael Furr a écrit :

>> I think developers of reusable components should try to strive for  
>> *focused*, independent modules, even if it means functorization  
>> and convention. Eventually it makes it easier for developers to  
>> integrate these modules and exchange specific parts if some module  
>> 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  
meaning).

For me the bar is too high for sharing. We need more lightweight ways  
of doing so, let the real bazar be and eventually good components  
will be selected. Maybe if there had been a convenient, agreed bupon,  
module-based, *localized* (in the sense not system wide) and  
distributed package system you wouldn't be the the xth person to  
implement avl trees. For example go look into Camomile there's an  
implementation there.

But I agree with you tight coupling can also be beneficial, it's a  
trade-off. However maybe (I don't know) reins could have been split  
w.r.t to the different kind of semantic data structure (set, list,  
map). It depends on the deal of code sharing that actually occurs  
between them. The unit tests could have been done as a separate  
project that requires these smaller packages. etc. I strongly believe  
that smaller components are more manageable in the long term. Because  
whenever they break or become orphaned it becomes easier for third- 
parties to understand them and maintain them alive.

But hey, I don't want to look like I'm grumling about reins, it sure  
looks great and usefull. So I think I better stop this discussion here.

Le 26 sept. 07 à 18:42, Sylvain Le Gall a écrit :

> It is really strange, everyone seems to look at OCaml as "languages  
> for
> kid" with everything bundle into some kind of nice package...  
> 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  
sake of it. I like simple, elegant, bar-bones, solutions, that's why  
I like ocaml and I don't think it is a complicated language. I'm  
interested in developing applications not fiddle around with build  
and package management systems -- and as such ocamlbuild is a blessing.

Best,

Daniel