Email list hosting service & mailing list manager

Making SRFI go faster Lassi Kortela (25 Apr 2021 09:33 UTC)
Re: Making SRFI go faster Vladimir Nikishkin (25 Apr 2021 09:46 UTC)
Re: Making SRFI go faster Lassi Kortela (25 Apr 2021 09:57 UTC)
Re: Making SRFI go faster Amirouche Boubekki (25 Apr 2021 11:05 UTC)
Re: Making SRFI go faster Lassi Kortela (25 Apr 2021 11:14 UTC)
Re: Making SRFI go faster Marc Feeley (25 Apr 2021 12:01 UTC)
Re: Making SRFI go faster Lassi Kortela (25 Apr 2021 12:15 UTC)
Re: Making SRFI go faster Alex Shinn (26 Apr 2021 13:09 UTC)
Re: Making SRFI go faster Jakub T. Jankiewicz (26 Apr 2021 18:51 UTC)
Re: Making SRFI go faster Alex Shinn (27 Apr 2021 02:59 UTC)
Re: Making SRFI go faster Amirouche Boubekki (25 Apr 2021 10:47 UTC)
Re: Making SRFI go faster Lassi Kortela (25 Apr 2021 10:57 UTC)
Re: Making SRFI go faster Lassi Kortela (25 Apr 2021 11:04 UTC)
Re: Making SRFI go faster Adam Nelson (25 Apr 2021 21:00 UTC)
Re: Making SRFI go faster Lassi Kortela (25 Apr 2021 21:10 UTC)
Re: Making SRFI go faster Amirouche Boubekki (25 Apr 2021 11:34 UTC)
Re: Making SRFI go faster Lassi Kortela (25 Apr 2021 12:01 UTC)
Re: Making SRFI go faster Marc Nieper-Wißkirchen (25 Apr 2021 12:23 UTC)
R6RS and portability Lassi Kortela (25 Apr 2021 12:35 UTC)
Re: R6RS and portability Marc Nieper-Wißkirchen (25 Apr 2021 14:18 UTC)
Re: R6RS and portability Marc Feeley (25 Apr 2021 14:41 UTC)
Re: R6RS and portability Marc Nieper-Wißkirchen (25 Apr 2021 14:55 UTC)
Scheme package management Lassi Kortela (25 Apr 2021 15:04 UTC)
Re: Scheme package management Marc Feeley (25 Apr 2021 15:08 UTC)
Re: Scheme package management Lassi Kortela (25 Apr 2021 15:14 UTC)
Re: Scheme package management Alex Shinn (26 Apr 2021 08:15 UTC)
Re: Scheme package management Lassi Kortela (26 Apr 2021 09:02 UTC)
Re: Scheme package management Alex Shinn (26 Apr 2021 09:33 UTC)
Re: Scheme package management Lassi Kortela (26 Apr 2021 09:41 UTC)
Re: Scheme package management Jakub T. Jankiewicz (26 Apr 2021 12:01 UTC)
Re: Scheme package management Lassi Kortela (26 Apr 2021 12:09 UTC)
Re: Scheme package management Alex Shinn (26 Apr 2021 12:58 UTC)
Re: Scheme package management Alex Shinn (26 Apr 2021 12:35 UTC)
Re: R6RS and portability Marc Feeley (25 Apr 2021 15:05 UTC)
Re: R6RS and portability Marc Nieper-Wißkirchen (25 Apr 2021 15:14 UTC)
Scheme package management Lassi Kortela (25 Apr 2021 15:22 UTC)
Re: Scheme package management Marc Nieper-Wißkirchen (25 Apr 2021 15:35 UTC)
Re: Scheme package management Lassi Kortela (25 Apr 2021 15:45 UTC)
Re: Scheme package management Marc Nieper-Wißkirchen (25 Apr 2021 15:51 UTC)
Re: Scheme package management Lassi Kortela (25 Apr 2021 16:27 UTC)
Re: Scheme package management Marc Feeley (25 Apr 2021 15:47 UTC)
Re: Scheme package management Lassi Kortela (25 Apr 2021 15:54 UTC)
Scheme package management Marc Feeley (25 Apr 2021 15:28 UTC)
Re: Scheme package management Marc Nieper-Wißkirchen (25 Apr 2021 15:41 UTC)
Re: R6RS and portability Jakub T. Jankiewicz (25 Apr 2021 15:55 UTC)
Re: R6RS and portability Lassi Kortela (25 Apr 2021 16:15 UTC)
Re: Making SRFI go faster Adam Nelson (25 Apr 2021 20:56 UTC)
Re: Making SRFI go faster Marc Nieper-Wißkirchen (25 Apr 2021 21:14 UTC)
Re: Making SRFI go faster Adam Nelson (25 Apr 2021 21:29 UTC)
Re: Making SRFI go faster Lassi Kortela (25 Apr 2021 21:40 UTC)
Re: Making SRFI go faster Marc Nieper-Wißkirchen (26 Apr 2021 06:05 UTC)
Re: Making SRFI go faster Marc Feeley (25 Apr 2021 21:07 UTC)
Re: Making SRFI go faster Adam Nelson (25 Apr 2021 21:34 UTC)
Building up R7RS in stages Lassi Kortela (25 Apr 2021 21:45 UTC)
Re: Making SRFI go faster Marc Feeley (25 Apr 2021 21:59 UTC)
Re: Making SRFI go faster Amirouche Boubekki (26 Apr 2021 06:54 UTC)
Re: Making SRFI go faster Marc Nieper-Wißkirchen (25 Apr 2021 11:36 UTC)
Re: Making SRFI go faster Lassi Kortela (25 Apr 2021 11:47 UTC)
Re: Making SRFI go faster Adam Nelson (25 Apr 2021 20:12 UTC)
Re: Making SRFI go faster Lassi Kortela (25 Apr 2021 20:29 UTC)
Re: Making SRFI go faster John Cowan (26 Apr 2021 00:28 UTC)
Spec vs code, user-driven vs designer-driven Lassi Kortela (26 Apr 2021 06:15 UTC)
Re: Spec vs code, user-driven vs designer-driven John Cowan (01 May 2021 06:34 UTC)
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen (01 May 2021 07:03 UTC)
Re: Spec vs code, user-driven vs designer-driven Lassi Kortela (01 May 2021 08:14 UTC)
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen (01 May 2021 09:12 UTC)
Re: Spec vs code, user-driven vs designer-driven Lassi Kortela (01 May 2021 09:56 UTC)
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen (01 May 2021 10:29 UTC)
Re: Spec vs code, user-driven vs designer-driven Lassi Kortela (01 May 2021 11:01 UTC)
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen (01 May 2021 11:33 UTC)
Re: Spec vs code, user-driven vs designer-driven Lassi Kortela (01 May 2021 12:09 UTC)
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen (01 May 2021 12:49 UTC)
Re: Spec vs code, user-driven vs designer-driven Lassi Kortela (01 May 2021 13:34 UTC)
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen (01 May 2021 14:02 UTC)
Re: Spec vs code, user-driven vs designer-driven Lassi Kortela (01 May 2021 14:39 UTC)
Re: Spec vs code, user-driven vs designer-driven Per Bothner (01 May 2021 15:37 UTC)
Re: Spec vs code, user-driven vs designer-driven Amirouche Boubekki (01 May 2021 14:10 UTC)
Re: Spec vs code, user-driven vs designer-driven Lassi Kortela (01 May 2021 15:04 UTC)
Re: Spec vs code, user-driven vs designer-driven Amirouche Boubekki (01 May 2021 16:43 UTC)
Re: Spec vs code, user-driven vs designer-driven Adam Nelson (01 May 2021 17:35 UTC)
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen (01 May 2021 17:55 UTC)
Re: Spec vs code, user-driven vs designer-driven John Cowan (01 May 2021 18:32 UTC)
Re: Discussion with the creator of Lojban, and editor of R7RS-large Arthur A. Gleckler (02 May 2021 02:08 UTC)
Re: Discussion with the creator of Lojban, and editor of R7RS-large Arthur A. Gleckler (02 May 2021 04:16 UTC)
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen (02 May 2021 17:21 UTC)
Re: Spec vs code, user-driven vs designer-driven John Cowan (01 May 2021 18:12 UTC)
Re: Spec vs code, user-driven vs designer-driven Arthur A. Gleckler (01 May 2021 18:21 UTC)
Re: Spec vs code, user-driven vs designer-driven Marc Feeley (01 May 2021 18:37 UTC)
Re: Spec vs code, user-driven vs designer-driven John Cowan (01 May 2021 20:18 UTC)
Re: Spec vs code, user-driven vs designer-driven John Cowan (01 May 2021 17:08 UTC)
Re: Spec vs code, user-driven vs designer-driven Lassi Kortela (01 May 2021 16:30 UTC)
Re: Spec vs code, user-driven vs designer-driven Faré (03 May 2021 02:24 UTC)
Re: Spec vs code, user-driven vs designer-driven Lassi Kortela (03 May 2021 09:49 UTC)
Re: Spec vs code, user-driven vs designer-driven Faré (03 May 2021 14:20 UTC)
Re: Spec vs code, user-driven vs designer-driven Lassi Kortela (03 May 2021 14:33 UTC)
Re: Spec vs code, user-driven vs designer-driven John Cowan (03 May 2021 14:41 UTC)
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen (03 May 2021 15:01 UTC)
Re: Spec vs code, user-driven vs designer-driven John Cowan (03 May 2021 19:47 UTC)
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen (03 May 2021 20:43 UTC)
Re: Spec vs code, user-driven vs designer-driven John Cowan (03 May 2021 23:49 UTC)
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen (04 May 2021 07:33 UTC)
Re: Spec vs code, user-driven vs designer-driven John Cowan (05 May 2021 18:34 UTC)
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen (05 May 2021 18:52 UTC)
Re: Spec vs code, user-driven vs designer-driven John Cowan (05 May 2021 20:13 UTC)
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen (05 May 2021 20:26 UTC)
Re: Spec vs code, user-driven vs designer-driven Amirouche (05 May 2021 21:37 UTC)
Re: Spec vs code, user-driven vs designer-driven Alex Shinn (05 May 2021 21:50 UTC)
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen (06 May 2021 13:18 UTC)
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen (03 May 2021 14:27 UTC)
Re: Making SRFI go faster Marc Nieper-Wißkirchen (26 Apr 2021 08:09 UTC)
Re: Making SRFI go faster Lassi Kortela (26 Apr 2021 08:15 UTC)
Re: Making SRFI go faster Marc Nieper-Wißkirchen (26 Apr 2021 08:27 UTC)
Re: Making SRFI go faster Wolfgang Corcoran-Mathe (26 Apr 2021 02:46 UTC)
Re: Making SRFI go faster Marc Nieper-Wißkirchen (26 Apr 2021 05:58 UTC)
Re: Making SRFI go faster Lassi Kortela (26 Apr 2021 06:45 UTC)
Re: Making SRFI go faster Amirouche Boubekki (26 Apr 2021 07:06 UTC)
Interaction between spec and code Lassi Kortela (26 Apr 2021 07:36 UTC)
Re: Interaction between spec and code Marc Nieper-Wißkirchen (26 Apr 2021 07:59 UTC)
Re: Interaction between spec and code Lassi Kortela (26 Apr 2021 08:06 UTC)
Re: Interaction between spec and code Marc Nieper-Wißkirchen (26 Apr 2021 08:17 UTC)
Re: Interaction between spec and code John Cowan (30 Apr 2021 14:39 UTC)
Re: Interaction between spec and code Lassi Kortela (30 Apr 2021 14:56 UTC)
Re: Interaction between spec and code John Cowan (01 May 2021 05:02 UTC)
Re: Making SRFI go faster Marc Nieper-Wißkirchen (25 Apr 2021 20:30 UTC)
Re: Making SRFI go faster John Cowan (25 Apr 2021 23:04 UTC)

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.