Suppose I wanted to kill a lot of pilots • Hacker News Board

Re: Suppose I wanted to kill a lot of pilots

#61

Post by kolinko » Sat, Jul 03, 2021, 2:06 PM UTC

dTal wrote: post #59

> rather than solving for success, solve for failure. If you want to design a dust filter that works at 600 Celsius within a steel mill, instead design all the ways you could develop a filter that would fail miserably in those conditions. That's a strange example. There are infinite ways of not accomplishing a task, and as a non-expert in filter design I have no trouble listing them: make the filter out of butter, ma…

The point is to make a filter that works in lower temperatures but breaks around 600C.

Using the other example - of course to kill the most pilots you coukd out them in a big meat grinder or just blow up their planes. But the point is to design planes so that they both fly and kill pilots.

Re: Suppose I wanted to kill a lot of pilots

#62

Post by macintux » Sat, Jul 03, 2021, 2:09 PM UTC

kortex wrote: post #25

Suppose I wanted to make a program inscrutable, hard to modify, hard to test, heavily coupled, and hard to reason about: - hide information so that it's not queryable - force information to flow through multiple hops - make it hard/impossible to set the true state of the system in its entirety - allow state to be mutated silently - give interfaces roles and force certain state to have to flow through specific paths -…

> What if I want to make my app as vulnerable to outage and overload as possible?

> - concentrate the app in as few machines as possible

Well, sorta. Distributing an application across multiple machines only reduces downtime if the machines are independent of each other.

I've seen bad architectures where wider distribution leads to more outages, not fewer. I even consulted for a company who had their services in two data centers for redundancy, but they put different services in each one, so a failure in either data center would effectively bring down their entire stack.

Re: Suppose I wanted to kill a lot of pilots

#63

Post by mannykannot » Sat, Jul 03, 2021, 2:12 PM UTC

kortex wrote: post #25

Suppose I wanted to make a program inscrutable, hard to modify, hard to test, heavily coupled, and hard to reason about: - hide information so that it's not queryable - force information to flow through multiple hops - make it hard/impossible to set the true state of the system in its entirety - allow state to be mutated silently - give interfaces roles and force certain state to have to flow through specific paths -…

For the most part I agree, but if you ask "suppose I want [a conjunction of deprecated outcomes]" then it is possible that something tending towards one of these deprecations may protect against another. For example, hiding information so that it is not queryable may make testing and certain modifications more difficult, but encourage heavy coupling, which in turn makes a program hard to reason about and therefore also inscrutable - and thus, one further step removed, harder to test and modify.

Re: Suppose I wanted to kill a lot of pilots

#64

Post by GormanFletcher » Sat, Jul 03, 2021, 2:14 PM UTC

dTal wrote: post #59

> rather than solving for success, solve for failure. If you want to design a dust filter that works at 600 Celsius within a steel mill, instead design all the ways you could develop a filter that would fail miserably in those conditions. That's a strange example. There are infinite ways of not accomplishing a task, and as a non-expert in filter design I have no trouble listing them: make the filter out of butter, ma…

I interpreted it as brainstorming ways to actively sabotage success. "Solutions" that appears superficially plausible, but undermine the outcome in real world situations.

So for the dust filter, maybe selecting a material that's only rated for high temperatures in short bursts. Or one that needs frequent, labor-intensive replacements in that dangerous environment. Or test that your filter survives at high temperatures, and test the filtration efficacy, but forget to test the efficacy at high temperatures.

Re: Suppose I wanted to kill a lot of pilots

#65

Post by bayesian_horse » Sat, Jul 03, 2021, 2:16 PM UTC

golergka wrote: post #31

kortex wrote: post #25

Suppose I wanted to make a program inscrutable, hard to modify, hard to test, heavily coupled, and hard to reason about: - hide information so that it's not queryable - force information to flow through multiple hops - make it hard/impossible to set the true state of the system in its entirety - allow state to be mutated silently - give interfaces roles and force certain state to have to flow through specific paths -…

> What if I wanted to make a program as slow and bloated as possible? That sounds like a very exact description of React/Redux.

If you are at war with your technology, your codebase will look like a battlefield. React and Redux require a functional, reactive mental model. If you approach it with an imperative mindset, you'll get a mess of a codebase.

Unfortunately the popularity of React means it is used by people who know neither Javascript nor FP very well. And the popularity of Redux is even worse.

In my opinion people should stay away from Redux until they know and understand intuitively why it is necessary. Until then, use the useState and useReducer hooks, then maybe something like "Zustand". When you start using Redux, use Redux Toolkit.

Re: Suppose I wanted to kill a lot of pilots

#66

Post by Kuinox » Sat, Jul 03, 2021, 2:17 PM UTC

fastball wrote: post #51

golergka wrote: post #31

Earlier quoted context omitted.

> What if I wanted to make a program as slow and bloated as possible? That sounds like a very exact description of React/Redux.

We've built a React/Redux application[1] that people keep telling us is very snappy, and we definitely haven't optimized as much as is possible, so from my experience React/Redux is not inherently slow and bloated. [1] https://my.supernotes.app

The main page is not snappy at all, on my phone when I click on a link on the top bar it takes at least 2 seconds before it changes the page

Re: Suppose I wanted to kill a lot of pilots

#67

Post by bayesian_horse » Sat, Jul 03, 2021, 2:21 PM UTC

the__alchemist wrote: post #57

kortex wrote: post #25

Suppose I wanted to make a program inscrutable, hard to modify, hard to test, heavily coupled, and hard to reason about: - hide information so that it's not queryable - force information to flow through multiple hops - make it hard/impossible to set the true state of the system in its entirety - allow state to be mutated silently - give interfaces roles and force certain state to have to flow through specific paths -…

Your FP example reminds me of the JS trend that picked up about 5 years ago. Not sure if they're still doing it, but you described the dogma near perfectly.

Because imperative programming in Javascript, even with OOP principles and patterns, generally leads to even more complexity and messiness.

FP is now almost the norm in frontend engineering. Certainly in the React world. Immutability and side-effect-awareness is highly valued.

Re: Suppose I wanted to kill a lot of pilots

#68

Post by BLanen » Sat, Jul 03, 2021, 2:21 PM UTC

I like how it references the Gulag Archipelago which two links to buy it, a pseudo-historical book. For no reason. Except for that a certain controversial person likes to talk about it a lot.

Of course 3 articles back they reference Jordan Peterson.

Re: Suppose I wanted to kill a lot of pilots

#69

Post by panax » Sat, Jul 03, 2021, 2:21 PM UTC

kaycebasques wrote: post #11

HN loves this idea of thinking in reverse. Is anyone here actually doing it? What problem did you solve?

In security the forward problem isn't as useful - adding security features/crypto is easy but probably not going to be helpful on its own. We use threat modeling and the security mindset. What is the easiest way for me to break the system/program? Where can I manipulate the inputs to the system? Where were the developers most likely to have made a mistake and what kinds of mistakes are commonly made there?

Also similar in nature is safety engineering. You think about how to make the system fail easily and unexpectedly and you avoid those.

You also try to prioritize the highest risk/lowest cost issues in these. These all involve risk management, which is also critical in investing and is a major reason why Munger has been so successful - he only goes for low risk/high reward plays and bets big on the few opportunities that he gets.

Re: Suppose I wanted to kill a lot of pilots

#70

Post by dhruvarora013 » Sat, Jul 03, 2021, 2:21 PM UTC

the__alchemist wrote: post #57

kortex wrote: post #25

Suppose I wanted to make a program inscrutable, hard to modify, hard to test, heavily coupled, and hard to reason about: - hide information so that it's not queryable - force information to flow through multiple hops - make it hard/impossible to set the true state of the system in its entirety - allow state to be mutated silently - give interfaces roles and force certain state to have to flow through specific paths -…

Your FP example reminds me of the JS trend that picked up about 5 years ago. Not sure if they're still doing it, but you described the dogma near perfectly.

Do you mean Redux? If yes, it's still quite popular