The Thirty Million Line Problem
Molly Rocket11 HN recommenders · recommended in 11 months, 2018-2024
326K views · 8 years ago · talk · evergreen
Casey Muratori's long talk arguing that modern software has ballooned to tens of millions of lines because of hardware and OS diversity. He proposes a stable ISA for entire system-on-a-chip packages and recalls when games shipped with their own boot disk.
HN recommends it, long as it is, as an eye-opening rant on software complexity and why systems became so complicated.
2:50:14Simple Code, High Performance
Molly Rocket
463K views • 5 years ago
2:27:34Casey Muratori – The Big OOPs: Anatomy of a Thirty-five-year Mistake – BSC 2025
Better Software Conference
926K views • 1 year ago
22:41"Clean" Code, Horrible Performance
Molly Rocket
1.2M views • 3 years ago
38:20Twitter and Visual Studio Rant
Molly Rocket
158K views • 6 years ago
18:41Refterm Lecture Part 1 - Philosophies of Optimization
Molly Rocket
93K views • 5 years ago
42:39Bloat: How and Why UNIX Grew Up (and Out) - Rusty Russell,Matt Evans
Linux.conf.au 2012 -- Ballarat, Australia
21K views • 14 years ago
59:11How to Speed up a Python Program 114,000 times.
InfoQ
171K views • 13 years ago
59:21A Crash Course in Modern Hardware by Cliff Click
Devoxx
21K views • 9 years ago
42:15"Performance Matters" by Emery Berger
Strange Loop Conference
502K views • 7 years ago
30:12Casey Muratori | Smart-Pointers, RAII, ZII? Becoming an N+2 programmer
xDahl
162K views • 2 years ago
1:04:48"Performance (Really) Matters" with Emery Berger
Association for Computing Machinery (ACM)
7K views • 6 years ago
19:25New computers don't speed up old code
Matthias random stuff
187K views • 1 year ago
28:47Someone improved my code by 40,832,277,770%
Stand-up Maths
3.1M views • 4 years ago
32:35Scale By The Bay 2019: Bryan Cantrill, Was He Wright All Along? Software After Moore's Law
FunctionalTV
11K views • 6 years ago
45:50"The Mess We're In" by Joe Armstrong
Strange Loop Conference
398K views • 12 years ago
1:01:09Plenary: Performance Matters - Emery Berger - CppCon 2020
CppCon
32K views • 6 years ago
1:16:58code::dive conference 2014 - Scott Meyers: Cpu Caches and Why You Care
NOKIA Technology Center Wrocław
231K views • 11 years ago
2:00Shouting in the Datacenter
Bryan Cantrill
5.7M views • 17 years ago
7:16Unix and Google
FOAM
9K views • 10 years ago
40:18"Compacting the Uncompactable" by Bobby Powers
Strange Loop Conference
29K views • 7 years ago
20 comments from Hacker News
Yes, modern computer systems are unbelievably complicated from the application level down to the hardware. The consequences are absolutely devastating. ▶ this video
It's not what OP is looking for, but there's a relevant video I know of by a well known game-dev, The Thirty Million Line Problem - ▶ this video
> I'm really sold on the idea: Instead of a full-blown OS, You mean you are sold on the idea of going back to the 80s. We used to have an operating system with every game released[1]. 1. ▶ this video
It's "abstractions" that led to this: ▶ this video [The Thirty Million Line Problem] And Apple is one of the companies directly responsible for the explosion in complexity - and insanity - in modern computing. It's all so deeply entrenched - the hardware, abstraction layers, languages, culture - that it's difficult to imagine ever being able to extricate ourselves from this mess. We need another 'quantum leap' in technology, or some new paradigm...
I would say just look around, but it's probably because of some of the information I've seen that opened my eyes to it, so I'll point you to these two talks: ▶ this video Preventing the Collapse of Civilization / Jonathan Blow link The Thirty Million Line Problem / Casey Muratori
Casey Muratori proposes going back to the memory-mapped-io-as-universal-hardware-api in "The Thirty Million Line Problem" ▶ this video
Reminds me of these videos from Casey Muratori: 30 million line problem - ▶ this video Twitter and Visual Studio Rant - link
You are not alone in thinking that, see 'The Thirty Million Line' talk by Casey Muratori. (Long, but worth it, assuming you haven't seen it already) ▶ this video
That might be what OS'es currently _are_, but I disagree that it is what an OS _is_. I think fundamentally an OS is as the OP uses it, a set of code that interfaces with all your hardware to make the computer function. Heres a good talk I came across in a HN comment a little while back [1] about how games used to be developed vs how they are today. [1] - ▶ this video
“In the 1980s with things like the Amiga computer, for example, every game was a boot disk. It booted into its own customized version of an operating system that ran what it needed to run to make its game work well and be performant and reliable. … We know that in the past, hardware that was very capable and very interesting made it so easy to create an operating system that literally everybody did it. Not a few people. Not even most people. But literally everybody.” – Casey Muratori in “The Thirty Million Line Problem” ▶ this video
I happened to have read many of VPRI’s papers and some domain expertise in a few of their topics, or know close friends with such domain expertise. Btw, my collection of their links are at link The goal is a noble one; though it's unclear to me if their research is the right way to go. Alan Kay's gang's research's end result are often great, but their implementations are usually more geared toward prototyping rather than production. For example, the GUI innovation is great, whereas its implementation using Smalltalk is clearly geared toward faster iteration and not meant to be as competitive as a production language (let's not enter into this debate as this is another rabbit hole. Plenty of other HN threads on this). But I think so far these implementations have gotten a pass because the end result is futuristic enough for someone else to come along and implement e.g. the GUI in more production-oriented languages. In the context of VPRI, however, the goal wasn't to create more futuristic end results, but to recreate existing result using hopefully drastically more concise paradigms and DSLs. In this case, the implementation itself is the thing we should examine, and imo they kinda fall short. For example: - Yes, it's very appealing that Nile can reduce the antialiasing logic by so much. Is it resilient to real world requirement changes though? Unclear (and the Nile paper still isn't out as the author seems busy with some startup). - The OMeta parser tool is cool until you e
A quite well-known rant from Casey Muratori about a very similar issue: ▶ this video (For those who never saw it)
There is a related Jonathan Blow talk titled "Preventing the Collapse of Civilization" [0] that I came across recently from a HN post. You might be interested in watching it. Also, Casey Muratori's talk titled "The Thirty Million Line Problem" [1]. [0]: link [1]: ▶ this video
Have you seen the 30 million line problem* by Casey Muratori (of Handmade Hero fame)? There is an argument that a lot of today's complexity in software is an (unnecessary) byproduct of changes in hardware design. * ▶ this video
If you'd like to venture further into this rabbit hole I can recommend "Preventing the Collapse of Civilization": link And "The Thirty Million Line Problem": ▶ this video
> I think it was Casey Muratori who made the argument that we could return to having nice ABIs that are canonical APIs Here's the video I think you're referencing: ▶ this video IIRC he mentions that he actually presented the same content in person to staff at Intel, and discusses how it's very hard to get any buy-in even if the engineers consider the approach to make sense.
I think the problem is that current OSes are too complicated. What does a common user really want? I'd say text editing, making presentations, multimedia, and browsing. While these sound like simple things, text editing usually happens in a Word-like format, which - from what I've heard - is ridiculously complex. The same thing holds for browsing (simple browsers don't exist anymore, and many use the same back-end for rendering). For multimedia, USB is very important, which is a very complicated format to use correctly. Then, there are tens of codecs and formats for multimedia, each with their own idiosyncrasies and ambiguities in the specs (or deviations from the spec that are so common that they are expected nowadays). The case is even worse when your OS is supposed to run on different hardware. I think this is the main reason that Apple, in general, has a much better UX: They only have to support a limited set of hardware. Casey Murati has a great rant about this: ▶ this video
I feel like you intended to link this [0]? [0] The 30 Million Line Problem: ▶ this video The article is about Casey's work verifying collision geometry and movement code in Jonathan Blow's The Witness, to ensure that the player can't get stuck anywhere or fall through the ground or anything like that.
So now not only projects have to be maintained, we also have to maintain changes ? I'm seriously getting sick at the notion that nothing can ever be finished. Bugs? That will be those introduced by the change, nothing more. If there is any bug left, that's only because nobody discovered them yet. Having a maintainer won't change that, only usage reveals bugs. (Unless of course the "maintainer" is instead tasked with finding bugs in the first place). Bit rot? That's only an issue when the environment around the code changes. Clang is a compiler , there's not much it cares about its environment. And if you're talking about changes within Clang that could have an effect, and those are well within the maintainer's control. We shouldn't need a maintainer for every patch. This change in particular doesn't seem to introduce any new feature. I'm guessing it only allows Clang to run faster. The new code path replaces the old, so it shouldn't require much more maintenance. --- More generally, we should do away with the notion that everything should be maintained, forever. We should be able to code correct programs. We should have environments stable enough to preserve that correctness. And we should stop believing we need so much code in the first place. Let's not kid ourselves, programs "require maintenance" (euphemism for "aren't finished"), mainly because they're so damn big. We can do better, really. link link ▶ this video
This may be a little off topic, but has anybody watched Casey Muratori's proposal on SoC ISAs[0]? The video is long, but it's worth watching all of it. It sounds to me like a SoC ISA could make docker obsolete. If it ever happens, anyway. [0]: ▶ this video