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 Lassi Kortela 25 Nov 2022 22:46 UTC

Thanks for a constructive reply! You have a far greater gift for
patience than I do.

> We are all prone to fallacies; we are humans, after all.  But that
> does not mean that a fallacy isn't one.  If an argument is truly "ad
> hominem," then it does not contribute to a rational discussion.  If
> someone thinks that an argument went this way, they should be allowed
> to say so; this will also give the person accused of failing for a
> fallacy the possible chance to explain why their argument is actually
> not a fallacy - if they still think so.
>
> I don't have the impression that the community gathered here has to be
> treated with kid gloves.  We have seen a lot of arguments.  As long as
> they stay on a rational level, I think no one complains when they are
> fought with no holds barred.  Sometimes, such discussions may drift
> off to personal ones.  In these cases, we have always managed to move
> back to the correct course, a civil one.

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

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