Software disenchantment

We should split layers and rush out everyone from the room where low-level things are going. Then, at least, the low-level things will not break.

In an ideal world, we should have building bricks, which even end-users should build an app. Instead, we have frameworks, which are only for programmers, and provide only some automatizable patterns (e.g. a web framework finds which code should be run based on URL), or wrappers (e.g. ORM).

Frameworks and libraries _literally_ hide stuff from progrmmers. They even don't know how computers work.

I've written some 256-byte intros, and showed them for my colleagues. They were amazed:

- Wow, which language do you use, Java? Oh, no you must probably can not use even C++, only C. (Solution: you can not use any language, only assembly.)

- Which framework do you use, Unity? Or pure OpenGL? (Solution: you can't use any, you must put every pixel yourself.)

They don't know, what fits in 256 byte. They don't care what they're producing. And it's not their fault.

Yup, pretty sure that "overcommit" should never have been the default option (although it is quite easy to disable, comparatively few people know that it even happens).

Article tl;dr: "I believe that apples are more efficient than oranges after all."

I just want to point out that the idea that "modern buildings use just enough material to fulfill their function and stay safe under the given conditions" is fundamentally at odds with the author's subsequent thesis.

Modern buildings don't use "just enough material", because "just enough material" would be _just_ concrete everywhere; it would have been "just wood" 200 years ago, but that's not good enough now. This is exactly the problem: it's not software that is unnecessarily bloated, it's software that has evolved to solve higher order problems, ones that are not simply based in how fast a computer can count to 10. Similarly, the definition of "fulfill their function" in the context of buildings have changed too. That definition changes all the time, even in building codes.

In the modern-building hierarchy of needs, we are way passed the "stay safe" level. We still optimize for safety, sure, but that hardly accounts for your spray foam insulation, HVACs, builtin wireless units, complex built-in cabinetry, complex appliances, and more. Simple things like "electricity" are now part of the definition of fulfilling building function. Go find a 200 year old building and you will find a building that simply does not fulfill today's functions. Even safety standards have and continue to change all the time. You can look at historical building codes and see evolving fire safety (asbestos? NO ASBESTOS!), seismic safety, and more.

This is the point. To say that Windows 95 is 30MB discounts the years of improved process space isolation, memory protection, Spectre mitigation, that, if missing, would cause enormous public backlash about why Microsoft doesn't care about security. Windows 10 is 100x larger because WE asked for it to be. WE wanted WiFi, VPN, IPv6 switchover and tunneling all added to our network stack. WE wanted GPU enhanced UI threads. WE want haptic feedback and touchscreens and predictive text and predictive multi-touch pixel accuracy for our touchscreen laptops. This extra complexity exists because our standards changed. A text editor isn't just something that renders ASCII anymore-- heck, it's not even just for rendering characters. My "text editor" is a full web browser because I _need_ that for development these days.

Extra complexity is a feature not a bug. We built computers specifically to do this stuff, not in spite of it. The abstractions and complexities aren't getting in our way, they are literally the things we are building. Does performance suffer? Maybe, but that's because we are explicitly paying into functionality. If you wanted a fast text editor, obviously a black-and-white screen that only renders 256 characters will be faster than VS Code, go ahead and use that software, but you're not getting the other things you probably want. Your very next complaint will undoubtedly be "how do easily I diff my Git branches?" -- and this is how software becomes more complex.

Welcome to progress.

This isn't an economic issue, it's an efficiency issue.

There are 3 competing ideas: Fast, cheap, quick. You get to pick 2. We're picking cheap and quick because "fast" comes for free on a longer-term timeline. You can argue with whether or not this is the right choice, but this is the choice society is making, and IMO it would work better than taking significantly more time to build something that is only 10% faster. It's more efficient to let hardware manufacturers solve the fast problem when the differences are on the order of 5-10% a year but the time-to-release problem is on the order of 50-100% differences in development times.

One of my friend pretend that we - software engineers - should work as mechanical engineers. They have a documented, standardized, and limited set of screws, nuts, ... and they build anything with it. This allow to develop CAD tool to assemble, verify, simulate, ... On our side, we have thousands of implementations of basic SW blocks (fifo, mutex, ...), or even "bigger" concepts (server, reader/writer, state-machine ...). What do you think ?