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

[Mike Furr <furr@cs.umd.edu>]

Daniel Bünzli wrote:
>> 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).

I only meant that we should strive to use the "right" solution, even if
that means a little more work for the time being since it will hopefully
improve things in the long run.

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

Its hard for me to conceptualize how such a distributed system would
work and so I can't really comment if it would in fact be a better
system.  However, one problem I wanted to tackle was that while I would
be the xth person to implement avl trees, there will be NO x+1th person.
   Reins is one (possible) solution to that.

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

Currently, the unit tests are just part of the build and are not
installed.  However, since they are parameterized, perhaps I should
distribute them as a second (optional) library so that anyone who
implements a data structure which matches the signatures there can use
them too.  Thanks for the idea.

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

As a counter point, smaller components may mean that fewer people are
interested in each component and thus are more likely to become orphaned
as individuals than as part of a larger collection.  I think your idea
is interesting, but I haven't seen any anecdotal evidence of it actually
being better than the "cathedral" approach.  Pointers/references to such
things would be welcome.

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

I don't think you are, and in fact, as library designer/maintainer its
great to get feedback on how people feel about the current status quo of
library management.  If someone were to build such a distributed
localized module collection, I would love to see the code from reins in
there.  In the time being, I think the cathedral approach should work
quite well.

Thanks for the dialogue... and now back to hacking.

-m