I'm concerned that this dramatically underrates the importance of
having some kind of specification for a library (or any software).
A project that emerges through gung-ho programming alone is likely
to be incomprehensible to other programmers who may want to
contribute (and probably to the author, a few months later).
Maybe this is my own preference showing (I always try to work out a
spec and a formal semantics first), but I think that even an informal
and protean specification is beter than no specification at all. To
paraphrase Conal Elliott, I'd like these libraries to be precise about
'what', not just 'how'.
I too often start solving a problem by writing a draft spec, and find
that it clarifies thinking a lot. But there are situations where it
doesn't make sense. Sometimes it's better to just get something out the
door. This tends to be the case when the problem is either really well
understood (i.e. the spec is obvious), or really poorly understood (i.e.
no use writing a spec about guesses and stabs in the dark).
In terms of deliverables, if stable releases were to be cut from Scheme
Live at intervals, those releases should be defined by a spec document,
and ship with the code at that point in time as a sample implementation
of the spec. (I.e. just like SRFI in this respect, but probably without
the rationale sections, unless someone is keen to write them.)
The question then is how to arrive at this document. It will be just a
file in version control, so in principle nothing stops people from
editing that file whenever they like. If you like to go spec first, you
could edit the doc first until you're happy with it, and then write the
code. Someone who prefers to implement first could do that.
IMHO the right approach would be informally discovering a process that
works for the participants. If only one person works on HTML parsing for
example, and that person likes implementing first, then they should work
on those parts that way. Otherwise we'd have no HTML parsing library,
which IMO is a bigger loss. If we have a parsing library that sucks but
gets the job done, can always fix it later, keeping in mind that the
process if tolerant of mistakes.
Related to comprehensibility is the issue of the monorepo. What's
the advantage of this approach? I second John's point about the
difficulty of cleanly extracting subtrees; this is especially a
problem if any (sub)library were to become a SRFI. Committing and
testing a monorepo seem likely to become very time-expensive, as well.
Why not multiple repos, perhaps with Git submodules?
The main point of a monorepo is that changing module boundaries becomes
easy. Another point is to get people invested in the whole, avoiding a
situation where everyone picks their favorite parts and doesn't run the
rest. This approach ensures that a cohesive whole eventually emerges,
not only a self-assembly kit of good parts.
For testing the whole collection, CI is a big help. When programming
locally, the test runner should let people run only parts of the full
test suite.
Not sure what you mean by committing being slow; git isn't slow with the
kinds of repo sizes we'd be likely to hit. Echoing many people's
experience with git submodules, I'd have to say "now you have two problems".
In summary, I'd like a Scheme Live library collection to be clear,
well-defined, and easy to work with. A large monorepo of unspecified
in-progress libraries sounds like the opposite.
That would be everyone's goal, but we may disagree on how to get there.
We may only disagree in degree, not in kind.
