Live data from Hacker News

Common Lisp ASDF maintainer considers resignation

mailman.common-lisp.net

51–60 of 69 posts

Re: Common Lisp ASDF maintainer considers resignation

#51

Earlier quoted context omitted.

You're inventing things like "judging and chastising" - they do not appear to be present in the original text. Mischaracterisation is a bad idea.

Let me quote the text for what I consider "judging" (in the sense of making a presumptuous claim about or characterization of a person or group): > What is even worse is that the CL community tacitly accepts [the behavior of the person I am arguing with] as normal behavior. This is making a judgment about what behavior "the CL community" accepts. (Unless you believe "tacit" includes anybody in the world who doesn't p…

> I would like to see the CL open source community pause and consider what constitutes a healthy community.

This is in no-one's dictionary "chastising" (random dictionary plucked from search):

> chastising (Entry 1 of 2) inflicting, involving, or serving as punishment

As for "judging" - this seems proportionate. E.g. while I think your judgment is poor when you use these words, I don't think a valid criticism of your comment is that you are "judging" anything. By this definition, almost everything anyone says is "judging".

Re: Common Lisp ASDF maintainer considers resignation

#52

Earlier quoted context omitted.

Let me quote the text for what I consider "judging" (in the sense of making a presumptuous claim about or characterization of a person or group): > What is even worse is that the CL community tacitly accepts [the behavior of the person I am arguing with] as normal behavior. This is making a judgment about what behavior "the CL community" accepts. (Unless you believe "tacit" includes anybody in the world who doesn't p…

> I would like to see the CL open source community pause and consider what constitutes a healthy community. This is in no-one's dictionary "chastising" (random dictionary plucked from search): > chastising (Entry 1 of 2) inflicting, involving, or serving as punishment As for "judging" - this seems proportionate. E.g. while I think your judgment is poor when you use these words, I don't think a valid criticism of your…

Interesting, my dictionary says:

> chas·tise

> /ˈCHasˌtīz,ˌCHaˈstīz/

> verb

> rebuke or reprimand severely.

> "he chastised his colleagues for their laziness"

I disagree with what you said about "judging" as it pertains to how you interpret what I said, but I don't have anything to further clarify for you.

In any case, I hope you can now agree these claims weren't inventions.

Re: Common Lisp ASDF maintainer considers resignation

#53
post #6
post #4

Earlier quoted context omitted.

TLDR; "Dev: Oh, you must have been using undocumented behavior of ASDF. Your code will continue to work as before, but if you change this #\- to a #\/ it'll stop complaining. User: Our code used to work in ASDF-stable. Any warning at all breaks our build, so it's broken in ASDF-devel. Just make it work like it did in ASDF-stable again. ... User: That undocumented behavior works well for us, though. Dev: That behavior…

Another TLDR would be; ASDF-stable is good enough that there isn't an incentive to update to a version of ASDF-devel that breaks backward compatibility.

That TLDR worked for Python 2 for 10+ years after all.

Re: Common Lisp ASDF maintainer considers resignation

#54
post #33
post #31

Earlier quoted context omitted.

Running a red light is dangerous, therefore let's remove red lights..

You have it backward. This is installing a red light in the middle of a road where there is no intersection because 10 years from now there is a plan to build a crossroad and then wondering why people are angry about a traffic jam in the middle of nowhere. People who ignore warnings are the people who run new red lights and will eventually kill someone when the intersection goes in. The people who upgrade them to err…

The people who upgrade warnings to errors are those who wire the check engine light to the brake. This is fine for a test environment where you want to highlight problems, but it does not mean you get to yell at whoever improved the check engine logic to detect more potential problems if you car now stops in the middle of the highway.

Re: Common Lisp ASDF maintainer considers resignation

#55
post #3

For (way) more context see https://gist.github.com/phoe/7d24bdb1f2be76a02fecba8cfecbef3...

Thanks for that link. It is an overlong but has some interesting comments about Lisp culture, Hyrum's law, and backwards compatibility. "Don't break stuff" is valuable.

Re: Common Lisp ASDF maintainer considers resignation

#56
post #21

Earlier quoted context omitted.

"asdf-devel" is just what this post is calling "releases newer than the ones implementations ship," which not only feels like an _incredibly_ slippery definition, but by definition, no, once an implementation starts shipping it it's no longer a -devel version. I know of at least one distro that forcibly upgrades the ASDF that SBCL ships, though.

:o

And distro behaviour is part of why the only reason anyone recently bothered working on lisp packaging for debian is the requirement for source packages for software shipped in main repo, so for one program someone built enough tooling to replace old debian tooling and build pgloader the way it should be done.

Re: Common Lisp ASDF maintainer considers resignation

#57
post #45

Earlier quoted context omitted.

It's very common that people take the behaviour of one or two people they actually interact with as the behaviour of the "community". Jumping to conclusions is a favourite past-time. In this case, Y actually affects a lot of members of the community, but I guess most couldn't be bothered to express their opinions. I don't know if the proposed change has strong enough motivation to break backwards compatibility in a l…

A long time ago, countless projects started using X in a way that wasn't documented (specifically, using X to define multiple modules in one file, instead of one module per file), and it has worked forever just fine. I consider it an unintended (and nice) feature. X no longer wants to support this use-case, because they discovered that by not supporting it, they can clean up X's code a bit, and it makes X more effici…

I'd like to add that the fact that you're supposed to use only one DEFSYSTEM form per ASD file wasn't very advertised, at least back when I wrote my first ASDF systems (back when ASDF2 was still in the future) and since then one rarely delved again into full rereading of the manual.

Re: Common Lisp ASDF maintainer considers resignation

#58
post #41

Something I have noticed. Consider the following trolley problem: - The switch operator is on a bathroom break - The trolley is headed for a dead-end where it will crash and cause $100k in damages. - Pushing the button will divert the trolley to an empty track where it will safely halt, doing no damage. - A bystander who is not employed by the trolley company happens to observe all of this For more people than I woul…

In today's world, a rational bystander would consider the possible legal implications of getting involved and decide no thanks, not my circus, not my monkeys.

Re: Common Lisp ASDF maintainer considers resignation

#59

If someone gives you a PR that is a small, minimal change, and is backwards compatible, but fixing a load of issues because someone wants to improve their system and is often being used in tandem with yours... then you're kinda just being a troll. Anything being used by other people will of course have changes. Software is never static unless you keep it to yourself in a locked basement. This whole ordeal is sort of…

On the other hand, if a single, foundational project is continually issuing PRs across the ecosystem that, at the end of the day, are not a result of changes that seem to benefit the user tangibly, then I could see it getting annoying for project maintainers.

“Continually” is a pretty strong word for one change.

Re: Common Lisp ASDF maintainer considers resignation

#60
post #59

Earlier quoted context omitted.

On the other hand, if a single, foundational project is continually issuing PRs across the ecosystem that, at the end of the day, are not a result of changes that seem to benefit the user tangibly, then I could see it getting annoying for project maintainers.

“Continually” is a pretty strong word for one change.

What's not obvious from the discussion here and elsewhere is that this was not the only change coming from ASDF to this same maintainer. The maintainer in question is also an SBCL developer, who is responsible for upgrading and shipping copies of ASDF with that implementation of Lisp. So it wasn't his first rodeo dealing with ASDF changing behavior (and, sometimes, breaking his users' code downstream). Finally, this wasn't one change to one project; this was one flavor of change that was being sent to the whole "edicl" collection of projects.
Post reply on HN