I was using Swiss army knives as early as 5-6 years old. I probably cut myself thrice at most.

However, if the toddler is the reckless kind, they'll start with a plastic butter knife.

While I'm also very engineering inclined, I was like that since very young age. Maybe it's how my brain is wired, or a natural extension of my curiosity, I don't know.

From what I observe, many people doesn't know what's normal and what's not. This is two pronged. Most of the people doesn't know that they are running to the limit unless the tool misbehaves or breaks down. A minority just don't care. They either don't value, or think that machines are meant to be used that way.

Either way, it's more not being knowledgeable than being malicious against devices, at least from my experience.

I don't think so. I personally find dull knives more dangerous because I need to apply more pressure and when it starts to cut, the knife becomes uncontrollable.

When the blade is sharp, and you know it's sharp, you respect the blade and give actual thought to what you're doing.

My wife didn't used to sharpen her knives. When I started to sharpen them, she had a couple of minor accidents, but now the accident rate is at 0.0. She even wants me to sharpen the knives when they become dull.

This is exactly what "having a feeling for the machine is". You know and respect it for what it is. It bites back when you don't respect it. Let it be a knife or a space shuttle, it doesn't matter.

When doing this in a company, making technical people appreciate free software and making lasting changes is hard enough. When doing this with non-technical people, everything becomes exponentially harder.

[0]: https://esolangs.org/wiki/C@%2B%2B

Being tired in a crowded street in rainy weather doesn't help either.

Instead, as you guessed, these demos generate assets on the fly and stream to the respective devices. You cite inefficiencies. I tell they run at more than 60 FPS on these constrained systems. Remember, these are early 2000s systems. They are not that powerful by today’s standards, yet these small binaries use these systems efficiently and generate real time rendered CG on the fly.

Nothing about them is inefficient or poor. Instead they are marvels.

They are highly dynamic programs, and not very different from game engines on that regard.

> misleadingly minimalistic.

That's the magic of these programs or demoscene in general. No misleading. That's the goal.

> writing cool effects for the demo scene is very different to writing software for a business which has to offset developer costs against software sales and delivery deadlines.

The point is not "cool effects" and "infinite time" though. If we continue about talking farbrausch, they are not bunch of nerds which pump out raw assembly for effects. They have their own framework, libraries and whatnot. Not dissimilar to business software development. So, their code is not that different from a business software package.

For the size, while you can't fit a whole business software package to 64kB, you don't need to choose the biggest and most inefficient library "just because". Spending a couple of hours more, you might find a better library/tool which might allow you to create a much better software package, after all.

Again, for the third time, while safety nets and other doodads make software packages bigger, cargo culting and worshipping deadlines and ROI more than the product itself contributes more to software bloat. That's my point.

Oh I overlooked this gem:

> I have friends who are doctors but that doesn’t mean I should be giving out medical advice ;)

Yet, we designed some part of that thing together, and I had the pleasure of fighting with GPU drivers with them trying to understand what it's trying to do while neglecting our requests from it.

IOW, yep, I didn't wrote one, but I was neck deep in both of them, for years.

That C64 demo doing sprite wizardy and 8088MPH comes to my mind. The latter one, as you most probably know, can't be emulated since it (ab)uses hardware directly. :D

As a trivia: After watching .the .product, I declared "if a computer can do this with a 64kB binary, and people can make a computer do this, I can do this", and high performance/efficient programming became my passion.

From any mundane utility to something performance sensitive, that demo is my northern star. The code I write shall be as small, performant and efficient as possible while cutting no corners. This doesn't mean everything is written in assembly, but utmost care is given how something I wrote works and feels while it's running.

...and this effort and small savings here and there is what brings the massive savings at the end of the day. Electron is what "4KB here and there won't hurt", "JS is a very dynamic language so we can move fast", and "time to market is king, software is cheap, network is reliable, YOLO!" banged together. It's a big "Leeroy Jenkins!" move in the worst possible sense, making users pay everyday with resources and lost productivity to save a developer a couple of hours at most.

Users are not cattle to milk, they and their time/resources also deserve respect. Electron is doing none of that.

> You quoted where i said that modern resolutions are literally orders of magnitude greater and assets stored in bitmaps / PCM then totally ignored that point.

Did you watch or ran any of these demos? Some (if not all) of them scale to 4K and all of them have more than two colors. All are hardware accelerated, too.

> And modern graphics aren’t limited to 2 colour sprites (more colours were achieved via palette swapping) at 8x8 pixels. Scale that up to 32bits (not colours, bits) and you’re increasing the colour depth by literally 32 times. And that’s before you scale again from 64 pixels to thousands of pixels.

Sorry to say that, but I know what graphics and high performance programming entails. Had two friends develop their own engines, and I manage HPC systems. I know how much memory matrices need, because everything is matrices after some point.

> Safety nets are not a waste.

I didn't say they are waste. That quote is out of context. Quoting my comment's first paragraph, which directly supports the part you quoted: "Yes, but this doesn't prevent you from being mindful and selecting the right tools with smaller memory footprint while providing the features you need."

So, what I argue is, you don't have to bring in everything and the kitchen sink if all you need is a knife and a cutting board. Bring in the countertop and some steel gloves to prevent cutting yourself.

> I’ve written software for those 80s systems and modern systems too. And it’s simply ridiculous to Compare graphics and audio of those systems to modern systems without taking into account the differences in resolution, colour depth, and audio bitrates.

Me too. I also record music and work on high performance code. While they are not moving much, I take photos and work on them too, so I know what happens under the hood.

Just watch the demos. It's worth your time.

Go's "GC disadvantage" is turned on its head by developing "Zero Allocation" libraries which run blazingly fast with fixed memory footprints. Similarly, rolling your own high performance/efficient code where it matters can save tremendous amounts of memory where it matters.

Of course more features and safety nets will consume memory, but we don't have to waste it like there are no other things running on the system, no?

> And this is all before you take into account that modern graphics and audio is bitmap / PCM and running at resolutions literally orders of magnitude greater than anything supported by 80s micro computers.

This demo [0] is a 4kB executable. 4096 bytes. A single file. All assets, graphics, music and whatnot, and can run at high resolutions with real time rendering.

This is [1] 64kB and this [2] is 177kB. This game from the same group is 96kB with full 3D graphics [3].

[0]: https://www.pouet.net/prod.php?which=52938

[1]: https://www.pouet.net/prod.php?which=1221

[2]: https://www.pouet.net/prod.php?which=30244

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

They all are very different applications and have very different designs, yet the arrow is there.

To be honest, I baffled at your question for a second or so, because I never thought about that, yet the method is so universal that I was not thinking about it at all.

I personally like both the process and the result in software development. Painstakingly designing things, writing them, and seeing that everything is working as it should be very smoothly, efficiently and fast. It's like building an engine by hand, tuning it, listening and feeling that it works as its best version within your capabilities. Then taking notes of the noises and inefficiencies and iterating upon them as the time allows.

Many people are not like that. They want an engine that works. Its efficiency, appearance or inherent reliability due to elegant design doesn't matter for them. If it works reasonably well, carries the builder from A to B (or more importantly makes money for the them), that's more than enough.

I personally respect this point of view, and completely understand it. What I can't respect or accept, regardless of how hard I try to, is being stoned to death or labeled as a Luddite because I and people with similar perspectives value a different set of things in their lives.

Mass produced things have their place, as well as artisanal, one-off ones. I believe we can live together, one doesn't need to kill the other.

I won't go into building of these AI systems, because I'm tired of repeating ethical and other concerns going into it, not because it's boring, but because people don't listen or care about them. Maybe I'll reiterate them when I have more time, next time.

It's vibe-coded, with AI, to Rust. That's enough. Ticks all boxes.

Just half-joking, BTW. Hype is hell of a drug.