Email list hosting service & mailing list manager

Amending libraries, versioning Shiro Kawai (21 Nov 2022 01:50 UTC)
Re: Amending libraries, versioning Arthur A. Gleckler (21 Nov 2022 02:15 UTC)
Re: Amending libraries, versioning Marc Nieper-Wißkirchen (21 Nov 2022 06:55 UTC)
Re: Amending libraries, versioning Lassi Kortela (21 Nov 2022 12:53 UTC)
Re: Amending libraries, versioning Arthur A. Gleckler (22 Nov 2022 19:46 UTC)
Re: Amending libraries, versioning John Cowan (22 Nov 2022 23:00 UTC)
Re: Amending libraries, versioning shiro.kawai@xxxxxx (22 Nov 2022 23:25 UTC)
Re: Amending libraries, versioning John Cowan (23 Nov 2022 02:29 UTC)
Re: Amending libraries, versioning Shiro Kawai (23 Nov 2022 03:31 UTC)
Re: Amending libraries, versioning Shiro Kawai (23 Nov 2022 04:37 UTC)
Re: Amending libraries, versioning Lassi Kortela (23 Nov 2022 10:07 UTC)
Re: Amending libraries, versioning Marc Nieper-Wißkirchen (23 Nov 2022 07:05 UTC)
Re: Amending libraries, versioning Lassi Kortela (23 Nov 2022 10:05 UTC)
Re: Amending libraries, versioning Marc Nieper-Wißkirchen (23 Nov 2022 10:09 UTC)
Re: Amending libraries, versioning Lassi Kortela (23 Nov 2022 10:42 UTC)
Re: Amending libraries, versioning Marc Nieper-Wißkirchen (23 Nov 2022 11:11 UTC)
Re: Amending libraries, versioning Marc Nieper-Wißkirchen (23 Nov 2022 11:17 UTC)
Re: Amending libraries, versioning Lassi Kortela (23 Nov 2022 11:33 UTC)
Re: Amending libraries, versioning John Cowan (24 Nov 2022 22:39 UTC)
Re: Amending libraries, versioning Lassi Kortela (24 Nov 2022 23:10 UTC)
Re: Amending libraries, versioning John Cowan (24 Nov 2022 23:50 UTC)
Re: Amending libraries, versioning Lassi Kortela (25 Nov 2022 09:23 UTC)
Re: Amending libraries, versioning Marc Nieper-Wißkirchen (25 Nov 2022 10:48 UTC)
Re: Amending libraries, versioning Lassi Kortela (25 Nov 2022 13:03 UTC)
Re: Amending libraries, versioning Marc Feeley (25 Nov 2022 13:29 UTC)
Re: Amending libraries, versioning Arthur A. Gleckler (25 Nov 2022 16:01 UTC)
Re: Amending libraries, versioning Lassi Kortela (25 Nov 2022 17:31 UTC)
Re: Amending libraries, versioning Marc Nieper-Wißkirchen (25 Nov 2022 17:56 UTC)
Re: Amending libraries, versioning Lassi Kortela (25 Nov 2022 22:46 UTC)
Re: Amending libraries, versioning Marc Nieper-Wißkirchen (26 Nov 2022 11:32 UTC)
Re: Amending libraries, versioning Arthur A. Gleckler (25 Nov 2022 04:35 UTC)
Re: Amending libraries, versioning Marc Nieper-Wißkirchen (25 Nov 2022 07:01 UTC)
Re: Amending libraries, versioning Marc Nieper-Wißkirchen (25 Nov 2022 18:38 UTC)
Re: Amending libraries, versioning Marc Feeley (25 Nov 2022 22:31 UTC)
Re: Amending libraries, versioning Marc Nieper-Wißkirchen (26 Nov 2022 09:24 UTC)
Re: Amending libraries, versioning Shiro Kawai (23 Nov 2022 11:36 UTC)
Re: Amending libraries, versioning Marc Nieper-Wißkirchen (23 Nov 2022 11:45 UTC)
Re: Amending libraries, versioning Marc Feeley (23 Nov 2022 13:58 UTC)
Re: Amending libraries, versioning Marc Nieper-Wißkirchen (23 Nov 2022 14:23 UTC)
Re: Amending libraries, versioning Lassi Kortela (23 Nov 2022 15:16 UTC)
Re: Amending libraries, versioning Marc Nieper-Wißkirchen (23 Nov 2022 15:22 UTC)
Re: Amending libraries, versioning Marc Nieper-Wißkirchen (23 Nov 2022 15:54 UTC)
Re: Amending libraries, versioning Lassi Kortela (23 Nov 2022 17:29 UTC)
Re: Amending libraries, versioning Arthur A. Gleckler (23 Nov 2022 23:58 UTC)
Re: Amending libraries, versioning Lassi Kortela (24 Nov 2022 08:20 UTC)
Re: Amending libraries, versioning John Cowan (24 Nov 2022 22:06 UTC)
Re: Amending libraries, versioning Marc Nieper-Wißkirchen (25 Nov 2022 07:09 UTC)
Re: Amending libraries, versioning Lassi Kortela (23 Nov 2022 11:25 UTC)

Re: Amending libraries, versioning Marc Nieper-Wißkirchen 26 Nov 2022 11:32 UTC

Am Fr., 25. Nov. 2022 um 23:46 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:

> I don't hold rationality in such high regard; I barely know what it is.
> To make rational decisions you'd have to predict the future, which
> people who like to follow chains of reasoning are not better at than
> others. (We are supposed to make decisions based on "priors" but that's
> passing the buck. Without knowing the future we have no basis on which
> to assign relative weights to different priors. Conventional priors
> encode a hidden assumption that the future is like the past; how do you
> formulate the likelihood of that?)

I meant the word "rational" to be understood in a slightly different
sense.  What I meant is that arguments should usually not be weighted
by who made them (neither positively nor negatively) and that when we
argue, we should avoid rhetoric tricks to try to persuade others but
try to convince them with the logic of our arguments.

We all have to base our arguments and logical deductions on some
hypothesis.  As is usual in inductive reasoning, we may be falsified
when our assumptions are shown to be wrong but the history of natural
sciences tells us that this is not an argument against inductive
reasoning in itself.

>
> > You seemingly think that the SRFI and RnRS are off-track or are in
> > danger of falling off track. It seems to be that not everyone here
> > shares your opinion about that. Maybe this is the crux of this
> > dispute, namely that not everyone proceeds from the same assumptions.
>
> Indeed, off track and getting more so. These processes are handled in a
> way that is excellent at details, but the details don't add up to a
> coherent whole.
>
> Instead of being a rationalist, I'm an essentialist - a big picture
> pattern matcher. Everything has an essence and its job is to conform to
> that essence. I basically look at technology like a sculptor. If
> something is technically correct but looks out of place or out of
> proportion, I see that as a bigger problem than something technically
> incorrect but in proportion.
>
> The essence of RnRS is to be the stuff that Scheme implementations agree
> on. Currently it's off pursuing "something completely different" and no
> one can say when it will return.
>
> The essence of SRFI is to be a basket of accessories that should be
> added by implementers, not users. Currently a lot of it is user-level
> stuff, and the implementer-level stuff we propose is not urgent.
>
> Seeing the essence of something first makes many things look odd. Lots
> of things seem out of whack with themselves; they have an identity
> crisis. Identity crises are painful to fix so they have a tendency to
> get slowly worse over time. This is a general problem in tech.

> > The following three statements are certainly not forbidden here:
> >
> > 1. "It is clear that RnRS has no future."
> > 2. "I think RnRS has no future."
> > 3. "RnRS has no future because the Scheme has diverged too much so
> > that any common standard will be too limited to be of any practical
> > use."
> >
> > Obviously, these three statements (whether true or not) contribute to
> > an ongoing discussion in different ways.
>
> At present, I believe both SRFI and RnRS are "doomed to succeed". A
> Pyrrhic victory. They will keep going and eventually fulfill all their
> obligations, but in a way that yields little benefit to Scheme as a
> whole. Following the letter of their charter but increasingly devoid of
> the spirit. And the fact that these processes keep functioning on paper
> will draw just enough juice out of competing efforts that nobody will
> manage to bootstrap their successors without splitting Scheme yet again.
>
> To use yet another metaphor, I think these are on track to be undead
> processes. ("Zombie process" is actual Unix terminology!)
>
> > PS If you are interested in a more private discussion and you want it,
> > we can also talk about these issues privately.
>
> I prefer a public discussion where possible.

Initially, I intended the three statements I wrote to be examples.
But if you feel the need to discuss these and your observations
surrounding the RnRS and SRFI processes, their goals, and what they
will achieve, I would suggest doing this in a new thread unless it is
related to the topic of this one, stability of specifications, and
implementations.

Marc