d@nny disc@ mc²Feb 27
cool gnu programming language alert https://todon.nl/@janneke/116142405561630337 this one does formal verification
Janneke (@[email protected])

We are happy to announce Dezyne 2.20 which introduces global function and foreign function. This release represents 111 commits over three years. <https://mail.gnu.org/archive/html/dezyne-devel/2026-02/msg00001.html> @[email protected]

Todon.nl
Show threadd@nny disc@ mc²Feb 27
fascinating fucking paper it links to in the docs https://cs.uwaterloo.ca/~a78khan/cs446/additional-material/scribe/27-refactoring/Lehman-LawsOfSoftwareEvolution.pdf
Show threadThomas DepierreFeb 27

@hipsterelectron I have some... rants... on the whole idea of lifecycle for programs. Boehm (who is referenced in there) really fucked up the whole field, but he was not alone. The NATO conference really fucked it too

And we are still not over this. And yes, what this paper said and its school of thought come straight from this and I disagree with it so *violently*.

In particular, I have soooo many problems with things like complexity reflecting deterioration.

If anything, we know today that it is the opposite.

Show threadd@nny disc@ mc²Feb 27
@Di4na it does seem very wrong that complexity would reflect deterioration https://circumstances.run/@hipsterelectron/116142115289368609 one viewpoint i've found very important is to understand how many bugs have been fixed in long-running programs and how all that institutional knowledge has to be rebuilt for cleanroom rewrites
d@nny disc@ mc² (@[email protected])

@[email protected] i don't think most build systems are complicated enough

GSV Sleeper Service
Show threadThomas DepierreFeb 27

@hipsterelectron I mean yes. On the other hand... bugs are usually not the actually important part, the ability to keep evolving (and how easy it is to evolve the code) matters a lot more in term of impact.

And these... these deserve some rewrites to a different set of tools regularly.

Said otherwise. Tools (like languages) are *also* limited by the context in which they were created. At some point, the world evolved past what the tools can handle, and so you have to rewrite everything that live *atop* the tools.

Show threadThomas DepierreFeb 27
@hipsterelectron re build systems... I think they are not complex enough in their depth, but their interfaces are atrociously *bad UX*
Show threadd@nny disc@ mc²Feb 27
@Di4na they're generally used to codify monopolies and are not something anyone actively chooses to use
Show threadThomas DepierreFeb 27

@hipsterelectron That is one view. My view is more that people that need help with build systems are the people that cannot pay for help. Like most software tools.

And the other problem is that getting the UX right is a process that take 10 years. Approx. Empirically at least. And you do not see results until 10 years after, once the tool has percolated through.

Waiting *20 years* to see any positive result for your investment is not a good investment case. And yet it is the one we ask.

This is not even about enforcing a monopoly. It is too long of a timespan for the monopolist to even think about.

It is on infrastructure investment timespan, but so far as a society we have not yet realised it is infrastructure.

Show threadd@nny disc@ mc²Feb 27
@Di4na not sure if you're familiar with bazel. it's true that it takes that long to see a result if you are motivated by developer empowerment but you can start seeing results much faster if you have different and more cynical goals. this is the case with a lot of basic science as you identify
Show threadThomas Depierre
@hipsterelectron I am familiar with bazel. It is exactly what I talk about there. A tool made only to solve a really small set of problems, because only a big org can justify that kind of tools and that means they are not adapted to the one with the needs outside of that limited target
Feb 27 at 12:51pmWeb
Show threadThomas DepierreFeb 27
@hipsterelectron It is not a monopoly move because bazel *doesn't care about anyone else using it*. It is a purely internal tool that leaked out a bit. But it barely matters. They do not care about imposing it. It is a tool that is actively anti-monopoly. A monopoly *needs to be adopted to work*. Bazel is not that.