Conviviality in computational science

tldr: I posit that there does not exist a "stable" layer on which to build software. There are gel phase layers where things are constantly shifting and glass phase layers that seem stable until an event comes along to shatter it. I find it more convival to live in the gel than build an ever growing tower of glass so I can pretend that the base isn't just a bunch of spheres in suspension.

As someone else who also did a PhD on colloidal suspensions, I did feel that that segment was almost backwards. I'm younger than the author and was in grad school when Numerical Python came out, but my experiences at the time have left me with the conclusion the opinion that "convival software is living software". Anecdotes that formed this opinion:

1. Some QCD software predated the ANSI C standard. Rather than update the software to the Reagan administration, it required compiling another compiler that could compile the original source. Incidentally, the interim compiler was growing problematic enough that there was discussion of throwing a third compiler into the chain. I also know that the bottom level compiler would only support 32 bit x86 and I believe the current recommendation is to run the final executable in QEMU on systems that now only support 64 bit code
2. A neutron camera only provided drivers for Windows 3.1.1. Again, I was given a flowchart on how to get the software running again on Windows 7, but it did require a pipeline of four compiler, only two of which I could actually find a copy of. I found it faster to rewrite from scratch than to get the original code working
3. Wrangling a Fortran package that only ran on VMS. Again, rewriting everything in Python instead of running a VMS emulator made the software more extensible and life simpler. A small part of the reason that I have my current job is from other people finding the python rewrite more useful.
4. The same beamline that needed the neutron camera had multiple components that were hard coded to require PCI-X hardware. It was next to impossible to buy a new motherboard which supported PCI-X and identical (or vastly superior) hardware was available for PCIe, but we were told that continuously modifying a code base was sign of poor project management and that good software projects had a point where it could be declared done. This software was done and I just needed to get better at sourcing used motherboards.

I appreciate the author's concerns. Heck, the software I wrote for that neutron camera was in Python 2.7 with wxPython. It will not trivially run on any computer I could buy today and I fully agree that it is not convival. However, I disagree that the solution is to freeze the world so that my code can run forever, nor to build a pile of shims and emulators that can allow my code to continue to pretend that it's 2008. The solution is to recognise that code is a living document that requires constant maintenance. Granted, the group who truly needs to recognise this are the funding bodies who should be providing funding for grad students and post docs to perform this maintenance.

What about his actual point, though?

It is a good support for large corporate libraries such as PyTorch, but no longer a good choice for typical research teams that don't have the resources for dealing with high rates of tech churn (Illich's obsolescence). It is now more difficult to run a five-year-old Python script than a 40-year-old Fortran program, and even if it runs, it may not produce the same results as it did in the past.

While I wasn't familiar with his "conviviality" framing, I also quit using Python as my main toolsmithing language around this time for similar reasons -- I intuited that the ecosystem churn around the Python 2 / Python 3 split was going to cause major problems for reverse compatibility, on top of being a big hassle for a while. I switched to using Lua for most personal scripting, and code I wrote literally 15+ years ago still works. Sometimes it needs very minor updates for standard library interface changes, but that's it.

When he says "the scientific Python ecosystem is the example I know best for progressive loss of conviviality," he's talking about how the Python 2 / Python 3 split pulled the rug out from under libraries and other infrastructure being used for scientific research. "The scientific Python ecosystem flipped from a stable infrastructure for research projects to an unstable software layer whose frequent breaking changes required researchers to invest more and more time just to keep their code in a usable state."

logistics of resource transportation, like food and goods

The discussions that I've seen on the matter haven't suggested abandoning roads entirely, but rather limiting their use. There would still be roads for delivery vehicles, buses, ambulances, and even taxis, but driving your own private vehicle would be forbidden. This would vastly reduce traffic allowing for smaller roads. The traffic that remains would fall under the higher standards of a CDL licence, which should (but likely won't) give better adherence to traffic rules and vehicle flow. The reduced traffic would also improve public transport reliability. Finally, there would be vastly reduced parking needs, reducing the empty space surrounding most commercial buildings.

Now, I'm sure you can think of a dozen problems off the top of your head (I certainly can), but resource transit is built into the system.

It's hard to take articles like these very seriously when they don't address the benefits large scale technology has to society.

The author cites degrowthers; degrowth as a movement doesn't just fail to address those benefits, it's actively antagonistic towards the idea that they exist.

My only semi-flippant definition of the degrowth movement is that it's what you get when the radical left realise that their brand of socialism isn't capable of delivering material prosperity to the working class (or any other), and start arguing against material prosperity instead ;)