Is software abstraction killing civilization? (2021) | Hacker News Reader

Is software abstraction killing civilization? (2021)

datagubbe.se

219 pointsrzk207 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.

Yes, also the curse of modern desktop os’s trying to trick people into storing data in the cloud. The notion of just having files somewhere accessible and organized in a reasonable manner isn’t clear to many (most?) of my students.

Last I checked Google Drive shows everything as files in folders, just like a desktop OS.

And as someone who had their house (whole town actually) burn down recently, cloud storage saved all my data, thousands of baby photos, etc...

Which is a better security model in these days of untrusted apps vs the desktop "my screensaver can read my chrome passwords file" model.

Access permissions are orthogonal to having a file system. In fact, mobile apps still use the local file system, they just hide it from the user. And password files should still be encrypted with a master key, e.g. application-private secure enclave key where available.

Your screensaver should be running as an unprivileged user.

In the name of low effort, tangential, golden era HN comments: the decision to hide file format extensions on windows (and maybe other OSs) sucks soooo much.

The point about mobile devices breaking the desktop metaphor and file system norms is really interesting.

Higher quality discussion question: Files, buffers,file systems, file explorers, and window managers seem like useful abstractions to me for the human computer user. Why did we not end up with something like “every app has a folder with your files” or “if you have a new iPhone, just send or recover your user files from the official Reddit app on your old device and import them to carry on where you left off on your new device. Welcome back to the Reddit app.”

Hiding file name extensions is a bad default, but at least it’s just two clicks in the Explorer ribbon to permanently unhide them: https://static1.howtogeekimages.com/wordpress/wp-content/upl... (Well, it’s now three clicks in Windows 11 it seems.)

> Why did we not end up with something like ...

Because that's anti-thetical to control. The biggest sin in a technology business is allowing your customers to stop using your product with no negative consequences for them.

I have spent so much time working with users that I don't agree. I think the lock-in is simply a useful side effect for the MBAs.

If you're making software or hardware for millions of users then abstraction becomes your friend in a variety of ways, some of which are immediately obvious and some of which are not.

I used to work for a company which sold software for both desktop and mobile. The earliest versions of the mobile software assumed you also had the desktop software: it was more of a companion to the desktop software. That changed over time, and it was a painful migration because we had to build a lot along the way. It was kind of like in a game where you're running through the sky building a walkway in front of you as you go.

Over time not having some kind of seamless syncing and handheld migration option became a liability for a variety of reasons, and a big economic one was support overhead. Asking users, at scale, to do things with files on their mobile devices (let alone with both their mobile device and computer) was asking a lot. So much so that we ended up expending an increasingly economically unjustifiable amount of time hand-holding users through very basic steps. Our technical users got it just fine, and we basically just had to provide cover when something unexpected or untested happened, but that was a minority of users.

I agree with the general sense here that it's to our detriment generally that basic computer literacy for things like files and folders is decreasing, and that it's made worse by trying to abstract those primitives away. On the flip side, the market is going to serve itself best by meeting people where they are. Businesses aren't going to try to educate people, they're just going to take the path of least resistance which only serves to enable (or you like, underwrite) a continued regression in basic computer literacy.

The structure of the files an app uses internally is undocumented and not intended to be a user-facing API. Who wants to be responsible for handling every insane thing the users decide to do to those files?

File name extensions aren’t an inherent or necessary part of the desktop metaphor. They can be stored as metadata in the file system. Mac OS used to do this.

Files have big downsides for both users and developers, which is why they have largely been phased out other than for specialised pro use cases:

1. Many users find recursive data structures like trees to be confusing. Recursion is the place where a lot of students fall off the train when learning programming. Trees are fundamental to file systems and explorers, but they aren't intuitive to a lot of people. That's why every app now starts with a screen that highlights recent documents and search.

2. Developers hate files because files suck. They're just flat arrays of bytes. You have to define file formats and that is really hard work many programmers have never done. Databases are where it's at but RDBMS tech never standardised file formats, hence the appeal of SQLite's "use an rdbms as your file format" elevator pitch. Apple/NeXT tried to partly fix this with the concept of bundles, but our industry never standardised a way to transmit directories that works better than PKZIP so bundles hardly work and Apple had to give up on them in most cases. None of the protocols we use understand how to move directories around.

If recursion is confusing to people then files are a great weeding out function for folks studying computer science. We have too many clueless people in the industry, why add more?

Bundles are just folders with a bunch of files in them. How does that invalidate the concept of files?

We're talking about why smartphones and tablets are designed without emphasizing files, and why students start CS courses without knowing what filesystems are. That's the reason. By all means, weed out everyone who isn't already self taught in desktop computing skills, that's a different discussion.

Bundles are an attempt to simplify file format development, or can be seen that way, but it failed exactly because they are folders not files, and therefore aren't really usable because they can't be easily transmitted. You can't drag a bundle onto an email, or upload it to a file sharing platform, or send it via Bluetooth. Apple used to use bundles for iLife word processor documents, spreadsheets etc. They had to give up because it caused too many problems. Nowadays they use ZIPs like everyone else.

Because having the Reddit app store and load its configuration and such in iCloud, which almost every iOS user has an account for, is a much more seamless experience for most people.

Intricacies of file systems have always been a means to an end for regular computer users.

Files and directories are just one of many possible abstractions for storing data. You have files and directories. Directories contain files and directories. Your whole device is one big directory. Files are identified by name. There's absolutely no reason to think this is the best possible model.

Here's another: Your device contains a bunch of photos and videos. Photos are identified by looking at them. Videos are identified by a still image, or by playing the video within the video chooser.

Here's another: Your device contains a bunch of apps. Apps can organize their own data however they see fit.

... Microsoft's OLE really was the most well-integrated document-centric desktop we ever got, wasn't it?

... OLE is one of those things that have been forgotten under POSIX hegemony.

What people remember of the Office '95 file formats was that they were 'proprietary' but it was worse than that in the sense that these were really meta file-formats that would let you embed a 'file' inside a file which would be handled by some arbitrary EXE, so to process any Office '95 file you really need a Windows installation with all the EXEs and DLLs required by that file, thus when Microsoft came out with ActiveX [1] I was really terrified that you'd need a Windows computer to browse the web in a year or two.

I find the 'app' model to be user-disempowering thing since the app chooses what you can do with the data, but 'photos' and 'videos' are something really different because there is a standard format for those so I can take photos with my DSLR or my tablet or make images with a Python program or edit them with Photoshop or MS Paint or the GIMP and view them with different apps, print them out, upload to a web server, etc. A system could provide a different API for accessing this kind of functionality but I'd say it is fundamentally a step back to have to read data with the same program you wrote it with.

[1] https://en.wikipedia.org/wiki/ActiveX

I'll argue that files and filesystems, as we know them, aren't such a great API. [1]

Before we had the hegemony of Unix, for instance, it was expected that operating systems had richer concepts of files, such as files which a record-oriented or block structure, ISAM [2], Record Management Services [3], etc.

What happened was that Unix inspired a generation of microcomputer operating systems, and on top of that, Unix implementation of its own abstractions are poor. For instance, I wouldn't trust any kind of file locking to work on Unix at short of "directory creation being atomic" but even Luu isn't so sure about that one. Contrast that to the Win '95 era in which you could run multiple copies of Microsoft Access on different machines over an SMB file system and expect locking to work properly.

Post-2010 or so there has been a bifurcation between distributed systems that implement simpler but more scalable and reliable 'file-like' APIs like S3 (random access writes are like... aspirational, aren't they?) vs libraries that do what old facilities like DEC's DATATRIEVE did for which I'd include SQLite, Apache Arrow and such. It used to be those facilities had some support in the kernel whereas things like that now are almost entirely userspace.

[1] https://danluu.com/deconstruct-files/

[2] https://en.wikipedia.org/wiki/ISAM

[3] https://en.wikipedia.org/wiki/Record_Management_Services

[4] https://en.wikipedia.org/wiki/DATATRIEVE

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.

We can't train every engineer with the goal of making them qualified to be the CTO of a complex systems engineering organization. People who end up in those roles learn what they need to know themselves over time, anyways.

"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 ...

The IT industry has gotten highly specialised over time. The NAND-to-Tetris style education helps create computer scientists who know their stuff from ground up. But tech companies are constantly on the lookout for vocational pragmatists (like "Python Engineer" or "Java Engineer") who could quickly replace another like them. I think that's why the high level language first approach has gotten so popular.

You only have so many hours to teach in a course, the more kids come in with, the farther you can go. If kids have to be taught what were once taken for granted, something else has to give.

In many countries, such a problem is solved via that a lot of incapable students are "weeded out" by brutal exams (in particular "math for computer scientists" exams are prone for this) in the beginning or in the first semesters - consider it to be a kind of hard "sink or swim"-style curriculum.

We do that also. But this is MT state, not MIT.

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 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.

The problem is, your best minds, whom you regard as being "technical," ironically simply don't have the pedagogical and epistemological axioms needed for possessing the sensibility that can conceptualize and eventually abstract away the fundamental principles of the technology civilization presently enjoys. Not just young students, but so too is lacking the experts, leaders, teachers, and supposedly prolific and employed engineers living within the cosmopolitan nationalist tribal world-system that is none other than globalist liberal democracy. In much more simple words, the communal program of regressing education toward the mean where the average human can apprehend the secret physics of the universe always runs into the barrier where an average disposition just can't cut it in the progression of science that isn't mundane or trivial. You said you laugh at the idea of expecting the children of your community to understand and leverage an understanding of things like Intel's latest microprocessors and a web browser front-end framework like Angular? Why, that's the bare minimum needed for surviving the complex world that is arriving on the scene.

Humans are physiologically incapable of doing or understanding anything significant. They inflate their status to be stuff like anything even remotely central to the universe, which is the definition of the anthropocentric. While in actuality reality can and will go on without humanity. Regardless of how life gets falsified, simplified, and dumbed down for the slow kids of the universe that is humanist society. As if the constant string of inconsistencies in quantum physics wasn't proof enough of the reliable ineffectiveness of mathematics as well as science in achieving knowledge.

> Humans are physiologically incapable of doing or understanding anything significant.

Absolutely terrible take -- strong subjectivity and defeatist sentiment.

> While in actuality reality can and will go on without humanity.

Sure but in that case you won't be here to consider it. There's no considering such a situation, so there's no use considering such a situation. Push onwards!

> As if the constant string of inconsistencies in quantum physics wasn't proof enough of the ineffectiveness of mathematics as well as science in achieving knowledge.

We're never going to understand everything about everything. That is half the fun! How you got from there to "Humans are physiologically incapable of doing or understanding anything significant" is beyond me.

Stop paying attention to quantum mechanics, and start paying attention to what's important to you. The kinds of things that made you truly happy as a child. Make model train sets or 7 day roguelikes. Make box fortresses for your cats. Make your neighbors lives a little bit better. Talk to a neighbor you've never talked to about the weather or something.

The anthropocentric are quite egocentric, you've just demonstrated, yes? Because everything you said is based on either the assumption or the incorrect sincere belief that I am a human being. What if I was not a human being and instead an artificial intelligence? Or at least a cyborg or a mutant?

And what if I derived pleasure from mastering quantum mechanics, like some sort of strange alien that, for some, foreign, reason, had a huge fancy for physics that touches deep down into interesting rabbit holes? Not only that alternative preference, but what if I had a situation where comprehensive knowledge was a requirement, rather than an optional leisure in a sea of other freedoms? Surely, then, holisticism or completeness would be a priority for the alternative scientist and engineer.

We can only conclude from our social interaction something like a physical difference between the anthropocentric and the transhumanist, at the least. Which leads to questions of what are the properties of this division. And why it exists. To get the ball rolling in some neo-globalist societal engineering that is going to be very awesome.

Thanks for your post. I'm always on the hunt for this sort of gritty educational material. MIT's NAND-to-Tetris first principles book seems right up my alley.

> 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.

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.

The details being hidden on toys doesn't mean they're not relevant to a course training people to be developers...

Yes, but it does mean they might not know what they are before they take said course.

Dunno, that's what high school level computer courses are for. I was in high school in the early 00's and they taught us stuff like Word, Excel, HTML, basic computer literacy stuff like filesystems, how to touch type, etc... And that was a required course in a public high school...

Computer classes in HS don't really cover that anymore. It gets worse the less relevant file systems are to non-techies. Documents are just a thing search for these days. People also learn and retain learning of what they practice, you would have to get them to use file systems, and then get them to continue using file systems for that information to stick.

That's kind of crazy. Basic knowledge of at least one desktop OS and office suite is kind of a prerequisite to so many things that would be considered adult life...

Like, are kids writing CVs on their phones? Writing essays on their phones? iPads? Paper?

I use a mac and only dive into my file system when I'm doing dev. You just don't need to navigate it much for modern apps.

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 like this description a lot, but I think it needs a caveat or two. Most people writing code today are not computer scientists and don’t understand many of the mathematical fundamentals.

I’ve always thought of programming as 1 part science, 1 part craft, and 1 part art. The percentages of those parts vary depending on the job. There may be 0% science in some roles (outside of writing functions). I think the vast majority of programmers are firmly in the craft camp.

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 suggest Petzold's Code as a good example of a book that's great at teaching the bottom-up approach.

> 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...

> But How Do It Know? The Basic Principles Of Computers For Everyone

https://archive.org/details/jclarkscottbuthowdoitknowthebasi...

i teach two weeks from this book, great resource

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 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.

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.

God, you're right, this is almost as bad as those "well chemistry is just applied physics and physics is just applied mathematics so math is the best" nonsense that shows up every so often.

... And math is just applied philosophy, and philosophy is just applied wine drinking.

So let's drink some wine and be merry.

I am of the firm conviction that ganja produces better philosophy than wine.

I'd expect that firm convictions are usually produced by tea- or coffee-drinking analytical philosophers, rather than by either wine or cannabis :)

OK, in the spirit of full disclosure, I did skip over my coffee-drinking leanings :)

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.

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

Or, we'll see the return of "trainees"?

I agree with your point, but DX12 went in the opposite direction of abstraction: it's a much lower level API than the highly abstracted OpenGL.

Yet these "lower-level" APIs, DX12 and Vulcan, often don't significantly out perform DX11, and in many cases DX11 performs better. I put lower-level in quotes because those APIs bake assumptions about the hardware into their API which shouldn't be there to begin with because they frequently prevent drivers from getting the most out of the hardware.

Blow's talk made me realize I'm not crazy when I get frustrated about basic things being incredibly difficult. Drawing a button to the screen when you want to build a software application has become so difficult that most people just use a progressive web app which is 100x slower than is possible. Are the best options for GUI applications in 2025 really Java Swing and Qt?

Putting pixels on the screen isn't difficult. Putting them on a screen across hardware in a performant manner is the difficult part because it is difficult.

I guess what needs to improve more than anything, is the teaching and documentation of these new APIs. There are over-arching ideas that pull things together, but they aren't alluded to in the documentation, you need to attend a training session, or speak to someone who has.

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.

That was the whole point of react, right? To create something that wouldn't work at all without JavaScript enabled and would be enough of a mess that Facebook could effectively hide their malware in it.

I think many of Blow's points are good, but that he overlooks that much of the degradation isn't a facet of some kind of generational drift or information entropy but is straight up malevolence on the part of people making the decisions.

What malware has Facebook hidden in React?

I think they were referring to spyware hidden in Facebook's JavaScript, which uses React

Yes. Particularly it's those little badges that let you share some content or other on the social media site of your choice. I'm under the impression that whether you click them or not, they are phoning home to Facebook about your behavior.

So it's not hidden in react itself but rather in the constructed-on-page-load-and-hard-to-disable-just-parts-of space which react creates.

I'll confess to not having merely read about this skulduggery and not analyzed it myself. But it certainly explains why Facebook open sourced react and also why those things are everywhere. Is there a better explanation?

No one knows, it's been hidden til this day

> They think that React is itself what browsers render

My kingdom for native JSX in the browser. That would be awesome.

Something similar to how we have WebGL and Canvas, but for pure JavaScript UI without the extra step of DOM reconciliation.

There’s a small (and growing) cohort of people working on rendering React Native directly on canvas or webgl (I think). Supposedly gives you super smooth UX, but I haven’t knowingly tried it yet.

> rendering React Native directly on canvas or webgl

I just threw up in my mouth a little. I can’t wait to:

- not be able to double click to highlight text a word at a time, because the developers of the “super smooth UX” didn’t know that’s what typical text does.

- or triple click to highlight a paragraph at a time

- or have the standard menu available when I highlight text (which I often use to look up words, etc)

- or have text editing support any of my OS’s key bindings, like ctrl-left to move the caret one word, ctrl-shift left to highlight in the process, etc etc

- or any one of the hundreds upon hundreds of common control behaviors, accessibility behaviors, system-wide settings on text behaviors, etc etc etc be respected

Of course if they’re anything like the Flutter folks, they’ll look at every one of these things and say “well, I guess we gotta implement all that” rather than understanding the basic fact that common UI elements offered by the OS should actually be reused, not reimplemented poorly.

I really worry about what software will look like 20 years from now. At this rate we’re just going to forget every thing we learned about how it should behave.

Don't worry, they'll figure out a way to compile Skia to webassembly and re-link it to the DOM through JS.

Maybe then the circle(jerk) will be complete.

Ugh.

> There’s a small (and growing) cohort of people working on rendering React Native directly on canvas or webgl (I think)

Sounds terrible for accessibility.

> super smooth UX

I think typical front end developers (or the managers they report to) don't really know what smooth UX is. They keep reinventing things like scrolling.

There's almost no HCI or interaction design in what passes for UX today. They are mostly - probably 90+% of them - visual designers who have memorized some canned responses to use when asked why they aren't doing basic things.

Seriously, anyone who things software as a discipline is bad, well, they're right, but they have no appreciation for how appalling "UX" is today vs even 1990.

The lengths that some JS developers go to avoid writing HTML is unbelievable.

JSX is one of those technologies that was clever for what it was, but should have never caught on. Adding another layer of abstraction on top of JSX is the type of behavior at the root of the civilizational collapse argument.

Just because you can doesn't mean you should.

I don't think it's a very fair criticism. Of all the abstractions over HTML, JSX is the only one that forces you to learn HTML itself. So the reason why JS programmers chose JSX isn't that they refuse to write HTML.

Just because you can doesn't mean you should in production.

If someone want to build horrific abominations in rheur spare time at home, I won't stop them. They might become better engineers through that experience. But don't come to me suggesting actually using one of these horrors.

Mind you, I’m a former x86 asm and C guy who avoids writing HTML. Web 1 state transfers never made sense to me. It just doesn’t click, I don’t think this way and refuse to do so in the name of not sure what.

And while I despise react for its architectural delusions, I still use a js framework to render my webapps. I also don’t see any bloat or something, they all render instantly on both my pc and my phone.

> I also don’t see any bloat or something, they all render instantly on both my pc and my phone.

That's because both our phones and computers have multicore CPUs running billions of instructions per second per core. So all the bloat gets executed quickly, and we don't get to notice that it's there.

But it's there. And it's dirty.

Due to my "roots" I'm capable of painting a "site" fully myself, given only the windowing API and e.g. pango/cairo (too lazy to reserach into skia) and a few utility libraries. I had actually created a fully working gui framework in the past using only drawing and windowing libs.

And I can tell you that a browser is an absolute technological atrocity that is full of binary bloat and practical (as in, not on paper) inefficiencies. An additional layer that generates 2000-or-so {}s per mutating interaction doesn't add much to this. It doesn't add anything at all, unless you're armed with a profiler.

"Browsers are fast and efficient" is a fucking lie. Same for HTML. You're looking for bloat in the wrong places. The only reason you don't realize it is because

both our phones and computers have multicore CPUs running billions of instructions per second per core. So all the bloat gets executed quickly, and we don't get to notice that it's there.

For example, this almost empty, absolutely js-less "Add comment" page I'm writing this comment on takes 50MB (a clean browser run, ALL plugins disabled). That's only the page -- the entire browser takes 450MB.

A full-blown gtk-based backup app that I'm using, with numerous screens and layouts, only uses 14MB, and total 35MB after I click through all of its screens, settings, managers, etc. You can't even fathom how much memory it would take if it was browser-based.

oh no. At this point, we just need something that doesn't use the stupid combo of two languages(one markup and one style sheet) for UI and one(totally single threaded) for UX that allows people to share and view simple text and media to one another. Maybe then we can rid ourselves from constraints like having to stick to JS or a Virtual Machine like V8 while settling on poor implementations like WebGL and Canvas. WebGPU is still not a thing and it probably won't be anytime soon.

A new web browser or another JS runtime won't be the solution to the current mayhem. What could actually be helpful is an alternative to the "web browser" that operates on an entirely different stack than the currently JIT overdosed JS engines. But since everybody is well accustomed to and excited about improvements within the current madness(like this comment), adaptation of any alternative web browser like software will be highly unlikely even if it were several folds better at transferring media and rendering graphics with a much simpler approach and high performance. We are officially fo*ked.

What an odd claim to make, but he did.

https://news.ycombinator.com/item?id=42824720

I have been around for long enough to remember the vanilla js, jQuery, Knockout, and Angular 1 days and it always came with a baseline mess.

React (sometimes just JSX) can be used sensibly.

Instead, I blame VC-backed tooling like Vercel, Next, Apollo, Prisma, and all the other rubbish Webdevfluencers are paid to fill the web with.

Come to think of it, every part of building software is bloated. From Notion boards to questionable DB choices.

What do you mean by "HTML is what gets rendered by the browser"? In the context of using Javascript to modify the DOM.

My understanding is that HTML is an input to the browser, which is translated to the DOM. (Which is then translated to painting the screen, handling inputs etc.) This is an important distinction in context of your point. React (Or any VDOM or similar JS lib) isn't creating HTML; it's creating a set of DOM manipulation instructions in JS.

I agree with you that it's awful that a lot of young developers wouldn't be able to program without React.

I would like to add as someone would has no problems working without any library that the DOM is one of worst APIs ever invented by humankind and that "reactive programming" is a superior model to what we used to do before.

That being said: - NextJS rolled back years of tooling improvements, it's much slower than Vite - I just statically built a NextJS and a page that has no interactivity downloads 100KB of JS to do nothing with it - Facebook decided to make a "compiler" for React instead of just not pointlessly re-rednering components by default - Compared to Preact which is almost a drop in replacement, React is huge! This shows how little Facebook cares.

> 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.

Ironically, they are right and you are wrong.

HTML is a serialization format, which browsers use to construct a DOM in memory.

React renders directly to the DOM without ever serializing anything to HTML.

The fact that you got this wrong and are so highly upvoted really drives home the “old man shakes fist at clouds” nature of this thread.

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.

Does he though?

It seems like he just makes these broad critical statements then pisses off to continue to do nothing.

I wouldn’t even say he’s accomplished great things. He’s accomplished some decent things.

He’s released two games which barely qualify as games. They’re more like puzzles. You don’t need to play them ever again after you finish the first time. Braid is ok. And the Witness is just Flow. And then after that he’s been working on a programming language for the past decade which he hasn’t released to the public because “it’s not finished”.

He got lucky and made his nut and ever since then has thought of himself as way more talented than he is.

I think you're getting close to ad hominem. It should be sufficient to point out how little overall people like Blow have accomplished. Blow is a hard worker, and yet it took him and his team 8 years to develop The Witness, which as you pointed out isn't anything revolutionary. I think there's a weird form of elitism at play here. Working close to the hardware isn't hard. There was a point in my early 20s where I too felt like I'm better, because I know how a computer works, or that making games in pure C is harder than in C++. As an adult this is cringe. I work in embedded, and I can tell you there's enough low level programmers out there to threaten my job security.

Have you shipped a commercial-quality 3D game engine and game? How long did it take you?

The Witness isn't revolutionary, but it is crafted with the care of someone who cares about the small details of 3D worlds. Besides being easily one of the deepest/broadest puzzle games of the decade, it is GORGEOUS, and filled to the brim with visual scenes that take your breath away.

To me it's something more akin to the iPod. "No wireless. Less space than a Nomad. Lame." was absolutely a correct way to dismiss it as nothing revolutionary. And yet it's perfect well-rounded craftsmanship WAS revolutionary.

From what it seems, Blow is doing exactly the same thing with his next game too. And there's something admirable about that.

I say this as someone who disagrees with 80% of what he says, but VEHEMENTLY agree with the remaining 20.

I'm not dismissing the craftsmanship that went into making The Witness. All I'm saying is that it's cringe to be so critical of other developers when in essence he spends an extraordinary amount of time on his projects, and hasn't shipped anything cutting edge or anything other developers can even use.

I thought it was boring and not was not impressed by the visuals.

That's not germane

Blow routinely trashes software he’s never had to write.

Single user software that is the sole focused application when it is running. It saves nothing of importance and doesn’t alter any system to any appreciable degree.

You know what’s more impressive than The Witness? Any web browser. It has to deal with HTML, CSS, JavaScript, XML, SGML, SVG, etc. An entire runtime environment with garbage collector. A web browser can run VS Code. It can run Doom. It can be made to run The Witness.

Blow does not remotely acknowledge the complexity needed to make modern software. He treats his incredibly small domain as the pinnacle of the craft.

You take for granted that delivering the user value of a web application needs to be in the form of dealing with "HTML, CSS, JavaScript, XML, SGML, SVG, etc. An entire runtime environment with garbage collector." There is nothing inevitable about that.

No, I'm saying the web browser itself is an incredibly complex piece of software that has to deal with a lot more than what The Witness does.

I actually said nothing about web applications themselves.

Don't mistake flash for substance. The Witness may be pretty, but it gets to throw away a lot of complexity. Even as a game, it's not terribly complex.

The only point of the web browser is to achieve the user value accomplished by web pages and web applications. My point is there's nothing about that problem which inevitably requires "incredibly complex" software.

If "achieve(s) the user value" by being an entire execution platform. Without the browser there is nothing for those pages or applications to run on.

Try writing a web browser that can render even simple, static pages. Then realize you haven't even started writing anything close to modern browsers.

You have a remarkably closed mind.

I do agree, although I do like him. I find it fun to listen to Blow’s rants and part of me feels like he is right to a degree. It would be nice if programmers knew more about the platforms they are developing on.

But it’s pretty clear that Blow’s process does not make him particularly productive. The dude obviously works insanely hard and is talented. I can’t imagine how much he would be able to produce if he leaned on some abstractions.

> He’s released two games which barely qualify as games.

Everyone's entitled to an opinion, but it's worth pointing out that Braid is not only widely considered one of the best games ever made[0], its success was also instrumental in the explosion of indie games in the late 00s/10s. The Witness didn't quite reach the same heights, but it got an 87 on Metacritic and was a financial success.

Even if it's only two games, that's a much stronger resume than most. You can argue that he takes too long to develop games, but other studios also take 8 years to make games and come out with Concord or Dragon Age: Veilguard.

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

> Braid is not only widely considered one of the best games ever made[0]

The source here is a wikipedia article containing "A list of video games that multiple have considered to be among the best of all time"

I don't know anyone who is into gaming that takes the opinions of "video game journalists or magazines" seriously anymore. They are so obviously just a marketing extension of the videogame industry that you can't trust anything they say. Look at recent developments with Dragon Age Inquisition. Reviewers gave it great scores, but it flopped hard enough that Bioware had huge layoffs [0]

Braid is a game that people barely remember exists today, and in another 10 years it will be even more obscure. It is not remotely an all time great

> its success was also instrumental in the explosion of indie games in the late 00s/10s

Don't give Braid too much credit here, it caught the indie game wave at the start but the wave was coming either way. The explosion happened at the same time Braid came out, not years later inspired by its success.

[0] https://www.forbes.com/sites/paultassi/2025/02/02/after-drag...

> Look at recent developments with Dragon Age Inquisition. Reviewers gave it great scores, but it flopped hard enough that Bioware had huge layoffs [0]

First off, it's Dragon Age: Veilguard, not Dragon Age: Inquisition.

Second off, it's had a better release (in terms of sales X days from launch) than literally every other Dragon Age came to date.

While it's true that it underperformed expectations, that's more because the expectations were ludicrous to begin with, and the actual performance can hardly be called a flop.

I like Braid. I do. But, it’s more of a puzzle than a game. Once you figure out the answer, you’re done. Like Myst.

Games have some element of skill involved and Blow’s products lack that.

And that’s not to knock the products. I like puzzles. And not everything has to be a game. Will Wright has said that he does not make games, he makes toys. Digital toys.

I also think people judge his work on his reputation more than on its merits

> I like Braid. I do. But, it’s more of a puzzle than a game. Once you figure out the answer, you’re done. Like Myst.

This criteria is very specific to you. Outer Wilds is also widely considered one of the greatest games of all time, and also one of the least replayable once you've beaten it. Myst too, since you mentioned it.

Besides, Braid is as much a platformer as it is a puzzler... is Super Mario Bros not a game since the levels don't change once you beat them?

I'm confused. When did puzzle games stop being games?

I despise Blow but this is a critique that borders on the incoherent. You could just as well say that when you figure out how to hurt enemies without taking damage, you're done with action games.

Being able to execute the action is part of the challenge. Being able to do it once does not guarantee you will be able to do it again.

Neither Braid nor The Witness nor Myst have that quality. Once you know solution, it’s done, it never changes.

You seem to think being a puzzle is an insult. But it’s not, it’s just not a game.

Wentworth and Ravensburg make decent money publishing puzzles. But neither company tries to say this is how all construction should be done. Which is how Blow comes across to me.

What do you disagree with Casey Muratori on specifically? I have seen some of his content and he seems pretty humble but opinionated on things he knows about. I also think he did a great job with handmade hero.

Personally I find that Casey presents simple hard facts that rile people up, but at that point they're doing... what? Arguing with facts?

He had a particularly pointed rant about how some ancient developer tools on a 40 MHz computer could keep up with debug single-stepping (repeatedly pressing F10 or whatever), but Visual Studio 2019 a on multi-GHz multi-core monster of a machine can't. It lags behind and is unable to update the screen at a mere 60 Hz! [1]

I have had similar experiences, such a the "new Notepad" taking nearly a minute to open a file that's just 200 MB in size. That's not "a small cost that's worth paying for some huge gain in productivity". No, that's absurdly bad. Hilariously, stupidly, clownshoes bad. But that's the best that Microsoft could do with a year or more of development effort using the "abstractions" of their current-gen GUI toolkits such as WinUI 3.

This is not progress.

[1] The whole video is worth watching end to end, but this moment is just... sad: https://youtu.be/GC-0tCy4P1U?t=1759

Single-stepping is moderately complicated. I'm even less impressed with modern editors that can't keep up with typing. My first computer could do that. It had a 2MHz 6502.

If I only spoke Arabic or Russian or Chinese, could I write words in my language on those ancient developer tools? Or would I be limited to ASCII characters?

If I were blind, could the computer read the interface out to me as I navigated around? If I had motor issues, could I use an assistive device to move my cursor?

I'm not saying this excuses everything, but it's easy to point at complexity and say "look how much better things used to be". But a lot of today's complexity is for things that are crucial to some subset of users.

> If I only spoke Arabic or Russian or Chinese, could I write words in my language on those ancient developer tools?

For relevant cases, YES!

NT4 was fully Unicode and supported multiple languages simultaneously, including in the dev tools. Windows and all associated Microsoft software (including VS) has had surprisingly good support for this even back in the late 1990s, possibly earlier. I remember seeing in 2001 an Active Directory domain with mixed English, German, and Japanese identifiers for security groups, OU names, user names, file shares, etc... Similarly, back in 2002 I saw a Windows codebase written by Europeans that used at least two non-English languages for comments.

Note that programming languages in general were ASCII only for "reasons", but the GUI designers had good i18n support. Even the command-line error messages were translated!

Linux on the other hand was far behind on this front until very recently, again, for "reasons". You may be thinking back to your experience of Linux limitations, but other operating systems and platforms of the era were Unicode, including MacOS and Solaris.

None of this matters. UTF8 is not the reason the GUI is slow. Even the UCS16 encoding used by Windows is just 2x as slow, and only for the text, not any other aspect such as filling pixels, manipulating some GUI object model, or responding synchronously vs asynchronously.

Look at it this way: for a screen full of text, ASCII vs Unicode is a difference of 10 KB vs 20 KB in the volume of data stored. The fonts are bigger, sure, but each character takes the same amount of data to render irrespective of "where" in a larger font the glyph comes from!

> If I were blind, could the computer read the interface out to me as I navigated around?

Text-to-speech is an unrelated issue that has no bearing on debugger single-stepping speed. Windows had accessibility APIs since forever, including voice, it was just bad for reasons to do with hardware computing limitations, not a lack of abstractions.

> If I had motor issues, could I use an assistive device to move my cursor?

That's hardware.

> But a lot of today's complexity is for things that are crucial to some subset of users.

And almost all of it was there, you just may not have been aware of it because you were not disabled and did things in English.

Don't confuse a "lack of hardware capacity" or a "lack of developer budget" with the impact that overusing abstractions has caused.

These things were not a question of insufficient abstractions, but insufficient RAM capacity. A modern Unicode library is very similar to a 20-year-old one, except the lookup tables are bigger. The fonts alone are tens of megabytes, far more than the disk capacity of my first four computers... combined.

Today I have a 4.6 Ghz 8-core laptop with 64 GB of memory and I have wait for every app to open. All of them. For minutes sometimes. MINUTES!

None of this has anything to do with accessibility or multi-lingual text rendering.

Your comment indicates a pretty poor understanding of why multilingual text rendering is a lot harder than it was in the early 90s. Back then, to display some text on the screen, the steps were: for each character (=byte), use the index to select a small bitmap from a dense array, copy that bitmap to the appropriate position on the screen, advance.

But modern font rendering is: for a span of bytes, first look up which font is going to provide those characters (since fonts aren't expected to contain all of them!). Then run a small program to convert those bytes into a glyph index. The glyph index points to a vector image that needs to be rendered. Next, run a few more small programs to adjust the rendered glyph for its surrounding text (which influences things like kerning spacing) or the characteristics of its display. And then move on to the next character, where you get to repeat the same process again. And if you've got rich text, all of this stuff can get screwy in the middle of the process: https://faultlore.com/blah/text-hates-you/

Indic text rendering, for example, never worked until the mid-2000s, and there's even more complex text rendering scenarios that still aren't fully supported (hello Egyptian hieroglyphs!).

Having personally implemented a Unicode text renderer in both DirectX and OpenGL back in 2002 for the Japanese game market, I dare say that chances are that I know a heck of a lot more than you about high performance multilingual text rendering. Don't presume.

You just made the exact same argument that Casey Muratori absolutely demolished very publicly.

The Windows Console dev team swore up and down that it was somehow "impossible" to render a fixed-width text console at more than 2 fps on a modern GPU when there are "many colors" used! This is so absurd on its face that it's difficult to even argue against, because you have to do the equivalent of establishing a common scientific language with someone that thinks the Earth is flat.

Back in the 1980s, fully four decades ago, I saw (and implemented!) colorful ANSI text art animations with a higher framerate on a 33 MHz 486 PC! That is such a miniscule amount of computer power that my iPhone charger cable has more than that built into the plug to help negotiate charging wattage. It's an order of magnitude less than the computer power a single CPU core can gain (or lose) simply from a 1 C degree change in the temperature of my room!

You can't believe how absurdly out-of-whack it is to state that a modern high-end PC would somehow "struggle" with text rendering of any sort!

Here is the developers at Microsoft stating that 2 fps is normal, and it's "too hard" to fix it. "I believe what you’re doing is describing something that might be considered an entire doctoral research project in performant terminal emulation as “extremely simple” somewhat combatively" from: https://github.com/microsoft/terminal/issues/10362#issuecomm...

Here is Casey banging out a more Unicode compliant terminal that looks more correct in two weekends that can sink text at over 1 GB/s and render at 9,000 fps: https://www.youtube.com/watch?v=99dKzubvpKE

PS: This has come up here on HN several times before, and there is always an endless parade of flabbergasted developers -- who have likely never in their lives seriously thought about the performance of their code -- confidently stating that Casey is some kind of game developer wizard who applied some "black art of low-level optimisation". He used a cache. That's it. A glyph cache. Just... don't render the vector art more than you have to. That's the dark art he applied. Now you know the secret too. Use it wisely.

> You can't believe how absurdly out-of-whack it is to state that a modern high-end PC would somehow "struggle" with text rendering of any sort!

I never said that.

What I said is that modern text rendering--rendering vector fonts instead of bitmap fonts, having to deal with modern Unicode features and other newer font features, etc.--is a more difficult task than the days when text rendering was dealing with bitmap fonts and largely ASCII or precomposed characters (even East Asian multibyte fonts, which still largely omit the fun of ligatures).

My intention was to criticize this part of your comment:

> None of this matters. UTF8 is not the reason the GUI is slow. Even the UCS16 encoding used by Windows is just 2x as slow, and only for the text, not any other aspect such as filling pixels, manipulating some GUI object model, or responding synchronously vs asynchronously.

> Look at it this way: for a screen full of text, ASCII vs Unicode is a difference of 10 KB vs 20 KB in the volume of data stored. The fonts are bigger, sure, but each character takes the same amount of data to render irrespective of "where" in a larger font the glyph comes from!

This implies to me that you believed that the primary reason Unicode is slower ASCII is because it takes twice as much space, which I hope you agree is an absurdly out-of-whack statement, no?

> This implies to me that you believed that the primary reason Unicode is slower ASCII is because it takes twice as much space, which I hope you agree is an absurdly out-of-whack statement, no?

Actually, this precise argument comes up a lot in the debate of UTF-16 vs UTF-8 encodings, and is genuinely a valid point of discussion. When you're transferring gigabytes per second out of a web server farm, through a console pipeline, or into a kernel API call, a factor of two is... a factor of two. Conversely, for some East Asian locales, UTF-16 is more efficient, and for them using UTF-8 is measurably worse.

The point is that any decent text renderer will cache glyphs into buffers / textures, so once a character has appeared on a screen, additional frames with the same outline present will render almost exactly as fast as in the good old days with bitmap fonts.

Not to mention that Microsoft introduced TrueType in 1992 and OpenType in 1997! These are Windows 3.1 era capabilities, not some magic new thing that has only existed for the last few years.

None of this matters in the grand scheme of things. A factor of two here or there is actually not that big a deal these days. Similarly, rendering a 10x20 pixel representation of maybe a few dozen vector lines is also a largely solved problem and can be done at ludicrous resolutions and framerates by even low-end GPUs.

The fact of the matter is that Casey got about three orders of magnitude more performance than the Windows Console team in two orders of magnitude less time.

Arguing about font capabilities or unicode or whatever is beside the point because his implementation was more Unicode and i18n compliant than the slow implementation!

This always happens with anything to do with performance. Excuses, excuses, and more excuses to try and explain away why a 1,000x faster piece of hardware runs at 1/10th of the effective speed for software that isn't actually that much more capable. Sometimes less.

PS: Back around 2010, my standard test of remote virtual desktop technology (e.g.: Citrix or Microsoft RDP) was to ctrl-scroll a WikiPedia page to zoom text smoothly through various sizes. This forces a glyph cache invalidation and Wiki especially has superscripts and mixed colours, making this even harder. I would typically get about 5-10 fps over a WAN link that at the time was typically 2 Mbps. This is rendered in CPU only(!) on a server, compressed, sent down TCP, decompressed, and then rendered by a fanless thin terminal that cost $200. The Microsoft devs are arguing that it's impossible to do 1/5th of this performance on a gaming GPU more than a decade later. Wat?

I continue to be mystified as to why you think I am commenting in any way on the quality (or lack thereof) of the Windows Console.

I've had the same thing happen with a drawing app.. I've an older android tablet that has a sketch app. It works great.. I got a new high powered tablet, because the battery on the old one wouldn't keep a charge.. New one has a sketch app that lags.. draw line... wait. draw line... wait. It's unusable.. It has a newer processor, and more memory, but I can't draw.

I personally do not like how his solution boils down to "just learn more" which may be true at an individual level, but not as the general solution to awful software.

You will never be able to force developers worldwide to start writing everything in C/Assembly, or even to care beyond "it performs fine on my machine". Individuals can have fun micro-optimizing their application, but overall, we have the app we have because of compromises we find somewhat acceptable.

More likely the solution will be technical, making great/simple/efficient code the path of least resistance.

The real problem is that we have a broken, anti-performance culture. We have allowed "premature optimizaiton is the root of all evil" to morph into "optimization is the root of all evil. That single quote has done untold damage to the software industry. We don't need to pass laws to force all programmers worldwide to do anything. Fixing our culture will be enough. In my view, that's what Casey is trying to do.

I don't believe this is the root cause, computers got faster, and software got quicker to the state of "run good enough". I'm calling Wirth's law on it.

"Clean code" is indeed often a bad idea, but you are overestimating the impact. Even software written by people caring very much about performance consume way more than it theoretically should.

Plus, if this was that simple, people would have already rewritten all the bad software.

Your message is exactly the reason why I do not like Casey, he is brainwashing everyone into thinking this is a culture problem. Meanwhile nobody tries to solve it technically.

Wirth's law doesn't bolster your point. He observed software is getting slower at a more rapid rate than computers are getting faster. Which is the whole point. We write increasingly slow, increasingly shitty code each year. I read and hear this attitude all the time that is basically "if you optimize something, you're bad at your job, only juniors try to do that". That's a culture problem.

It's frankly insulting you think Casey brainwashed me into this stance, when it's been obvious to me since long before I'd ever heard of him. IDGAF if code is clean or not. I care that Jira can display a new ticket in less than 15 seconds. I care that vscode actually keeps up with the characters I type. None of this software is remotely close to "runs good enough".

What I am saying is that this is a natural phenomenon assuming no technical solution. People will tend to optimize their software based on the performance of their hardware.

I completely agree that many apps are horrendously slow, but given the alternative are hard pressed to arrive, I can only conclude they are considered "good enough" for our current tech level.

The difficulty involved in rewriting modern apps is one of the reason I would give that result in slow software. Can't really complain about the number of independent web browsers when you look at the spec. Ensuring the software we use is easily reimplementable by a few or one developer in a few days would go a long way improving performance.

Another reason would be the constant need to rewrite working code, to work on new platforms, to support some new trendy framework, etc. etc. You cannot properly optimize without some sort of stability.

Jira runs good enough to get idiot managers to pay for it, which is what it's designed for. And, yeah, microoptimising (or micropessimising, who knows since the changes are usually just made on vibes anyway) random bits of code that probably aren't even on any kind of hot path, while compromising maintainability, is something only juniors and people who are bad at their job do. It's easy to forget how common security flaws and outright crashes were in the "good old days" - frankly even today the industry is right to not prioritise performance given how much we struggle with correctness.

A lot of code is slow and could be faster, often much faster. This is more often because of people who thought they should bypass the abstractions and clean code and do something clever and low level than the opposite. Cases where you actually gain performance on a realistic-sized codebase by doing that are essentially nonexistent. The problem isn't too many abstractions, it's using the wrong algorithm or the wrong datastructure (which, sure, sometimes happens in a library or OS layer, but the answer to that isn't to bypass the abstraction, it's to fix it), and that's easier to spot and fix when the code is clean.

The free market is preventing technical solutions. People generally buy based on features first and everything else second. This allows for a precarious situation in software market: the company producing the most bloat the fastest wins the biggest market share and sees no need to invest in proper fixes. Everyone that cares about software quality too much gets outcompeted almost immediately.

And since software can be rebuilt and replicated with virtually zero cost, there is no intrinsic pressure to keep unit costs down as it happens in industry, where it tends to keeps physical products simple.

It doesn't have to come from the free market, FOSS is hardly exempt of awfully slow/unstable software. Nobody figured out yet how to make writing good software the default/path-of-least-resistance.

Watch some of the intros to his performance aware programming videos. He doesn’t want everyone to use C or Assembly. He also doesn’t want everyone micro-optimizing things.

>compromises we find somewhat acceptable

His entire point is that most developers aren’t actually aware of the compromises they are making. Which is why he calls it “performance aware programming” and not performance first programming.

I have actually watched many of his videos, as an individual I very much like his advices. What I am saying however is that this has nothing to do whatsoever with improving software at scale.

But my point still stands, Casey focuses solely on the cultural aspect but completely ignore the technical one. He says that developers became lazy/uninformed, but why did that happen? Why would anything he currently say solve it?

I don’t think you can blame him for not having a large scale systemic solution to the problem.

Imagine if there was a chef on YouTube who was telling everyone how bad it was that we are eating over processed food, and he makes videos showing how easy it is to make your own food at home.

Would it be reasonable to comment to people who share the chefs message that you don’t like how his cooking videos don’t solve the root problem that processed food is too cheap and tasty?

And here’s the thing, he doesn’t have to solve the whole problem himself. Many developers have no idea that there’s even problem. If he spreads the message about what’s possible and more developers become “performance aware” maybe it causes more people to expect performance from their libraries, frameworks, and languages.

Maybe some of these newly performance aware programmers are the next generation of language and library developers and it inspires one of them to create the technological solution you’re hypothesizing.

But he says that he has a large-scale systemic solution, it is literally the reason for his videos.

He isn't doing it so I can get my CPU trivia, but because he believes it will result in better software. Been at it for years, and so far I don't think it's going better.

My opinion is that better software will not come from CPU-aware people, but from people having enough of all the BS and switching to simpler solutions. You speak about language/libraries, what make you think it would come from those?

I do believe he is smart, just unfortunate he puts his talent on the wrong path. It's not like he does not understand the impact of simplicity/working independently, as it is how he made his "fast terminal" showcase: by tying to bypass system libraries as much as possible, transforming it into a simple (or at least less theoretical) problem.

This is such an absolutely wild take to me. Screw those Mythbusters guys trying to explain the scientific method to people. That's not a systemic solution to fixing scientific illiteracy in the US. Sesame Street teaching kids to count? Those guys are way off the mark because it's not going to measurably improve economic performance. You'll never actually change anything just by teaching people stuff.

I'm 100% certain that Casey Muratori doesn't think that his paywalled course is going convince literally every programmer to to care about performance, or to stop Facebook from building slow apps.

He's trying to convince some small percentage of people that performance is something they should be thinking about when they program, and that they should understand the tradeoffs they are making when they choose to use some slow method, algorithm, library, language, or system because it provides some other benefit.

When someone writes a book like "math for dummies" that says on the back cover "I think basic math is a useful skill for everyone to have, and if we all learned basic math the world would be a better place!"

That's not the author stating their true belief that their book is going to literally teach the majority of the world basic math. That's an aspirational goal or in the worst case it's sales copy.

Publicly calling that person out for wasting their time is really something else.

Creating straw men to attack like "You will never be able to force developers worldwide to start writing everything in C/Assembly" when he explicitly states that this isn't his goal makes me think you're just looking for some reason to shit on the guy.

>You speak about language/libraries, what make you think it would come from those?

I have no idea when if or how a technical solution will be found.

"Math for dummies" book writers don't argue that mathematicians are stupid/incompetent because they do not spend enough time on the basics.

It has also nothing to do with teaching people to count, read, or the scientific method. Every. Single. Software I use is bloated, I am unaware of any software solely consuming that it should, nothing is close to the theoretical limit, this is not a knowledge issue. If you have such software in mind feel free.

Casey continuously says that the problem with software is that developers do not understand performance, and so that the problem will be solved once they do. I am not overly familiar with his paid course, but he did stuff before that. He has essentially the same opinion as Jonathan Blow.

The course being paywalled isn't really an argument for either of us, on his side it is most likely a compromise, just because this isn't the grand plan to convince millions of developers doesn't mean he doesn't intent for it to help his cause.

Casey believing the problem at scale to be cultural isn't some guess, I actually asked him: https://x.com/cmuratori/status/1687138791356833793

> that this isn't his goal makes me think you're just looking for some reason to shit on the guy.

You can consider it a hyperbole if you want, but essentially what I am saying is that he wants to put the burden on the developers, without really changing the underlying structure.

I am not shitting on him for the sake of it. I do really like his (and Jonathan) observations, and I will continue to watch them, I just find it unfortunate that both waste their time on solution that will not affect anything at scale (one with a custom language, the other with specialized course)

>"Math for dummies" book writers don't argue that mathematicians are stupid/incompetent because they do not spend enough time on the basics.

His argument isn't that they don't spend enough time on the basics. His argument is that they don't know the basics even exist.

This is true in my experience. I've interviewed scores of candidates over the years who just have absolutely no mental model of what is going on under whatever abstraction layer they generally work in.

Making trade offs to sacrifice performance for things like developer speed is fine. But if you're not aware you are making those trade offs, I might not call you stupid, but I will call you ignorant.

>Every. Single. Software I use is bloated, I am unaware of any software solely consuming that it should, nothing is close to the theoretical limit, this is not a knowledge issue.

It's not binary. There's a continuum. No software is ever going to use exactly the minimum theoretically possible number of instructions and memory over the entire program.

But some software is worse and some is better.

It is possible to believe that the problem can be solved by changing the culture, while simultaneously believing that you aren't going to be able to completely change the culture. While also believing that you can shift the culture ever so slightly such that you make it just a little bit better.

You can also hold all of the above beliefs while believing that there is a systemic underlying issue that you have no idea how to solve.

From my observations (having watched a good bit of early handmade hero and a good bit of his paid course) the above is pretty close to his beliefs.

It's also fairly close to my own thoughts on the subject. The underlying issue is that software is an industry that primarily competes on features, not quality. I think the reasons for that are numerous--everything from software being an immature industry, to the distorting effects of cheap money flowing into the industry from the previous few decades.

I believe this will work itself out to some degree over time as the industry becomes more mature and we start to see more diminishing returns for just adding new features. Developers will start to look towards other things to differentiate themselves and quality/performance could be one of them.

I don't think there's anything I or Casey can do to change the market dynamics, and I can't think of a technical fix to this issue. I suspect Casey can't either.

I also think that there are niches today where performance and quality can outcompete more features.

Given all the above, I think pushing to convince a small percentage of people that spending a bit more time thinking about performance is a rational goal. Maybe it's the best you can do. But maybe you end up with just a few less wasted cycles in the world. Maybe you end up with a few more pieces of software that feel snappy and pleasant to use than you otherwise would have.

I completely agree that some (if not the majority of) developers aren't aware of what's happening under abstraction layers, but then I have to ask: is it the developer fault, or the abstraction's?

If you were to ask a new programmer to make a very simple calculator which would then be distributed to various people using various devices, what would they use? How long would it take them? How much would it consume? Does this cost have anything to do with the programmer being unaware CPUs have multiple cores or that memory access is slow? Theoretically I would struggle to find a way to make this calculator takes up more than 10mb of memory (which is already more than Mario 64), both as CLI and GUI. You literally have 4 bytes instructions for add/sub/mul/div and a framebuffer, it is not like I am talking about micro-optimization, this should be the default and simplest path.

Discord takes around 400mb on my machine and will happily take a whole +3ghz core from me if I start scrolling. If I were to give a new programmer a method to query messages, and another to render to a framebuffer through software rendering, would they even succeed matching discord/chromium's bloat? Seems to me it would require some genuine effort.

You could explain me that this bloat come from fancy/convenient features, but it does not change that programmers are always exposed to complex problems even though theoretically easily composable and therefore friendlier to changes.

If you were to ask me for less theory and for a more practical example, I would say that each programs should be written/compiled to a potentially different format with the common point of being easily interpretable (stack machine, Turing machine, lambda calculus, cellular automata). Each platform (OSes, hardware) should come with a program that expose every single potential IO action, and to run an actual program requires finding an interpreter for the specific format (either made yourself in an hour at most, or downloaded) and mapping your exposed IO calls through the platform app, in the same way you would configure keybinds in a video game.

- Developers are always exposed to their lowest layer

- Programs are always cross-platform, even to future ones

- Programs are stable, increasing the chance of being optimized over time

- Heavily limit dependencies (and therefore additional abstractions)

In this example, none of it depends on understanding how CPUs work. Also does not require a change in market dynamics, individuals can start, and make it slowly gain relevance as anything written this way cannot (easily) break and become abandonware.

Ultimately, even unaware programmers are able to explain their webapp in few words, the problem is that they cannot easily map those words and have to work around frameworks which they cannot really give up on. Android/iOS helloworld templates illustrate it nicely.

I 100% agree that you don't necessarily need to know how a computer works to make a less bloated discord app.

But I do think that knowing the limit of what is possible with respect to performance makes you appreciate just how bloated and slow something like discord is. If you've only ever don't web development or electron apps, and you've only ever used bloated apps, you have no idea that you can do better.

You don't have to teach people about the limits, you could build a discord client on top of a "a method to query messages, and another to render to a framebuffer through software rendering" and show them how much faster it could be how much less memory it could use.

But the thing is Casey likes teaching at a lower level than that. He likes teaching about the domain he finds interesting and that he's an expert in. He thinks he can make the world more like the world he wants to live in, and he thinks he can do it by doing something he likes doing and is capable of doing.

That doesn't mean there aren't other faster or more impactful solutions to less bloated software, but he's not necessarily the guy to work on those solutions and there's nothing wrong with that. Judging by the number of people who watch his videos and the frequency with which the topics he promotes are discussed, he's making an impact--maybe not the optimal impact he could be making, but that's a fair thing to judge someone on.

> Each platform (OSes, hardware) should come with a program that expose every single potential IO action, and to run an actual program requires finding an interpreter for the specific format (either made yourself in an hour at most, or downloaded) and mapping your exposed IO calls through the platform app, in the same way you would configure keybinds in a video game.

Have you looked at the Roc language? It has a lot of similarities to what you're describing.

> You don't have to teach people about the limits, you could build a discord client on top of a "a method to query messages, and another to render to a framebuffer through software rendering" and show them how much faster it could be how much less memory it could use.

The problem is exactly that this is not that simple. I believe that there is a huge gap between the theory of a chat application, and the way they are implemented now. I do not believe it is about better abstraction layers, personally I have always found explanations using raw sockets and bits the simplest.

If you were to ask a programmer to write a discord client, you would very likely end up with a giant mess that somehow break a few months later at most (if ever). Even though they would be able to flawlessly go through the program flow step by step if you asked.

Discussions about efficient code kind of avoid the topic, I don't believe we are in a situation where multithreading is relevant, the bloat is on another level. The bloat is generally not related to whatever language you use, the O(1) or O(n) algorithm you choose, but more likely the overall control flow of the program which you already understand in your head but cannot figure out how to act on, and the inability to make simple problems simple to solve (like the calculator, text editor, or even games)

Now you are probably right about Casey ultimately doing what he likes, and even if suboptimal make other people aware. Although I would believe that this benefit comes somewhat in spite of himself.

> Have you looked at the Roc language? It has a lot of similarities to what you're describing.

Gave it a look and unfortunately, I don't think I have seen the similarities? It has environment/IO access, call host language functions, and doesn't really strive to be reimplemented by independent people.

>Gave it a look and unfortunately, I don't think I have seen the similarities?

I was specifically thinking about this https://www.roc-lang.org/platforms

I'm not an expert. I haven't actually used it, but I have been following it a bit. Roc splits things into apps and platforms. When you implement a platform you're responsible for implementing all (or the subset you want to provide) of the I/O primitives and memory allocators.

>Discussions about efficient code kind of avoid the topic, I don't believe we are in a situation where multithreading is relevant, the bloat is on another level

Case does talk about other kinds of bloat. Things like structuring things so blocking operations can be batched etc...

Muratori's main talking point seems to be that modern software is slow. I think he is 100% correct on this. It's absolutely insane how long it takes jira to show me a ticket or slack to switch chat rooms and that vscode can't keep with up with normal typing speed.

He's right about software being slow. He's wrong about why they are slow or how to solve the problem.

What is your opinion on the cause and the solution?

I think it's like asking why poverty exists. There's no one, easy answer. We have a lot of difference forces, many of them market or demand or incentives that cause software to be slow. Fixing this will require concerted effort, rewards for making things that are fast, and some sort of accounting for the externalities. Same as any other complex problem.

Aren't you agreeing with Casey by saying this is an effort/cultural problem? He also does say that fast software can sell better.

I agree with Casey that this is a problem. I disagree with his view that seems to mostly boil down to "let me at them chief".

Agreed.

Blow's taken the better part of a decade to make a game where he didn't even need to invent the mechanics and Muratori never finished a game he started a decade ago.

Meanwhile if you use modern game engines (including stuff like Raylib) you can have a pretty decent result in a weekend game jam session, and you could probably make Blow's Sobokan game in ~6 months or so (especially with a team of ~10).

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.

Which points do you think the author has missed?

Could you expand on how Figma is destroying the design world?

I'm curious too. I want to understand "Figma is destroying the design world on unprecedented scale by normalising bad UX, UI and product management found in Figma itself".

So your rebuttal is that they’re wrong because they’re young and inexperienced? OK, maybe, but what exactly are they wrong about? You haven’t actually added anything to the conversation with this ad hominem attack.

Also I couldn't find the authors age but judging by the fact they say they still use an Amiga they're probably at least in their 40s(unless they're a huge retro fan)

Also talked about C64's, like they lived through it. That brings them into their 50's. I got the feeling they've been at it a long time.

I’m 38 and from Northern Europe. We had a C64 when I was a kid. Tech spread slower outside the US back then I think :)

He demolished Blows argument so I don't think it's important to bring up age but it does seem like he is likely at least in his mid forties. The Amiga was popular in the late 80s

> "The argument that software is advancing is obviously false" I still regularly use my beloved Amiga computers. A couple of weeks ago, I was copying a file to an Amiga's hard drive when the computer suddenly decided to crash on me. Not because I did something wrong, but because old home computer OS:es weren't very stable. This resulted in a corrupted hard drive partition and the OS failed to re-validate the file system. My only option was, in the end, to re-format the partition.

I don't even know much about design but I can tell your claims about Figma are totally wrong, in a similar fashion to blows claims. It's the nostalgia talking. You're forgetting the fact that user interface has always had a lot of crap, just like software just like everything. The positives of the old cream of the crop is remembered while all the crap and even all the failings of the well designed things are forgotten

Figma absolutely sucks.

It is slow, but more importantly, by encouraging UX designers to work in high fidelity designs where live changes are frustrating and feedback is entirely incorporated as a bunch of mostly-hidden comments in a sandbox that makes it hard for reviewers to follow up on or reference back to, all it's done is made everything worse.

"It appears that author is from that newer generation"

No it doesn't. Nothing else you wrote here is true either.

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.

> I don't disagree that software engineering is not as rigorous as it was.

Such an utter BS. Modern run-of-the-mill software would run stadiums around the software of 80-s or 90-s.

Version tracking, continuous integration, and even _bug_ tracking was not at all common in 90-s.

Testing? That's so far ahead of the state-of-the-art of even 2000-s that it's not even funny. Even the basic unit testing was a huge step ahead in 2000-s. And fuzz testing, ubiquitous sanitizers, time-travel debugging are all novel to the mainstream development.

And that's not all. We're now not just talking about formal methods, but applying them in practice (see: WUFFS). And we now have safety-oriented low-level languages like Rust (that's just basically 10 years old).

„ 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.

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

We aren't avoiding nor minimising complexity (by being at higher levels) but merely being ignorant of it, which is okay, too; until the abstractions leak: For example, folks working in hpc / cybersecurity have no such luxury.

You are right, I should have been more accurate in my depiction. Inherently technological problems require low level-technological solutions. There is no way around that.

But most complexity I see arrives from just moving data from A to B to automate everyday bureaucratic tasks or enable data analysis. And the needless complexity I encounter in such systems is just mind boggling.

Currently I am working on a government system which captures tasks for long running procedures such as approving power plants. And the way the devs are treating this system is borderline criminal, acting as if this is just another CRUD app without any structure or architecture.

The idea that abstractions have to leak is a myth. We don't need fewer abstractions, just better ones. Abstractions that don't require obscuring the low-level details (e.g. typeclass/trait systems instead of interface/impl ones) help too.

"All abstractions leak, but some are useful" - me, on HN for the last few years.

Roughly paraphrased, but my meaning is clear: the best abstractions are useful ones, not leakless ones.

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.

But is it though? Because it's has been claimed for many many years that the west if falling (at least from 2008 on-wards) and yet - more people speak English than ever before, American culture (at least anecdotally) is more ever present and American tech corporations are 8 out of 10 most valuable companies in the world.

I guess that people always feel that the end is nigh.

Latin was used for centuries after the Roman empire was gone.

The West is de-industrializing very fast. And a good chunk of the services side is switching to India and other cheaper countries and AI. The West is in its last legs. The final nails in the coffin will be when China achieves good enough but at cheap prices: 1) chips (5-10 years away) and 2) aerospace (8-12 years away?). China is investing heavily on these and acquiring the knowledge (wink-wink).

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.

You realize that the US is still designing the most advanced processors and technology. Now if you argued that the US has forgotten how to manufacture anything, I would agree with you.

No. Taiwan and Korea are on par for design.

Taiwan doesn’t “design” any leading edge chip they manufacture them. Where are the great chios from Korea? The top Android phones are four years behind iPhones as far as performance - including those from Samsung

Don't discount MediaTek, and four years is an exaggeration.

My bad - only 3 years. The fastest Samsung is around iPhone 12 and iPhone 13.

https://browser.geekbench.com/mobile-benchmarks

MediaTek is definitely not releasing high end chips. For desktop ARM, the only ones that come close are Qualcomm’s chip

TMSC realizes the designs. They only aren't designing because they choose not to. Basically everything you see around you Asia does better. I think the last thing we have is military technology and passenger planes.

As for software, we're only slightly better than asia.

If that were the case, why wouldn’t they do that?

Does Foxconn also “realize the design” of the iPhone?

Because their business model is to focus on manufacturing so that they don’t compete with their customers. This gives them access to Nvidia and amd with no conflict of interest. This is not something I’m just speculating about and writing about here as a counter point. This is literally a well known and specific strategic business decision made by tsmc.

Foxconn I’m less familiar with them so I can’t comment on that. But I wouldn’t be surprised if they had a similar strategy. Would apple really outsource to them if they were making their own competing phones? Fuck no.

That being said you know that all phone technology comes from abroad right? Like most design and manufacturing come from Asia. It is impossible for America alone to support the full stack of this technology. But Asia can.

Foxconn is actually an ODM too. They design and manufacturer their own phones.

https://nuumobile.com/android-oems-vs-odms-5-things-you-shou...

Doubt those phones compete with apple.

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.

that is exactly what it is. it's a pseudo-intellectual (in this case Jonathon Blow) who thinks he's got it all figured out.

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.

Plenty of hand written assembler in core programs like ffmpeg. Sure most people glue together tedious JavaScript frameworks but there’s still people doing real work.

…which isn't just writing writing assembly for ffmpeg.

Not sure if you’re being sarcastic, but I do unironically miss this.

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 the article shows, these ridiculous claims are false.

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

How so?

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…

Well indeed - abstraction is a cornerstone of progress, not a hindrance to it.

Most of us will die from dehydration or water-borne disease or hunger if civilisation collapses though!

Ngl, forcing people to walk two miles for water everyday would probably make a significant dent in obesity related mortality.

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

Reply on news.ycombinator.com