Re: Spec vs code, user-driven vs designer-driven Lassi Kortela 01 May 2021 16:30 UTC
Thanks for the thoughtful reply! > Yes, it is, isn't it. Fortunately, I take a rather relaxed attitude to > received wisdom (which is also big on static types, TDD, and other > things I don't do much). > > Specs are wonderful, but they should be > produced iteratively with users in the loop. With no field testing > before finalization, > > Hardly my fault. The point of the pre-finalization process is to give > people the opportunity to do functional testing. > > the process is uncomfortably waterfall-like. This > is an argument that several experienced schemers have made about > current > SRFI practice. > > They are of course free to write their own SRFIs however they wish to. > > I do use the SRFIs I wrote, and while I think they turned out okay I'm > not satisfied with the process of how they were made and the fact that > changes can't be made to them anymore. I know what you mean, but our people don't have the requisite energy to do the above things. People don't use these opportunities because the rigor of the SRFI (and especially RnRS) process is mentally exhausting given the scope of the work that we are doing. The only way out is to use a less rigorous process. One where: - procedures can be added as needed instead of one library at a time - libraries are not finalized on a timetable - there is a routine, low-friction way to correct design mistakes - there is more collective ownership and less individual responsibility - speculative work can be committed and retracted after a few months SRFI as currently practiced can accommodate all of the above things, but all of them are demoralizing to do in the context of SRFI, and doubly so in the context of RnRS. > Scheme Live would fix these problems. Any given individual doesn't need > to have time for everything if it's a group effort. The beauty of the > approach is that the spec and code writers are also the main users. > > Except those are different skills and not everyone has all of them. > "Scratch your own itch" is fine in theory (SRFI 179 is a good example) > but not always feasible in practice. In a less rigorous design process individuals can still serve different roles if they like. It's still useful to write specs, perhaps even to start by writing a spec before there's any code. But to avoid exhaustion and stagnation due to perfectionism, most aspects of the process should be more lenient and flexible. > I still don't understand why you are so drawn to finalizing specs first > and then having other people implement and use them. > > I don't: that would indeed be a waterfall. I *write* specs and ask > other people to implement them and still other people to use them. They > aren't finalized until at least the implementation is written and > hopefully not until at least some early adopters have used them. But > early adoption is tricky: people tend to want to adopt only things that > already work, as they are afraid they'll have to undo what they've done. Fair enough. But if the users are not showing up, something is amiss. It may be a communication or trust problem, but social processes exist for the purpose of solving those, and our current processes, in the way that we currently use them, are not solving them. I believe the thing that's missing is collective ownership. You say that you intend all SRFIs and pre-SRFIs around R7RS-large to be collectively owned, and I have every reason to believe you. Yet in practice, people (and especially users) are not taking ownership very much. It seems to me that the most likely reason is the design processes are too rigorous for most schemers' available energy levels. I've seen several people mention in passing that they should write a SRFI, but due to lack of available time and energy, or due to the rigor expected from the specification, they haven't. There's a need that isn't being met. We can always publish libraries in Snow and Akku, but those don't enjoy any kind of official standing. The Lisp community has a 30-year record that shows what consistently happens when all libraries are available on a level playing field: cohesion at the language level keeps eluding. > What does that mean for those pre-SRFIs -- will they be up for grabs > for other people to continue the work and submit as SRFIs? > > Absolutely. And of course I expect the implementers to deviate from the > specs, hopefully discussing the changes with me (if I am still available). Good to hear that they will continue to be developed. You've put a lot of good work into them. We appreciate your continued presence, effort and expertise. > Scheme Live should have as a main goal that the libraries make one > whole. > > It sounds to me like you *want* them to converge, but I don't see how > you mean to get there. Coherence, like security, is hard to retrofit. Yes, that's right. I would try to get there by having everything open to change, but publishing yearly stable releases of the API. This would give a balance where anything can change in the cutting edge version if there's enough of a need, but at the same time, the existence of the stable versions and the common ownership would bring social pressure against changing things frivolously and too often. This is not perfect but I don't see a way to do better than this; alternative ideas are welcome. > Not sure I know this pain. Haven't found any fundamental problem with > it. There are better tools than `git filter-branch` now. > > > Tell me how, then. `git subtree` is now built in; https://github.com/newren/git-filter-repo is third-party but even better. Neither relies on submodules. > I think that separate ownership has led to separate repos. I have never > cared about ownership: on the contrary. You're probably right. It's good to have agreement on common ownership.