Preventing the Collapse of Civilization / Jonathan Blow (Thekla, Inc)

[this video] I think Jonathan Blow made a decent argument that we're in a decadent age of software. In a decadent age, the civilization still does and can do the thing, but has started to lose a grip on the fundamentals, so it's on the way out. A decadent age is a kind of end, doesn't necessarily feel like the end, it kind of feels like a stagnant bumbling. How many programmers do you know that can write assembly code? How many layers of abstraction between a web app and the silicon? Processor, OS, probably a byte-code VM, probably a framework... leaking a little bit all of the way. He makes a good point--where's the evidence that we can write good software? It seems possible , but it doesn't appear, so really, the feeling that maybe we could is just a feeling, not evidence.

"optimal amount of fraud in society is 0" - are you sure? why? Bad Things(tm) are useful for testing and improving safety/security, and when I see people/institutions with no experience reacting to Bad Things(tm), I know they're in for a world of hurt when it does happen. Perhaps you mean, the optimal amount of fraud that isn't prosecuted... or not detected... ? Even then, I'd argue that there's a tiny percentage that's useful for keeping the safety/security industry on its toes and at the ready. As a proof point, if you believe that war (world peace) is not a solved problem, then it's only a matter of time before your city/region/civilization/race faces an existential threat, for which the only true preparation is to be ready to innovate and mobilize. Sorry if this comes across as dark. I mean it in the same vein as having a small percentage of farmers is desirable. By contrast, I visited a traditional silk factory in Stockholm (amazing btw) and the craft has been lost to the point where they're struggling to find craftspeople able to work their looms and other old equipment. See Jonathan Blow's excellent talk about lost technology: [this video]

Excuse me for not having much to add to the discussion but two interesting references for people to check out, if so inclined of course: a) Ginger Bill (the Odin language creator, no affiliation) stated on a podcast that Odin will never have an official pkg manager, since what they're, in his opinion, mainly automating is dependency hell, and this being one of the main reasons for rising software complexity and lower software quality; see [link] (timestamped to the correct position) (they mention Rust explicitly as an example) b) another programmer rather seriously worried about software quality/complexity is Jonathan Blow, who's talk "Preventing the Collapse of Civilization" is worth watching in my opinion: [this video] (it's not talking about package managers specifically, but is on topic regarding software complexity/quality as a whole) Addendum: And sorry, I feel like almost everyone knows this xkcd by now, but since no one so far seems to have posted it; "obligatory xkcd reference": [link]

This. So much code so many frameworks so much wow, to do so little. And we a little closer to collapse of civilization. [0] There is not enough Jonathan Blow's for all JavaScript bloatware unmaintained unusable in a few years tools. [1] [0] [this video] [1] [link] `I think we're now in a situation where everybody in the world is flooded by low-quality software, and everybody wishes that they had higher quality software, at least people who make software I think. We're making a game, games have a lot of things they want to do, a lot of those things are potentially stuff that a library could do of some kind, and so, let's go out, whether it's maybe to do some constructive solid geometry or text layout or something. There's a lot of different little sub-jobs. If I go on the internet, what is the state of the art of what people out there are doing for this task? Very often I will find a number of things that claim to do the job. Some of them actually do it to an okay level and some don't, and a lot of them don't really work for high-stress situations, and a lot of them don't even like frickin compile anywhere. Just the amount of swimming through a sewer that I have to do to even figure out, "What is the thing that I can seriously consider to maybe do this job versus writing it myself?" That is a huge investment, time and energy investment`

It was just a few days ago when I mentioned how often I see the dragon book held up as a punching bag. It seems that at some point the book, along with K&R, have become the target for unsubstantiated criticism. I've pressed for details, and I've seen others do the same, but it never ends in anything concrete—just an implicit appeal to the new conventional wisdom that they do more harm than good. Reminds me of how "truth" gets synthesized on Reddit. Here's a counterexample: Russ Cox has a series on regular expressions, beginning with Regular Expression Matching Can Be Simple And Fast < [link] >. In the last several years, it has become very well-received. In it, he lays out the case for Thompson NFAs, and also laments in some places about how the approach is not more widely known, having become a sort of lost knowledge. (See also Jonathan Blow's < [this video] >.) For all the criticism of the dragon book, though, you'd think that would mean enough people have read it that someone would have pointed out that Thompson is cited in Chapter 3, where his approach is described in some detail. I think that what's actually going on is that, like The Art Of Computer Programming, the dragon book is widely referenced and rarely read. Now, enter the 21st century meme factory. Having said that, the most recent comment I saw that was being casually dismissive of the dragon book—ironically for its "second-rate methods" that have "held back" compiler development—did motivate me into digging the boo

I have had a really frustrating relationship with software maintenance in all of the companies I've worked for. I've always been a strong, strong believer in an analogy like: How much time would you estimate that nuclear engineers spend operating and maintaining existing reactors, versus building new ones? How about public highway departments and building new roads, versus fixing or improving existing ones? No analogy is ever perfect, but the only logical conclusion I can reach is that software engineering is a really weird discipline relative to practically all of its "we build things that last years" peers. Its weird because, well, our organizations in my experience chronically under-invest in maintenance then act flustered when new developments don't meet deadlines or take forever; but its also weird because all of my experience screams at me "I'm not even sure if we know how to maintain systems well". I've seen this in one org (a public company you'd recognize); where years ago we had and met lofty goals like "99.999% availability"; today its a good month if we hit three-nines, API wide. In team meetings with really senior, smart engineers when we ask How Can We Improve This, you start observing this learned helplessness where they suggest small changes like, you know, adding a cache for some external API, or replacing the built-in HTTP client with some other one that has a more comprehensive knob for timeouts, or whatever. I talk with them privately and say: Is this real