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]
But the environment cannot be completely described without abstraction, and therefore, approximation.
@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.
@hipsterelectron There is so much I want to yell at in this. It is this whole worldview that got us into our current mess, by making it hard to find out where our problems are.
Because our problems are in things that are totally ignored by this worldview.
@[email protected] i don't think most build systems are complicated enough
@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.
@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.
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.
@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
@hipsterelectron @RuthMalan programs today need to adapt to changing environments. Platform requirements change. Library support changes. Security issues get detected and exploited. Laws change.
So yeah, bit rot is not happening, because the program itsself deteriorates, but because its environment changes nd the program needs to adapt.
d@nny disc@ mc²
Thomas Depierre
Sven Kloppenburg
trystimuli