Preventing the Collapse of Civilization [video]

At what point in the past were our programs stable, robust and just worked? Perhaps it was before my time, but DOS and windows (3.11, 95) would crash, constantly. Blue screens of death, infinite loops that would just freeze my computer, memory leaks that would cause my computer to stop working after a day.<p>I now expect my computer to stay on for months without issues. I expect to be able to put it to sleep and open it in the same state it was. I expect that if a website or a program errors, my OS simply shrugs and closes it. I expect my OS to be robust enough so that if I enter a usb or download a file I&#x27;m not playing Russian roulette that it might contain a virus that would destroy my computer.<p>In the past I would close my computer at the end of every day because otherwise it will simply crash some time in the night. I would run de fragmentation at least once a month. Memory errors and disk errors were common, and the OS had no idea how to overcome it. Crashes were so common, you just shrugged and learned to save often.

As a JavaScript developer I strongly resonate with the quote at 14:50 into the video. In summary all of the silicon industrys&#x27; chips at the time were full of defects and often the same defects between various vendors. The industry was completely aware of this. The problem is that the original generation of chips were designed by old guys who figured it out. The current generation of chips (at that time) was designed by youngsters working in the shadow of the prior generation and not asking the right questions because they were not aware of what those questions were.<p>A decade ago JavaScript developers had little or no trouble working cross browser, writing small applications, and churning out results that work reasonably well very quickly. It isn&#x27;t that cross browser compatibility had been solved, far from it, but that you simply worked to the problem directly and this was part of regular testing.<p>That older generation did not have the benefit of helpful abstractions like jQuery or React. They had to know what the APIs were and they worked to them directly. The biggest problem with this is that there weren&#x27;t many people who could do this work well. Then shortly after the helpful abstractions appeared and suddenly there was an explosion of competent enough developers, but many of these good enough developers did not and cannot work without their favorite abstractions. These abstractions impose a performance penalty, increase product size, impose additional maintenance concerns, and complicate requirements.<p>The ability to work below the abstractions is quickly becoming lost knowledge. Many commercial websites load slower now than they did 20 years ago despite radical increases in connection speeds. To the point of the video this loss of knowledge is not static and results in degrading quality over time that is acceptable to later generations of developers who don&#x27;t know the proper questions to ask.

I was with him until the middle.<p>Lack of inter-generational knowledge transfer doesn&#x27;t cut it. Most of the people who rolled this stuff are still alive. And as for the whipper-snappers: people don&#x27;t get very far writing programming languages&#x2F;video games&#x2F;operating systems without knowing their stuff.<p>The real boogeyman is feature combinatorics. When making a tightly-integrated product (which people tend to expect these days), adding &quot;just&quot; one new feature (when you already have 100 of them) means touching several (if not all 100) things.<p>Take OpenBSD for example: When you have a volunteer project by nerds for nerds, prioritizing getting it right (over having the fastest benchmark or feature-parity with X) is still manageable.<p>Bring that into a market scenario (where buyers have a vague to non-existent understanding of what they&#x27;re even buying), and we get what we get. Software companies live and die by benchmark and feature parity, and as long as it crashes and frustrates less than the other guy&#x27;s product, the cash will keep coming in.

Great talk. I agree that sw is on the decline. You can see it in your OS, on the web, everywhere. Robust products are replaced with &#x27;modern&#x27; crappy redesigns. We are surprised if the thing still works after 5 years.<p>I don&#x27;t agree on his conclusions. The real source of problem is that now we have maybe x100000 more software than we had in 70s. It&#x27;s that many more programmers, so not just the 1% smartest greybeards as before. We need more abstractions, and yes, they will run slower and have their issues.<p>Also, not everybody is sitting at the top of hierarchy of abstractions. Some roll up their sleeves and work on JIT runtimes and breakthrough DB algorithms.<p>All those blocks of software need to communicate with the platform and between them. IMO the way out is open source. Open platforms, open standards, open policies. Every time I found a good piece of code in company&#x27;s huge codebase, it was open source library. Every time. You have to open up to external world to produce well engineered piece of software. The lack of financial models for open source is the obstacle. We should work on making simple and robust software profitable.

The risk is that things &#x27;just work&#x27; for extended periods of time and the maintainers are optimised out of the system because they aren&#x27;t needed in the short term.<p>My personal guess at why civilisations can collapse so slowly (100s of years for the Romans, for example) is that the people who maintain the political systems do too good a job, and so the safeguards are forgotten.<p>For example, after WWII the Europeans learned some really scary lessons about privacy. The Americans enjoyed greater peace and stability, so the people with privacy concerns are given less air time in places like Silicon Valley or Washington. The two-step process at work here is that when things are working, standards slip and the proper response to problems are forgotten. Then when things don&#x27;t work, people don&#x27;t know what to do and the system degrades.

I loved this talk, and in particular the point about programmers being forced to learn trivia instead of deep knowledge. I just started a new job at a big tech company, and I&#x27;ve spent a whole week so far trying to figure out how to use the build tool. The frustrating part is that most of the software modules my team is working on aren&#x27;t very complicated. The complexity comes from pulling in all sorts of 3rd party libraries and managing their transitive dependencies.

It seems to me that there is a cultural problem that deep expertise is not valued, because it is difficult to understand and to get somebody &quot;flexible&quot; is easier.<p>I was just at a workshop about <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Design_thinking" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Design_thinking</a>. The whole premise was that you don&#x27;t actually need to hire an (expensive, inflexible) expert, who understands how something is done, but rather what you need to do is to &quot;observe&quot; an expert.<p>But imagine what happens when everybody does that! Everybody gets rid of their experts, assuming that the client (who they are supposed to provide the service for) has the actual expertise. And they are assuming the same about their clients and so on. The end result is complete disregard for expertise.<p>So expertise is a positive externality, in an economic sense. Nobody is incentivized to keep it more than neccessary. This leads to losses over time.

He briefly mentions the Boeing 737 MAX issue, but he understates the problem. Sure there was a software problem, but the urderlying issue was the whole notion that everything can be &quot;fixed&quot; (worked around) by software. That it&#x27;s fine to make changes to the plane aerodynamics and compensate with software so that it would seemingly act like the previous model.

He obviously uses Windows for his anecdotal examples, but I don’t think you can point the finger at Windows specifically. I think it’s consistent throughout OSes. I see regressions in iOS since the earlier versions, as well as in Linux and the applications I use.<p>My IDE stopped providing menus. It’s open source so I just shrug and track the issue in Github.

Fantastic talk.<p>Portable Apps on Windows are a hedge against some of the angst he describes. (E.g. the part about updates changing a lot of things around or causing failure-to-launch problems).<p>E.g., I still use WinAmp to play mp3&#x27;s. It&#x27;s a portable version, doesn&#x27;t need installation (so I can use it on my locked-down work computer). The UI hasn&#x27;t changed in 20 years. Newer file-formats can be played after adding plug-ins.<p>I&#x27;ve put together a whole bunch of Portable Apps, and nowadays I first try to find a portable version of an app I need before a non-portable version.

The repeal of Moore&#x27;s law will be a blessing in disguise, I think. Not only will programmers need to get clever in a traditional sense but, also, a new era of specialized hardware will require a more intimate understanding of the bits and pieces. I&#x27;m optimistic.

The general purposeness of computers is the reason for complexity. We use the same systems to do highly secure and critical business transaction as high performance simulation, playing and fun. The conveniency of not having to switch systems when doing different tasks is adding a lot of complexity. Special purpose hardware can by its nature of not being general, be much simpler and omit a lot of the security and complexity. But it&#x27;s much less convenient and much less flexible.

At my workplace when I ask about why some process parameters are this way it usually leads to a dead end where the people who know are long gone and those who should know don&#x27;t know the essentials. Everything is kind of interconnected and errors show up months later so you can&#x27;t really change anything on any machine until the machine as a whole breaks and needs to be replaced. Then you try to get it to work somehow and those parameters are then set forever.

I think it&#x27;s because companies always try to commoditize software developers but it doesn&#x27;t work. You can&#x27;t replace a good software developer with 10 mediocre ones plus thousands of unit tests. The only way to become a good software developer is with experience.

I remember seeing the foundationDB distributed systems testing video for the first time, and being blown away with what it takes to build robust software. Worth a view if you haven&#x27;t seen it. <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=4fFDFbi3toc" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=4fFDFbi3toc</a><p>Would love to see more things in this direction, but, I agree that the market doesn&#x27;t want it. Most users will gladly accept an infrequent bug for an earlier release, or lower cost version of a product.

Reducing all this complexity is partly why I&#x27;m hoping the Red Language project can succeed where Rebol failed.<p>Of course you can&#x27;t do everything, but a good full-stack language could cover perhaps 80% of software needs using well written DSLs. The simple fact that we have so many languages targeting the same thing is a waste and duplicative effort (Java, C#, Kotlin, Scala, Clojure, F#...etc) for business apps and (Python, Matlab, Julia, R, and Fortran) for data science and scientific programming. Also systems languages like (C, C++, Ada, Rust).<p>On one side it is good to have purpose built languages, but on another it puts a big barrier to entry.<p>Note that I&#x27;m advocating for abstractions, but far fewer languages. Yes, abstractions add complexity, but actually make the code more readable. I shudder to think of humanity having to maintain and support ever increasing levels of software.

This whole presentation feels like a great candidate for a meta analysis on the effects of recency bias on analysis.

I challenge his assertion around 32:50 that something is lost. I&#x27;ve done assembly programming. C programming. I might venture to say I&#x27;m pretty good at it. I even dabbled a bit in baremetal programming, was going to make my own OS, but lost interest. Wanna know why? Take a look at this[1] article. Yep. If, on x86, you want to know what memory you&#x27;re allowed to access; how much of it and where it is, there is literally no good, or standard way to do that. &quot;Well,&quot; you (or jon blow) might say, &quot;just use grub (or another multiboot bootloader), it&#x27;ll give you the memory map.&quot; But wait, wasn&#x27;t that what we were trying to avoid? If you do this, you&#x27;ll say &quot;I&#x27;m smart, I&#x27;m sparing myself the effort,&quot; but really there is a loss of capability, you don&#x27;t really know where these BIOS calls are going, what the inner workings of this bootloader are, and something is lost there.<p>This is a bit of a contrived and exaggerated example, but it serves to prove my point which is that these things really do scale linearly: you give up the same amount you get back by going up a layer of abstraction (in understanding&#x2F;productivity, not talking about performance yet). Low-level programming languages aren&#x27;t more productive than high-level programming languages. Low-level <i>programmers</i> are more productive than high-level ones because it takes more discipline to get good at low-level programming so the ones that make it in low-level programming are likely to be more skilled or, at least, to have acquired more skill. Think about the story of mel[2]. Does anyone honestly think, with any kind of conviction, that mel would have been less productive had he programmed in python and not thought about how machine instruction would be loaded?<p>As I&#x27;ve mentioned, I have done, and gotten reasonably good at, low-level programming, and yet my current favourite language is perl6. A language that is about as far from the cpu as it gets, on a par with javascript or haskell. Why? Because <i>nothing is lost</i>. Nothing is lost, and quite a lot is gained. There are things I can do with perl6 that I <i>cannot do</i> with c—but, of course, the reverse is also true. And I think that jon blow&#x27;s perspective is rather coloured by his profession—game development—where performance is important and it really does pay, sometimes, to think about how your variables are going in memory. He has had, I&#x27;m sure, negative interactions with proponents of dynamic languages, because he sees their arguments as (maybe that&#x27;s what their arguments are, I don&#x27;t know) &quot;c is useless, javascript is good enough for everything.&quot; Maybe the people who truly think that have lost something, but I do not think that mel, or jon blow, or I, would lose much by using perl6 instead of c where perl6 is sufficient.<p>1: <a href="https:&#x2F;&#x2F;wiki.osdev.org&#x2F;Detecting_Memory_(x86)" rel="nofollow">https:&#x2F;&#x2F;wiki.osdev.org&#x2F;Detecting_Memory_(x86)</a><p>2: <a href="http:&#x2F;&#x2F;www.catb.org&#x2F;~esr&#x2F;jargon&#x2F;html&#x2F;story-of-mel.html" rel="nofollow">http:&#x2F;&#x2F;www.catb.org&#x2F;~esr&#x2F;jargon&#x2F;html&#x2F;story-of-mel.html</a>

There is a relationship between quantity of functionality and bugginess. Even with the most demanding testing, bugs will remain. The question is, as more and more software permeates our lives, will the accumulation of unfixable bugs ultimately overwhelm us. Can we build an AI that can clean enough of the bugs out of all of our software, including it&#x27;s own, for our civilization to survive?

It seems like Jonathan Blow completely forgot about the blue screen of death and how common it was.

Now, what would be amazing would be if we had found the Antikythera mechanism so intact that it could be reconstructed perfectly. And then we&#x27;d check everything it could do, and what kinds of drawbacks or errors the construction had!

People don&#x27;t care about five 9s anymore? It&#x27;s not <i>as</i> important as it was (I assume—I wasn&#x27;t really around at the time), but cloud providers definitely advertise their number of 9s.

I had a few cocktails and thought about a few points made in the video.<p>It seems to me that there are two different notions here that are being conflated:<p>. A rotting of knowledge over time.<p>. A variant of Moore&#x27;s Law. In this case, the idea that the value of technology, in a particular area, has a decreasing value on the margin.<p>It&#x27;s kind of like the notions you see in cliodynamics, that there are a few interacting sine waves (or some other function) in mass human behavior.<p>I suppose that the main concept of importance is how it all might mess with your own personal situation. Personally, I think that the West is in decline, but that doesn&#x27;t have a whole lot to do with the quality of software on internet websites.

There is no preventing a collapse. Try and enjoy the ride :)

bravo, great talk Jon. but real talk can you make another Braid already

Not to pick on Microsoft specifically too much, but I remember seeing the hello world program for windows 3.1 for the first time and thinking, “this is not looking good.” And I was right.

Wow he has a rosy picture of the past. I don&#x27;t see where he gets the five nines from. He doesn&#x27;t even quote anybody on it. Most of the examples he gives would have been zero nines back in the day because they were not available at all!<p>Wikipedia for example has one nine availability in my life. Because when I sleep my phone is still on.