Hacker News Reader

> [I]t should be the default that the status quo is a bad thing; instead of justifying why something should be done, the burden of proof should rest on those who believe things should remain the same.

This is the opposite of Chesterton's Fence, the idea that knowledge is often encoded in the current state of things, and you should seek to understand what that is before changing it.

https://fs.blog/2020/03/chestertons-fence/

I too took particular issue with the second point; among other possible criticisms, the categorical statement that "the status quo is a bad thing" seems to completely miss the idea of "embedded wisdom." Surely this idea should be familiar to anybody who's spent enough time reading about software development?

I suppose the point could be interpreted to mean "investigate the assumptions of the status quo and find out which ones are no longer valid" - but then, that's not what Thompson wrote.

As to points one and three - I don't buy that "free speech is good" is no longer the default and I don't see much in this essay that shows otherwise. The example given (Youtube censoring perspectives that contradict the WHO, despite the WHO itself having disseminated falsehoods) leads directly to the questions: should Youtube not have been allowed to make that decision? And if not, how should they have been prevented?

As to the third point - revisiting the example just discussed, surely the WHO's communications (of which Thompson seems critical) could be seen as an example of an organization hewing to the very default he asserts as valuable? Move fast with your communications, value early release over perfect certainty, etc.

I had a similar feeling. I think the point that TFA is making is that our world is changing quickly and profoundly enough that "we've always done it this way and we know it works ok" is not as useful a heuristic as it might once have been.

We shouldn't thoughtlessly discard proven ways of doing things, but we may need to update the weight that we give them. What worked well in 1990 isn't as likely to work today as 1960's practices were in 1990.

> Imagine tossing a coin that has a 0.001:99.999 probability split. Just 0.001% chance that you will be killed vs 99+% chance that you won't. Believe me, you don't want to be tossing this coin in a macro scale OR way too many times.

That has to be some kind of named law: As the volume of a system increases, tolerance for failure decreases. Used in cases of: 1% failure of a hundred might be acceptable, but 1% failure of a million isn't.

Weirdly enough, we see this all the time in large systems. When we built DynamoDB - the core 3-way replication is based on the fact that machine failure rates are something like 0.005, so we will need to be unlucky (0.005)^2 times. Guess what? it happens alarmingly often enough when you run 100k boxes.

Just call it "Murphys Law of Large Numbers":

The higher your scale, the faster it will fail.

We (humans) run on some 37 Trillion cells and don’t fail very often compared to computers; blue whales scaled for size could have ten quadrillion cells and they don’t get cancer.

Maybe its not a law of large numbers, but one of medium numbers (in the sense of Dawkin’s Middle World is human scale or Ron Graham speculating that maybe all the most interesting math is in the very large numbers we can’t work with)

We fail all the time. We get illover every silly thing, develop cancer, break down little by little over time. It's just that we evolved to handle this better than a artificial designed high spec-machine which was primary optimised for low budget.

Yeah, I think they are overstated. The status quo should be questioned and forced to justify itself, but not just ignored thoughtlessly. We should move fast and tolerate risk when the cost of delay is very high (like thousands of people dead per day) but not when it's low.

I also like to use this coin toss analogy as one of my arguments against the use of Type4 GUID keys. Consider a hypothetical: SQLite is to be used to mediate the monitoring, arming and detonation of a thermonuclear warhead. Would you want to use Type4 GUID keys or integer keys for the arming sequence table? Why not just take that extreme as the normal, and use boring & safe approaches everywhere? Assume everything can explode in horrible ways that you could never hope to anticipate. All you really need to do is make sure the explosion is impossible within your problem domain, or is at least manageable if it does occur.

An observation I have happened upon recently: The more time you spend away from the computer thinking about the problem you want to solve with the computer, the better the outcome will be. Spending a few days to consider the pros/cons of various business entity identity schemes is probably worthwhile when weighing the long term consequences.

A better argument against Type 4 GUID keys is that random distribution of your primary key doesn't preserve temporal locality in indexes. If you have a big enough keyspace to worry even in the slightest about collisions in 122 bits, you have a bigger index than will comfortably fit in memory. Under those circumstances, random key lookups will thrash your cache. If you access multiple rows at a time which were allocated close together in time - not unusual with normalized schema - you'll want them adjacent in the index too.

Any reasonable database index implementation will utilize data structures which address this exact flavor of concern. Concepts like the splay tree can optimize the locality of access dynamically based upon actual access patterns over time. But, you are right in that this locality of access property is available by default using integral types without the constraint imposed of needing to use a particular kind of dynamic data structure.

Plenty of databases use b+trees, which don't address this exact flavour of concern. In my direct experience, MySQL will perform quite poorly with lots of random lookups once your index starts getting to a meaty size.

Your coin flip is in a vacuum though. What is this innovation replacing? Did I previously have to roll a 100-sided die? If so, that coin flip sounds really damn good.

I feel like Technology Connections did a better approach to the same topic of innovation:

https://youtu.be/GiYO1TObNz8?t=335

The idea is "But Sometimes". That is, this new innovation is great in all these areas, but sometimes it's worse. That then becomes a locus for the FUD campaigns -- justified or not. It's also the same kind of thing heard in "no one was ever fired for picking IBM". Fear of an unknown potentially bad outcome outweighs all the known bad outcomes which are improved by the innovation.

I don't understand the advantage of rolling a 100side die vs 99% biased coin flip - assuming they are balanced right, both should be equivalent.

I was just remarking on the outright pointers in those two points that status quo is bad / speed of change is god etc. - There is a difference between being against change and being resistant to change.

I am all for incremental changes because I strongly believe existing tested and hairy systems got there by handling a million corner cases that the new one is probably going to solve all over again.

Replacement systems become warranted only in those cases where earlier systems have lost any form of iterability and are stuck per-say and have been obsoleted in some ways. Most of the other scenarios are just developer job-security :)

Again all the above apply only for reasonably complicated systems. I am all for hello world's getting rewritten every day.

Your example was a 0.001% to 99.999% ratio, which is like rolling a 100,000 sided die, if I understand correctly. That would be much safer than rolling a 100-sided die (1% chance to fail) the same number of times.

> Imagine tossing a coin that has a 0.001:99.999 probability split. Just 0.001% chance that you will be killed vs 99+% chance that you won't. Believe me, you don't.

That's how I feel when people throw stats at random. Especially airplane vs car safety.