Comment by pydry
3 days ago
Most of it was exchanged for abstractions which traded runtime speed for the ability to create apps quickly and cheaply.
The market mostly didn't want 50% faster code as much as it wanted an app that didn't exist before.
If I look at the apps I use on a day to day basis that are dog slow and should have been optimized (e.g. slack, jira), it's not really a lack of the industry's engineering capability to speed things up that was the core problem, it is just an instance the principal-agent problem - i.e. I'm not the one buying, I don't get to choose not to use it and dog-slow is just one of many the dimensions in which they're terrible.
I don’t think abundance vs speed is the right lens.
No user actually wants abundance. They use few programs and would benwfit if those programs were optimized.
Established apps could be optimized to the hilt.
But they seldom are.
> They use few programs
Yes but it's a different 'few programs' than 99% of all other users, so we're back to square one.
>No user actually wants abundance.
No, all users just want the few programs which they themselves need. The market is not one user, though. It's all of them.
But each vendor only develop a few software and generally supports only three platforms -/+ one. It’s so damning when I see projects reaching out for electron, when they only support macOS and Windows. And software like Slack has no excuse for being this slow on anything other than latest gen cpu and 1gb internet connection.
1 reply →
Users only want 5% of the features of the few programs they use. However everyone has a different list of features and a different list of programs. And so to get a market you need all the features on all the programs.
Did people make this exchange or did __the market__? I feel like we're assigning a lot of intention to a self-accelerating process.
You add a new layer of indirection to fix that one problem on the previous layer, and repeat it ad infinitum until everyone is complaining about having too many layers of indirection, yet nobody can avoid interacting with them, so the only short-term solution is a yet another abstraction.
> Most of it was exchanged for abstractions which traded runtime speed for the ability to create apps quickly and cheaply.
Really? Because while abstractions like that exist (i.e. a webserver frameworks, reactivity, SQL and ORMs etc), I would argue that these aren't the abstractions that cause the most maintenance and performance issues. These are usually in the domain/business application and often not something that made anything quicker to develop or anything, but instead created by a developer that just couldn't help themselves
> ORMs
Certain ORMs such as Rails's ActiveRecord are part of the problem because they create the illusion that local memory access and DB access are the same thing. This can lead to N+1 queries and similar issues. The same goes for frameworks that pretend that remote network calls are just a regular method access (thankfully, such frameworks seem to have become largely obsolete).
The fact that this was seen as an acceptable design decision both by the creators, and then taken up by the industry is in an of itself a sign of a serious issue.
I think they’re referring to Electron.
Edit: and probably writing backends in Python or Ruby or JavaScript.
The backend programming language usually isn't a significant bottleneck; running dozens of database queries in sequence is the usual bottleneck, often compounded by inefficient queries, inappropriate indexing, and the like.
2 replies →