> In the example of your Amiga, your hard drive failed, but it probably would still boot right into any game from any floppy [...] The same game, replicated in Unity, requires a several gigabyte

You have a good point to make, but the argument you've employed is bad. When you said,

> In the days of the Amiga or the Archimedes, it was quite possible to boot entire app or os/app combo and just leave the computer on indefinitely, without it crashing itself even if untouched.

You've mixed up reliability with understandably & maintainability. In an uptime competition, a retrocomputer will lose the game to many modern computers, it's almost guaranteed. But it's not the point. The point is what happens after it's down. If it's a retrocomputer, it's possible for a single person to understand every aspect of the computer and to perform troubleshooting down to the component level. It's also easy for a single hobbyist to build one's own computer using the 6502 chip. But it's usually impractical or impossible on modern hardware. My personal understanding on the thesis of the talk is that modern computers have much less understandably & maintainability than retrocomputers, and this, in the long term, makes the civilization as a whole, less reliable. It's not a question of how durable we can make a single computer to be.

You can make a better argument if you stop saying how reliable retrocomputers are and focusing on understandably and complexity.

I don't make the argument that they were more reliable now or then than today's PC, they almost weren't and aren't. The problem is how we got more reliable pcs today is in the context of people who had access to both. Some generation in the future won't have access to living human beings for the day the first electronic computer came into existence as we ourselves have access to now.

Notice I said "even if left untouched." Perhaps that was too charitable, as these retropcs, without memory protection, would often crash if metaphorically "touched." It would happen often with productivity apps, much less so with games. As time has gone on with pcs, this seems to have flipped, a fair trade for the time being.

Hmm, so your argument was not reliability of retrocomputers in paticular, but more generally, "how the hardware worked" (and some just happened to be reliable enough for many people), and all these things shaped the understanding of the next generation of innovators who invented our PCs. Thus it's important to preserve the hardware as a key of understanding how we get here from there, because there will be no living witness for the future generation - and this is your actual point.

I think I now understand your argument now.

Yes you grokked my point quite well. I wrote a long rant about how I've never had access to Amiga hardware, but I think I owe your pithiness some pithiness in return.

That's not really a like for like comparison though. You could for example light up a white pixel on a black background in the browser, which almost everyone has installed by default, or using the basic OS APIs or by downloading PICO-8 which is pretty small IIRC.

There are tradeoffs being made in all three choices and each will suit a different context.

Does anyone seriously write games for the browser anymore? Can Jonathan target the browser to make Braid, and seriously expect any commercial success?

Maybe you'll think "What about Celeste?" at which point you'll have only proven both of our points equally at best.

Yes they do. There are also plenty of games written on a web stack and shipped as executables.

And how is that meaningfully different or better than using unity to ship an executable?

I thought your whole point was that everyone already has a stable browser, and shipping games as some bare metal or in some half bare metal form is really the developers imposition if the game could have just as well run in a browser.

There are still people developing efficient and capable game engines. Godot[0] is a good example of one that has achieved widespread success. It's a few dozen megabytes in size, does 2d and 3d, supports VR, and can target Windows, MacOS, Linux, Android, iOS and HTML5/WebAssembly. It's open source and free as in beer too.

[0] https://godotengine.org/

I think Godot has only recently become mature enough to be remotely comparable with unity etc.

From the Godot download page:

"Godot is currently not code-signed for macOS. See the last section of this page for instructions on allowing Godot to run anyway. Alternatively, you can install Godot from Steam to work around this." So what does that leave, Windows and Linux on x86-64?

Isn't this the kind unjustified hoops that Jonathan is criticizing, that people criticize Apple for not making it viable for a clearly legitimate OSS project to have to deal with? It definitely isn't something that would make me confident recommending a middle school game programming class to depend on working one semester to the next.

No my whole point was that you're comparison was silly because there are lots of ways to accomplish what you said without downloading gigabytes or using Unity. I listed two other ways that weren't the browser and said that there were contextual trade-offs in what you'd choose to use.

You've decided to take one of those options and attribute a bunch of arguments to me I've never ever uttered.

Fair enough. I think you've called me out reasonably there.

I still don't think you've addressed my core point, and it's quite probable I wasn't clear enough to make that possible.

My white pixel example was referencing the talk, where I interpreted Jonathan saying almost verbatim about the barriers to just lighting up a single pixel on a modern computer. I made the assumption that everything he opines on publicly is in the context of him making games.

Is this whole stack overflow thread just a bunch of masochistic programmers, or is it needly complex to achieve consensus on how to plot a pixel in a browser canvas? I'll take responsibility for begging the question in jest. https://stackoverflow.com/questions/4899799/whats-the-best-w...

If one wants to start the game they are going to make in the same engine the are going to finish making it in, for most people, unity is going to be worth the gigabyte download. If you just want to teach kids html/css, the server stack in python, and how to change the color of one pixel in the browser is lesson one day one on a raspberry pi, fantastic. If one wants to write a mario clone and ship it in electron, bravo.

Plotting a single pixel is amusingly difficult in general particularly in the age of 3D acceleration. It was also not necessarily a picnic in the past either as there often wasn't space for a fully addressable frame buffer.

I actually did this whilst playing about with Zig a while ago. I made an offscreen buffer, rendered pixels to a frame buffer array in WASM and then copied them into the offscreen buffer. Not going to win speed awards but it worked, was fast enough and was super simple. Also it meant I could scale the canvas to scale my image. This was for a very small screen representing windows in a building. My proof of concept was approximately 30 lines of JS and the same again in Zig. Most of the latter is type definitions.

Although given that Canvas is supposed to be a friendly abstraction it definitely feels like a weird oversight. Personally for pixel sized things I love PICO-8.

> In the example of your Amiga, your hard drive failed

The crucial part here is that software caused the hard drive to fail. That was my point - I think it's easy to forget how fragile most home computer OS:es were 25-30 years ago compared to today.

Bad software and bad UI corrupts usb drives all day long in 2021.

Yes, bad things can still happen. What I'm trying to say is bad things used to happen, too, quite frequently and on very simple systems, and that his points about gradually diminishing robustness and productivity are easy to refute. I'm of the opinion that computers today - despite layers of abstraction and growing complexity - are more robust and lets us be more productive than ever.

Abstraction fosters ignorance and complexity is fragile, I agree with him on those points. But I also think he makes very sweeping, erroneous statements about software and development.