Live data from Hacker News

Common Lisp ASDF maintainer considers resignation

mailman.common-lisp.net

21–30 of 69 posts

Re: Common Lisp ASDF maintainer considers resignation

#21
post #16

Earlier quoted context omitted.

This seems like a very minor thing in comparison. The python 2 to 3 thing had many big issues. It was impossible to automatically convert code from 2 to 3. It was very complicated to write code that would be compatible with both versions. If one of your dependencies was 2-only, then you had no choice but to wait for them. Meanwhile, with most software being on 2, libaries were incentivized to stay on 2. So there was…

Is there any impending prospect of major CL implementations distributing asdf-devel by default?

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

Re: Common Lisp ASDF maintainer considers resignation

#22
post #15
post #11

Earlier quoted context omitted.

Is it really sane to have a world of software that can’t survive new compiler or loader warnings? That just seems crazy to me

There is one school of software engineering which upgrades all warnings to be errors and thus fatal because "warning culture" leads complacency. Thus emitting a new warning as part of default behavior will break builds.

Yes. But if you do that, then you need to be willing to fix new warnings (or ignore them) when you update dependencies. After all, if an update adds a new warning about something dangerous you are doing in your code, but shouldn't be, wouldn't you like to know about it?

Re: Common Lisp ASDF maintainer considers resignation

#23
post #6

Earlier quoted context omitted.

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.

But isn't "breaking compatibility" here emitting a warning that the downstream is treating as an error (because they've chosen to treat warnings as errors)? I feel like emitting it as a warning doesn't break compatibility but the downstream complaining (sbcl?) happens to be high profile enough that they can raise a stink about it.

And specifically, a warning about using undocumented behavior.

Re: Common Lisp ASDF maintainer considers resignation

#24
post #21

Earlier quoted context omitted.

Is there any impending prospect of major CL implementations distributing asdf-devel by default?

"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

Re: Common Lisp ASDF maintainer considers resignation

#25

I learn a lot about diplomatic language from posts like that. I wonder how much time it usually takes people to write those. For me, it takes a lot of time and revisions.

I like that the language is also minimally-dramatic. Seems like the product of a clear-minded thinker. (And/or many revisions).

Re: Common Lisp ASDF maintainer considers resignation

#26
Two obvious constraints in sharing software:

* If software producers are pushing out obviously incompatible changes (excluding Hyrum's law and https://xkcd.com/1172) to consumers, the eco-system is broken. This includes SemVer-aware package managers which transparently bump up past major-version boundaries by default. (That doesn't seem to be what's happening here.)

* If software consumers can't handle new warnings, the eco-system is broken. This includes C and now Common Lisp.

Creating an eco-system that threads the needle between these constraints is an exercise for the reader. One thing that helps is minimizing the depth of dependency stack: https://news.ycombinator.com/item?id=16882140#16882555. Beyond that, producers should be free to make incompatible changes as long as consumers can pick them up on their own schedule. Anything else is absolutely bonkers.

Re: Common Lisp ASDF maintainer considers resignation

#27
post #10

To people as lost about this as I was: ASDF here is the common lisp build system [1], not the tooling version manager [2]. Entirely my fault I was confused, tbh. 1: https://asdf.common-lisp.dev 2: https://github.com/asdf-vm/asdf

I thought maybe it was like BDFL but different words.

Re: Common Lisp ASDF maintainer considers resignation

#28
post #7
post #6

Earlier quoted context omitted.

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.

So another Python 2 vs 3 situation?

Well, the Python community is a few orders of magnitude larger than the Common Lisp community, so more of a tempest in a teapot situation here.

Re: Common Lisp ASDF maintainer considers resignation

#30
the discussion of "gifts" etc in https://gist.github.com/phoe/7d24bdb1f2be76a02fecba8cfecbef3... (which is a great suggestion to read to understand what's up with ASDF) reminds of the bigger context – the ongoing "discussion" about the "responsibilities" of open source developers. i'm putting both words into quotes because it doesn't seem that the language we have even supports discussing that there's any responsibility

Antoine de Saint-Exupéry's weird saying comes to mind, though. “You become responsible for what you've tamed.”

Post reply on HN