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 Depierre
@hipsterelectron re build systems... I think they are not complex enough in their depth, but their interfaces are atrociously *bad UX*
Feb 27 at 12:31pmWeb
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 threadThomas DepierreFeb 27
@hipsterelectron see https://www.softwaremaxims.com/blog/economics-developer-tools
The Economics of Developer Tooling

It would be a major boon to software velocity, maintenance burden and safety to bring more attention to developer tooling, in particular bringing to everyone’s toolkit the techniques and technologies developed since the 80s but that was never mainstreamed. It is at least what I advocated for in We Need More Process Engineering in Software. Over the past few years, I have explained to a lot of people the current state of developer tooling development and how the economics of them work. This post aims to summarize all of this in one place.

Musings about software
Show threadThomas DepierreFeb 27

@hipsterelectron my conclusion still stand
"Does it still make economic sense to invest in this domain? Yes, the upside would be massive. But the financial instruments adapted to this particular set of conditions seem to be lacking. Neither commercial, non-profit, philanthropic, or governmental organizations have found a sustainable way to contribute after the prototype phase. The only exception seems to be some massive organization, which can justify the investment on their internal cost reduction alone."

We simply do not have the correct financial instrument to back this kind of work

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 DepierreFeb 27
@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
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.