back
207 comments
I teach the systems class at Montana State, where we go from transistors up to a real computing system, and I have students that don't understand what a file system really is when they start my class

I agree that blow is wrong on some details, but I really think we need to be thinking hard around a NAND-to-Tetris style education that starts in high school for our technical students.

I use "outdated" models like Little Man Computer and a simple visual MIPS emulator which, even though they aren't realistic, at least give the students a sense of where we came from, with a level of complexity that a normal human can get their head around. When I look at modern 64 bit architecture books that get suggested for me to teach with I just laugh.

Anyway, not to say I agree 100% with Blow on everything, but connecting technology down to the roots is a hard problem.

The concept of files and file systems is useful to regular computer users, even when they have no interest in knowing how things work under the hood. The issue is with mobile OSs, and that software companies like their apps to be a walled garden for your data as much as possible, and therefore resist exposing your data as files living in a normal shared file system. Even if you already work with files, they have you “import” your existing data into their storage system, and you have to manually “export” (or “share”) any modifications as a new, separate copy.
> I teach the systems class at Montana State, where we go from transistors up to a real computing system, and I have students that don't understand what a file system really is when they start my class

Admittedly I am old grouch, but I stopped having any expectations of the current generation of "college kids".

Incidentally, I'm at Montana State getting a master's in IE, and I deal daily with this one PhD student who has demonstrated an inability to perform a simple partial derivative, which you'd think is a pretty useful skill given the subject matter. Hell, last semester in a 400-level math course, one of the students didn't understand how to add two matrices, I kid you not. It is odd that a senior in CS wouldn't know what a file system is, but that seems rather quaint compared to some of the wild bullshit I've encountered here.

My first stint in university in the 2000s felt a lot different than this, and it's a bit depressing. But man, I feel just great about my prospects in the job market next spring.

This depends on the specialization. Computer science vs. computer or electronics engineering, for example.

Computer science, despite the misnomer, is not about computers, even if computers are an indispensable tool in the field. Computer science is all about abstraction and language modeling of a domain and their application; the computing technology of the tool, however important practically, is an implementation detail. Just as it pays for the astronomer to understand how to operate his telescope in due proportion to his needs as an astronomer, it pays for the computer science person to understand how to operate his computer to the degree that he needs to. But it is a total mistake to place the computer at the center of the universe and treat it as the point of departure for what computer science is really about. This muddles things and is a source of much historical confusion in the field, and in fact, this discussion.

In fact, even the language of "low-level" programming or whatever is abstraction and language. It is simply the language of the computing device that must be used to simulate the abstractions of the domain of discourse.

I learned computer architecture using MIPS when MIPS were actually used in things. It was nice then, and is nice now.

I spend a lot of my free time decompiling MIPS assembly and small functions can be decompiled to matching C by “hand” without need other tools.

"I teach the systems class at Montana State,"

You teach and hence deal with this: "Information passed on between generations is diluted"

Is it diluted? No it isn't. Your job is teaching and books and computers help us avoid calling you a bard 8) Mind you, being called a bard is not a bad thing!

In the end this is a blog post response to another blog post. I have no idea about how "important" those bloggers are but I smell ... randomly deployed blogging for the sake of it. That's the whole point of a blog anyway. I'm being polite here ...

> When I look at modern 64 bit architecture books that get suggested for me to teach with I just laugh

Why I recommend Bryant/O'Hallaron's Computer Systems: A Programmer's Perspective (for comparch) to newbies, as coding is what most folks are likely to be doing early on.

https://books.google.com/books/about/Computer_Systems.html?i...

Actual old fashioned file systems aren’t really in use anymore, and the computerized versions hide the details, you don’t even get a command prompt on an iPad. I’m pretty sure my 8 year old has no clue what a file system is yet (I learned at about 7 when my dad brought home an Osborne with pre-DOS CPM to play around with). Computers don’t require you to know that stuff anymore just to use apps and save/get files.
When I was a child watching my dad fix things around the farm. I was amazed at his power to manipulate the physical world; welding, angle grinding, hammering, etc.

I was always amazed by the back of the television and asked him "Dad, how does electricity work?". He didn't know.

From that moment, I was imbued with purpose.

When we got our first computer I sought desperately to know how it worked and how it was built.

My first year of computer science at university was uninspiring. I learned to code but I wanted to know how people coded without operating systems, without using a computer. I was annoyed by the chicken and egg nature of it.

In my second year we did the "hardware/software" interface and read Patterson and Hennessy's Computer Architecture and Design.

When we made our way to the diagram of the basic von Neumann architecture, my childhood questions, that previously no one could answer, was answered.

The world made sense. And it was the class your now teaching that finally satisfied my childhood questions.

I'd strongly suggest having a look at the Cardiac [0] and MIX [1] computers. Shift operations are pretty important and having a dedicated multiplication/division is also very useful.

The fact that all of these are (or can be) decimal machines makes it much easier for people to understand what's going on.

Jumping to binary before you understand how a computer works is like learning logic in Latin.

[0] https://en.wikipedia.org/wiki/CARDboard_Illustrative_Aid_to_...

[1] https://en.wikipedia.org/wiki/MIX_(abstract_machine)

I've been playing around with a modern version of the cardiac, drop me an email if you'd like to collab on testing it on live students.

I completely agree, I was coaching someone recently who finished the CS50 computer science course, who had some very funny ideas about what programming was, It was very clear that they had big holes in their understanding, so I took the exact same tact with them and went through everything from Transistors to High Level Languages! I'm so glad others are thinking the same thing. It made such a huge difference to them and I was so much more confident they understood what I was saying, because it provided a baseline that I could bring them back to if they didn't understand something I was saying.
I got this exact style of education at UMass Amherst's 4 year CS undergrad degree program 2005-2010 and it absolutely made me the engineer i am today. would recommend 10/10.
If an older web developer rants about abstraction, they will target React developers.

If a Python dev rants about abstraction, they will target older web developers.

If a C++ application dev rants about abstractions, they will target Python developers.

If a firmware dev rants about abstractions, they will target application developers.

If an electrical engineer rants about abstractions, they will target firmware developers.

Drawing the line for “excessive abstraction” based on what you personally know and calling everything afterwards as “killing civilization” is quite a take.

You make some very good points here. I've watched the talk too and criticism of it is important.

I have to say though Blow is right when he says: "you can't just Draw pixels to the screen"

I am a game engine programmer at a 'medium sized' games company and it is becoming VERY difficult to hire anyone to work on graphics code. DX12 (and others of the same generation) is a massive step up from what previous generations (DX11) used to demand of the programmer. Doing anything at all with these APIs is a massive task and by Microsoft's own admission (I can't find the quote from the docs anymore, citation needed), DX12 is extremely difficult to learn without experience with previous graphics APIs.

I see a lot of people using the argument: "but these APIs are only for developers that want to really push the limits of what the graphics card can do, and want to implement very low level optimizations." and that's partially true. But it's now the industry standard and it's nigh-on unteachable to anyone without previous experience.

Unless something changes, the hiring pool is going to continue to decrease in size.

I think JavaScript on the server and React and these things has really made the web a mess of software development compared to how little stuff it actually does.

I know for a fact a bunch of kids now do not even know that HTML is what gets rendered in the browser. They think that React is itself what browsers render.

Not to mention the absolute idiot of a CEO of Vercel who thinks React is the Linux kernel of development.

Blow often makes fantastic points about development, and often completely misses the mark.

He’s accomplished great things and has ideas worth listening to - but also plenty of nonsense that’s presented indistinguishably.

I felt quite strongly that the collapse of civilisation talk was one of those pieces of nonsense, and I’ve largely ignored it (despite listening to it twice). I’m grateful to OP for providing a more principled rebuttal.

Don’t even get me started on Casey Muratori, who tries to do the Blow thing but doesn’t even get the good parts right.

There are certainly plenty of issues with the modern software landscape, and I do think too much abstraction is a problem. Yet, the opposite extreme is also bad, and people overly romanticize the past. Not only were crashes and reboots problems, not only did Amiga and such have compatibility problems between hardware versions, but even systems that strove for compatibility suffered from incompatibilities.

The fact is, even on the most unreliable modern system (Windows 11) my computer is far more reliable than any computer I had before about 2010. It can also run software written for Windows 95. That’s a very good run. A computer being usable day to day is better than one that isn’t.

Not all simplifications are abstractions. Not all abstractions are simplifications. But the pursuit of simplification is usually what motivates an abstraction. I don’t think that abstractions kill software, or civilization for that matter, but ill begotten abstractions in the name of short win simplifications, puts a drag on the flexibility and agility and approachability of either.

Take syntactic sugar in just about any language. There’s usually a breaking point, where you can say the localized gain in simplification for this particular nuance is not worth how complex this tool (language) has become. People don’t make more mistakes in a syntax heavy language because of any particular element, but because using the tool well to solve complex problems just gets difficult (regardless of what a compiler might guarantee you).

I look at the complexity that async and coroutines adds to my experience when programming anything “threaded like” in Kotlin compared to how I deal with the same sorts of problems in Elixir/Erlang and it’s just night and day difference. Both have abstractions/simplifications to the age old problem of parallel/async computing, but one (the former) just multiplies simplicities to end up with something complex again and the other has an abstraction/simplification that Just Works(tm) and really is simple.

It appears that author is from that newer generation, and completely misses points because he just don’t know. Ironically the article is an example of what Blow was talking about. similar happens if I talk about how Figma is destroying the design world on unprecedented scale by normalising bad UX, UI and product management found in Figma itself, and get responses from younger designers that everything is great, completely baffled. You have all that knowledge because you grew up in that environment. They didn’t, and not likely they can learn the equivalent of culture and experience anywhere.
Ill-considered abstractions, yes. There are a lot of abstractions that you can tell are the first draft or attempt but because of tech's "religion of speed"—and being drunk on hubris—end up shipping (vs being one of several iterations).

Then, if those abstractions are part of a popular project, other people copy them due to mimetics (under the watery banner of "best practices").

Rinse and repeat for ~10-20 years and you have a gigantic mess on your hands. Even worse, in a hyper-social society (ironically, because of the technology), social consensus (for sake of not being found out as an "impostor") around these not-quite-there solutions just propagates them.

FWIW, I love that Jonathan Blow talk and come back to it at least once per year. He doesn't say anything controversial, but deep down, I think a lot of developers know that they're not shipping their best (or guiding younger generations properly), so they get upset or feel called out.

We've just reached a state of culture in which chasing novelty has become commonplace (or in some cases, celebrated). Well-considered solutions used to be a cultural standard whereas now, anything that's new (whether or not its actually good) has become the standard.

We can navel gaze and nitpick the details of Blow's argument all we want, but the evidence is front and center—everywhere. And yes, over a long enough horizon, that can lead to civilizational collapse (and when you consider the amount of broken stuff in the world, arguably, already is).

It is unfortunate that someone needs to pick apart a flawed thesis in such detail (as the author did with Blow). The pure empiricist is equaly as detached from reality as the pure theorist, and as such Blow is making up arguments just because they fit his experience, cherry picking examples that fit his rants and promoting the exception to be the rule.
I think this post is related: We are destroying software (https://antirez.com/news/145)

I don't disagree that software engineering is not as rigorous as it was. But software has also spread into much wider area, allowing many more people to participate as programmers, all thanks to abstractions.

I'm drawn to the romantic/pure/spartan aspect of low level programming too but I also need to make a living by solving problems in practical and scrappy ways.

„ If we forget low level stuff, civilization will fall apart since we won't be able to keep vital software running.“

I argue the other way around. There is too mich complexity involved with using low level systems to model high level processes. We use the wrong tools and often model our system in a way which mimics the initial dataflow instead of discovering our domain and have a higher level understanding.

Complexity kills. And we must do everything in our power ti keep complexity to its minimum and avoid accidental complexity.

One reason I like Rust is it lets me replace a lot of high level Python stuff with faster and more correct code while also opening access a new world of low level C stuff I never had an opportunity to learn about, it’s been super fun to tinker with and I look forward to keep working with it!

Definitely good to broaden our horizons but also crucial to maintain focus…there is so much to learn, how can we balance the joy and productivity of software with the strategic imperative to build locally grown hardware?

The problem is confusing the collapse of the Western civilization and civilization per se. China is very happy to pick up the pieces. In spite of their cultural weaknesses, on this point they do teach and learn how to do everything from scratch.

The West as a dominant civilization is absolutely collapsing. It's just a matter of how long will it take. I hope China learns from our mistakes and has the will to fix their cultural shortcomings.

Abstraction isn't the problem, overabstraction is; and I suspect the reason the latter is so common is because people don't actually understand why and when abstraction is useful (and likewise, when it isn't), so they blindly apply it whenever they can, with the misguided notion that since abstraction is somehow a good thing, the more abstract something is, the better it is.
IMHO part of the problem stems from teaching without carefully stating the nature of what is explained. A teacher should check that the audience reasonably knows what 'convention' means, how it differs from 'abstraction', 'truth', 'theory', 'measured fact'...

Bonus: explicitly recognizing that many terms (along with other conventions) aren't adequate. According to the knowledge of those who coined them they appeared adequate at the time, and replacing them may induce confusions, would condemn existing knowledge and writings, and isn't perfectly effective as the new convention may even prove inadequate later. I used to say that we may consider them as tributes to the the wonderful people who coined them.

This is a very interesting take but there is an underlying issue to software. An abstraction that isn't at the software libraries/system level: managerialism. The processualizing of all the things.

Rudyard Lynch has a provocative interesting take on it.

> Abstraction fosters ignorance about low level programming.

> If we forget low level stuff, civilization will fall apart since we won't be able to keep vital software running.

There's barely anything to remember. Most of low level stuff did 180 in last 3 decades. RAM is slow now, compute is fast. Drives can be almost as fast as RAM. Sometimes it's better to do more than less to make code branchless. It's best if you can split your task into thousands of micro-threads and run on GPU.

There will always be youngsters who love to dive into machine code and low-level stuff. And there will always be a need for developers who can code low-level efficient device drivers, game engines etc.

So software abstractions is not something I worry about when it comes to the survival of civilization. Nukes seems to be more of a real threat IMHO.

No it’s not. Software is killing the US and not because it abstracts low level stuff. It’s because it abstracts reality in such a way that the US is becoming a nation of software engineers ignorant of even how to build the stuff it programs. We’ve moved up the stack and moving up the stack requires people knowledgeable about the bottom.

One can’t exist without the other so the world isn’t getting destroyed. China is handling the bottom of the stack. And by understanding the bottom of the stack they also become good with the top.

I used to hear shit like China only knows how to manufacture stuff the US is good at design. And I keep thinking well if you submit an entire design to China to manufacture you don’t think they will figure out how to design? Knowing how to design is easy. Manufacturing or turning that design into reality is hard.

Software isn’t killing civilization. It’s killing the US and that may seem like the world if you lived here all your life.

Abstraction is a way to move work onto machines to make us humans more productive (at least that’s the plan). Machines do insane amount of useless (ok, highly inefficient) work to allow us to save some brain effort. Sure, some abstractions are counterproductive and add to complexity rather than making it easier for us. I’d argue it’s a minority though.
No need to worry: there are amazing optimizations happening in the software and hardware world, but outside the US - unless you don't consider these places as being part of "Civilization"
This feels like plumbers thinking that using some weird type of toilet fitting is killing civilization.
In a sense, I wrote an article about this exact thing: https://jonpauluritis.com/articles/4000years/

While fun to talk about, there really isn't a danger

I miss assembler and maximizing code efficiency to juggle 2k of ram.
In a sense abstraction does. You stop learning the fundamentals of how something works. Long enough as time goes by no one knows how the fundamentals work and a company fails.
As somebody who works in embedded, and does kernel programming and low level networking, I wish any of Blow's fear mongering was true. It would do wonders to my feeling of job security and self importance.
> I'm not a historian and will not comment on this first part of the talk. It doesn't matter much,

Okay.

> What is robust? ... Is it the multi-year uptimes of a plethora of ...

Big uptime systems are dubious. Probably a lack of kernel patches, hardware patches, and who know if, on reboot, the system will actually boot and start the relevant services correctly. A bank once had their mainframe fail, and they were flailing around for a good long while, possibly because it had been about a decade since their last failure and everyone forgot what to do, or maybe Bob had retired. Or how about that host that boots four years into the future and now various things are quite broken? There was NTP, but an unrelated change had broken that on some firewall. "Normal Accidents" are somehow a thing in complex systems, as are black swan events. Quite possibly either or both were involved in the late bronze age whateveritwas, but naturally history doesn't matter much.

> Oh, and garbage collection and functional programming aren't new abstractions. Lisp did both in the late 1950s

PAIP (Norvig) recounts that the garbage collection was so bad it was turned off and the LISP machines were let run until they ran out of memory, at which point they were rebooted. I guess this is a point for improved robustness in certain areas, though there are probably still "/5 * * * reboot-something" type cron jobs out there for services that leak too much memory. No, management did not grant time to fix that service last I had to put in the most recent five minute reboot script. Many don't get such a intimate view of the rusty bowels of the internet.

> open up a Unix-type command line in Linux/MacOS/*BSD/WSL, type "ed" at the prompt and see how far you get with your text editing

Some wacky systems do not install ed, or link it to nano or some other nonsense, so you may need to actually install ed to get the standard editor. If you happen to be stuck on such a system, `busybox vi` is tolerable—vim gussied up with color spam is not, especially the unreadable blue on the black console—though learning enough about ed might be good if you, hypothetically, ever have to fix an old system over a serial line at 3AM in the morning. There isn't much to learn for such cases, "a" to append new lines, "." on a line by itself to end that, "/foo" to search, "c" to change that whole line (and then the "." thing) and then "wq" to save. Great for edits were you don't want other folks seeing the contents of, say, /etc/hostname.wg0. Or sometimes a cat of the file should be done to preserve it in the scrollback buffer, which has saved a non-zero number of configuration files across the internet. Ideally this sort of disaster training should be practiced by some now and then, but that does take time away from other things.

Back to the unloved history thing. A collapse can take a few centuries, which may be a problem given the recent emphasis on the current sprint or how the stock will be doing Tuesday (as opposed to the lease for Hong Kong, though a hundred years is a magnificently short period of time). So a few folks crying wolf or playing Cassandra might be a good thing to help point out past issues and maybe from that future shocks can be made less bad.

And of course one should beware the C people.

Killing or just another risk? As far back as the 80's or 70's there was the idea of losing ball bearing manufacture capability as a risk to society and civilization. I'd think the lack of a systemic defence to amplified mis and dis info is might higher in a list, with application of another software abstraction (merkle trees) being part of the solution. Well, defence of rule of law perhaps and less about layered technological aspects of civilization.
Billionaires are killing civilisation
Why stop here… not say easy access to clean water is destroying your health. Should walk two miles to the watering hole, carry it back, collect wood for fire and boil the water your self…

\s

No

https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...

Of course not

And if it were it wouldn't be something

c or c++ related but all the banks and unemployment systems still written in COBOL