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
