There are plenty of instances of badly written software putting lives in danger. And true, it was a new field at some point, but what still is allowed to pass as "professional" software is alarming and embarrassing. So that's one of my main points: on the whole, it's like even basic fundamentals of designing coherent software are by and large missing, ignored, or not even grasped. Things like proper decomposition and abstraction, etc. My guess is that this is largely due to that fact that you cannot "see" what's in a program: the data flows and execution flows, etc. Like many programmers are so used to having to decipher code anyway, that they either don't realize that it doesn't make sense, or that it can make straightforward sense. There are multiple times in my career where I've thought to myself: if the components and flows and organization in our code was something physical that any non-programmer could walk by and see -- if it was at least vaguely visible what their software "engineers" were doing with/in their software -- the business would be appalled. Hey, that's our name on that! We don't have time and money to waste this convoluted nonsense! We expect or customers to rely on this stuff! I know many consider this to be a subjective matter, but I'm not taking about I prefer Jim's style of writing versus Joe's, I'm taking about Sarah laid out the business requirements in two clear paragraphs and a few bullet points, and Sue wrote 5 pages about the same thing with no coherent train of thought. (names and examples are made up). My point is that language and tools will not fill this gap, but is something that needs to be understood and fixed in it's own rite. HOWEVER, I do think it can help tremendously if it's obvious at a glance whether a program (or software component) is straightforward, or horribly convoluted. If we can see what we're doing, maybe we can begin to understand what we're doing, see what we're doing, and talk about it and take ownership of it. (This is mostly coming from a context of what happens in professional software development, based on my experience and observations)

I think you're ignoring the largest source of problems, the elephant in the room that never gets discussed: incoherence of ownership. Software is in a pretty nice state today. Everybody accepts bugs, and unlike other fields we can get away with "NO WARRANTY" licenses. So the fundamental problem is one of incentive. As in, giving people an incentive to do better. Right now we can get away with constantly pointing at somebody else when there's a problem. Maybe that will always be true. There are certainly other fields that are sustainably high status relative to their customers. And they tend to involve a priesthood that understands arcane rules. So maybe we can get away with it indefinitely, turning gradually into an ossified field that requires tons of accreditation before you're permitted to write a line of code, and writing code for yourself, well perish the thought. Or maybe we create a crisis so vast that the population at large throws their arms up and turns away from the open sea (as happened with https://en.wikipedia.org/wiki/Zheng_He). This is a personal preference, but I prefer the latter future to the former. But really I'd like to avoid both these endgames. And that seems to require taking responsibility for your dependencies. That is the prerequisite. Asking for better representations for your dependencies before you take responsibility is akin to asking for more resources before you can do the work your boss tells you to do. We all know how that conversation goes.