[michaelfiano]

1) There is much more to the interactive development experience than the REPL. As mentioned in the article, the debugger and inspector are key parts of this workflow.

3) It's not that software is released too far apart, it's that the release of software is out of the hands of developers, and packaged by a third party with dependencies that may not even be API compatible with the developer's software. Since there is no versioning dependency management for Quicklisp to leverage, all it can do is try to build your software in isolation, not check compatibility with dependencies, and certainly not runtime compatibility.

[aidenn0]

> 3) It's not that software is released too far apart, it's that the release of software is out of the hands of developers, and packaged by a third party with dependencies that may not even be API compatible with the developer's software. Since there is no versioning dependency management for Quicklisp to leverage, all it can do is try to build your software in isolation, not check compatibility with dependencies, and certainly not runtime compatibility.

This is what I like about quicklisp. IMO other package managers don't do it this way only because it doesn't scale; pushing packaging and releasing to individual developers does.

Also, building the software "in isolation" checks at least compile-time compatibility with dependencies. IIRC someone (not Xach I think?) also runs the system tests for each system in quicklisp, which will check runtime compatibility to the extent that the tests do so.

In any case, I have literally never run into an issue with transitive dependencies not working in QL; not sure if I'm lucky or what.

[djhaskin987]

> As mentioned in the article, the debugger and inspector are key parts of this workflow.

Which you can use from the commandline inside of the multiplexor. Like I said it's fully featured because it's just you firing up Steel Bank. The debugger and inspector are still there.

> Since there is no versioning dependency management for Quicklisp to leverage, all it can do is try to build your software in isolation, not check compatibility with dependencies, and certainly not runtime compatibility.

The lack of versioning and dependency management is pretty dumb I'm not going to lie. I didn't expect that from a package manager.

> It's not that software is released too far apart, it's that the release of software is out of the hands of developers, and packaged by a third party with dependencies that may not even be API compatible with the developer's software.

Perhaps there are some cases where this is a problem, but in general, I firmly believe that having separate packagers is a good thing[1]. It can be annoying at times, but much more comfortable for the end user.

1: https://drewdevault.com/2019/12/09/Developers-shouldnt-distr...

[adgjlsfhk1]

the problem with this point of view is that for packages under active development, it creates an awful user experience. running into an issue that was fixed 2 years ago and you can't fix is incredibly annoying.

[djhaskin987]

If we're talking about server operating systems, yes, I commiserate with you. But the same principle is applied with Arch Linux, and I've never felt more joy interacting with a packaging system (or Linux community for that matter). Everything is packaged and up-to-date (again, sometimes too up to date). I use Fedora at home and it's at most months behind, but certainly not years, and usually strikes that sweet spot between stability and annoyance.

[adgjlsfhk1]

I take should try an arch variant soon. I'm on an Ubuntu, and I'm at the point where I've learned to live with the jank, but don't love it.

[eigenspace]

As someone using an Arch variant, I can say that the newness of the packages isn't really a problem. The real problem is that there's no package compatability bounds, so even if a new version of a package is known to be incompatible with something you have installed, it'll happily upgrade that package anyways. Plus, there's no easy way to request an old version of a package.

I just wish I could just Julia's package manager as my Linux Distro.

[djhaskin987]

Probably what the guix[1] folks are trying to do, use a "more sophisticated" package manager for OS.

1: https://guix.gnu.org/en/download/