Software disenchantment

Finally, someone I agree with on this topic

You don't need a web browser to edit text. As evidenced by dozens of excellent text editors that are not built on web browsers.

It's just easier to take a web browser that already has something approximating a text editor, and pile things on top of that.

And why is that? Well, because you want to support all the different platforms, and we as an industry have absolutely screwed up the portability story, and so we build it as hacks instead. There's absolutely no reason why developing a GUI app for macOS should be radically different from developing a GUI app for Windows or Linux - they all ultimately do the same thing. There's no sensible reason for them to be different. But they are. And so now the easiest way to solve that problem is to pile the browser on top, and forget that the differences exist. Of course, it doesn't actually solve the problem in general, because the differences are still there, and the industry as a whole still pays the overhead tax, in both man-hours of work someone has to spend maintaining that flimsy stack of abstractions, and in runtime performance tax those abstractions impose.

But the only way to fix it is to burn the whole thing to the ground. And that's not happening, because the short-term cost is too large to even contemplate any long-term gains.

Those shouldn't even be needed.

To give an example, let's say you need to calculate SHA-256 hashes in your program. People would rather include the OpenSSL library than just add a SHA-256 function to their code. Instead of a single function (that maybe has a couple helper functions), they add a massive library full of features they don't need, taking up memory, bloating the executable size, and increasing load time.

If you're using less than 10% of a module, you should be questioning if you even need that module at all.

Yes, it's an apple to oranges comparison, but the point is more why are we using an orange when an apple will suffice?

The real question is, is all that really needed?

We keep building abstraction layers on top of abstraction layers when often times, there is already tried and proven solution that works and is much simpler.

I've been doing some experimenting creating a single page application (SPA) without a web framework and turns out you can get 90% of what React offers with a tiny amount of code.

https://github.com/brennancheung/volgenic/blob/master/13-IDE...

My current iteration is just to do a:

    State.update(() => { state.foo = 123; state.other = 456;  })

I just use plain javascript objects to store data and wrap it in a function that will trigger re-rendering the VDOM / repaint.

And even if we do need that additional layer of abstraction we can always make it appear simpler and provide a cleaner interface to the programmer. A Proxy object setter could be used to eliminate the boilerplate of State.update.

Good abstractions simplify the problem by creating a mental paradigm that is closer to the problem domain. Poor abstractions do the opposite, they take away what is needed to solve the problem and create additional steps that are not really germane to the problem.

Many abstractions are well intentioned, but after we toss layer on top of layer, we often get so far removed from the problem domain, we have to ask ourselves if it is not simpler to just build up another set of abstractions that allow us to get closer to the problem domain (i.e., "First Principles").

I can think of many reasons to deliberately create software that is inefficient. Number one on the list is to make it more reliable. The number one reason software is rarely reliable is because code is more often than not complex to the point where the developer unsure whether it will work or not. In turn, this occurs most often when trying to maintain state via flags. If, instead of trying to maintain state, the software is designed so that the current state of objects is always a function of the original state of the object at the time the App started, you have an App that is potentially slow but like to be extremely reliable and extremely easy to read.

I always program this way these days and my Apps are always reliable. For example ToteRaider (see Toteraider.com), a complex gambling App, released 2.5 years ago is still on version 1. Zero defects in production and also zero defects in testing.