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

Re: Suppose I wanted to kill a lot of pilots

#71

Post by eitland » Sat, Jul 03, 2021, 2:24 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.

I'm all for bashing unnecessary usage of Javascript, but I work with React a lot and I think there is room to make it a lot slower and more bloated, i.e. for what it is React is reasonably lean and performant.

Re: Suppose I wanted to kill a lot of pilots

#72

Post by greenie_beans » Sat, Jul 03, 2021, 2:25 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 -…

Sounds like a serverless app on AWS

Re: Suppose I wanted to kill a lot of pilots

#73

Post by jhgb » Sat, Jul 03, 2021, 2:28 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 -…

> Sounds familiar, maybe like a scathing criticism of OOP?

No, not really. For example:

> - make it hard/impossible to set the true state of the system in its entirety

Strangely enough, environments like Smalltalk allow you to do exactly that, but other environments not so much.

Re: Suppose I wanted to kill a lot of pilots

#74

Post by alisonkisk » Sat, Jul 03, 2021, 2:36 PM UTC

ethbr0 wrote: post #42

I first heard about this in the context of software project estimation. The author (forgotten to me) made the point that nobody has permission to think about disasters when estimating project completion time. So why not explicitly ask them to? "So now we have our estimate, what would cause us to miss it?" And in the course of giant monster attacks, you give people permission to talk about specific scenarios that are…

The reason no one does this is because thr answer is constant "something might fail and add an arbitrary delay"

once you hace committed to play the estimation game, you're committed to the delusion and reality checks dont matter. Just stop trying to estimate.

Re: Suppose I wanted to kill a lot of pilots

#75

Post by mmcconnell1618 » Sat, Jul 03, 2021, 2:37 PM UTC

Is this another way to help define the problem you're trying to solve? It sounds like "Keep pilots alive" wasn't detailed enough. By thinking about all the failure conditions, you're building a more robust description of the true problem you're trying to solve. I also wonder where you draw the line and stop thinking of failure conditions.

Re: Suppose I wanted to kill a lot of pilots

#76

Post by pjmlp » Sat, Jul 03, 2021, 2:38 PM UTC

bayesian_horse wrote: post #67

the__alchemist wrote: post #57

Earlier quoted context omitted.

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.

Thé irony being that JavaScript doesn't add anything that Smalltalk didn't already provide, yet we have all this OOP backslash and how FP is somehow better.

Re: Suppose I wanted to kill a lot of pilots

#77

Post by AussieWog93 » Sat, Jul 03, 2021, 2:44 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 wanted to make a program as slow and bloated as possible?

>put all state in one place.

>no caching.

Just as a counterpoint, both as a user and a developer I've found the main cause of performance issues and UI bugs come from a combination of distributed state and caching.

State being stored as a private member on the widget object itself is arguably more likely to cause a state desync bug or accidental O(N^2) behaviour than everything being global. IMGUI solves this but has only really seen a warm reception amongst the gaming industry (where, incidentally, UIs are always lightning fast despite being traditionally limited by older console/handheld hardware.)

Having a cache at the wrong level might reduce some function's execution time from 100us per frame to 10us, but makes it much more likely that the entire app will become unresponsive for 10s while some dumb bit of code rebuilds the whole cache 25,000 times in a row.

In a similar vein, I've found issues in multi-threaded apps where some function is sped up from 10ms to 2.5ms by making use of all four cores, but occasionally spins on a mutex, blocking the UI for 250ms if some slow path (usually network/disk IO) is taken.

Genuinely, I think the simplest way to make sure a program will have bad performance just requires one step:

- Make it difficult for a human programmer to reason intuitively about the performance of the code they write.

Re: Suppose I wanted to kill a lot of pilots

#78

Post by mortenjorck » Sat, Jul 03, 2021, 2:48 PM UTC

ethbr0 wrote: post #42

I first heard about this in the context of software project estimation. The author (forgotten to me) made the point that nobody has permission to think about disasters when estimating project completion time. So why not explicitly ask them to? "So now we have our estimate, what would cause us to miss it?" And in the course of giant monster attacks, you give people permission to talk about specific scenarios that are…

I once worked on a team that did something along these lines and referred to it as a “pre-mortem.” We basically held a meeting where we imagined the project in its concluded state and discussed what “went wrong.”

Re: Suppose I wanted to kill a lot of pilots

#79

Post by jhgb » Sat, Jul 03, 2021, 2:54 PM UTC

bayesian_horse wrote: post #65

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.

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 fro…

> If you are at war with your technology, your codebase will look like a battlefield.

That almost sounds like a criticism of people who developed React and Redux and went to war against their browser APIs.

Re: Suppose I wanted to kill a lot of pilots

#80

Post by oceanghost » Sat, Jul 03, 2021, 2:54 PM UTC

jacquesm wrote: post #45

ethbr0 wrote: post #42

I first heard about this in the context of software project estimation. The author (forgotten to me) made the point that nobody has permission to think about disasters when estimating project completion time. So why not explicitly ask them to? "So now we have our estimate, what would cause us to miss it?" And in the course of giant monster attacks, you give people permission to talk about specific scenarios that are…

Spot on. They used to call me 'Dr. No' because that is exactly what I would do, but it saved us tons of money so it was tolerated. We also actually delivered on time and within the budget but I'm sure it cost us contracts to more optimistic competitors.

This. Most engineers delude themselves and plan for the happy path.

I was famous too for "being negative." In the planning of a complex project once a rather dull engineer, after I had just pointed out a major potential problem asked, "Why are you so negative?"

"I'm not negative, I'm planning for success."