←back to thread

837 points turrini | 2 comments | | HN request time: 0.471s | source
Show context
titzer ◴[] No.43971962[source]
I like to point out that since ~1980, computing power has increased about 1000X.

If dynamic array bounds checking cost 5% (narrator: it is far less than that), and we turned it on everywhere, we could have computers that are just a mere 950X faster.

If you went back in time to 1980 and offered the following choice:

I'll give you a computer that runs 950X faster and doesn't have a huge class of memory safety vulnerabilities, and you can debug your programs orders of magnitude more easily, or you can have a computer that runs 1000X faster and software will be just as buggy, or worse, and debugging will be even more of a nightmare.

People would have their minds blown at 950X. You wouldn't even have to offer 1000X. But guess what we chose...

Personally I think the 1000Xers kinda ruined things for the rest of us.

replies(20): >>43971976 #>>43971990 #>>43972050 #>>43972107 #>>43972135 #>>43972158 #>>43972246 #>>43972469 #>>43972619 #>>43972675 #>>43972888 #>>43972915 #>>43973104 #>>43973584 #>>43973716 #>>43974422 #>>43976383 #>>43977351 #>>43978286 #>>43978303 #
_aavaa_ ◴[] No.43972050[source]
Except we've squandered that 1000x not on bounds checking but on countless layers of abstractions and inefficiency.
replies(6): >>43972103 #>>43972130 #>>43972215 #>>43974876 #>>43976159 #>>43983438 #
pydry ◴[] No.43972103[source]
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.

replies(3): >>43972127 #>>43972262 #>>43975855 #
fsloth ◴[] No.43972127[source]
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.

replies(2): >>43972199 #>>43972414 #
pydry ◴[] No.43972199[source]
>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.

replies(2): >>43972407 #>>43972495 #
1. skydhash ◴[] No.43972407[source]
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.
replies(1): >>43973648 #
2. pydry ◴[] No.43973648[source]
slack is shit along all sorts of dimensions (not just speed and bloat) because you're not the customer.