Le lun. 26 avr. 2021 à 08:45, Lassi Kortela <xxxxxx@lassi.io> a écrit :
>
> > 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).

I agree.

> > 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 better than no specification at all.  To
> > paraphrase Conal Elliott, I'd like these libraries to be precise about
> > 'what', not just 'how'.

I somewhat disagree. It is like Test Driven Development, do you write
all the tests first, then the code? It is not my case, I know tests
are useful, but while coding, especially something new with lots of
unknowns there is a conversation between tests, code, and
specification.

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

I somewhat agree.

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

Yes. Getting something out-of-the-door without documentation (and
examples) is almost useless nowadays.

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

I am not sure what is the difference between specification and
documentation in the scope of scheme-live?

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

+1

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

That will be the problem of the implementer. I take the case of JSON
parsing: without a light spec such as : need to stream parse JSON, you
end up with a much different implementation.

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

I agree. And I do not care much so far about git history.

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

--
Amirouche ~ https://hyper.dev