Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Suppose I wanted to kill a lot of pilots

historyofyesterday.com

Post reply on HN
Print view View original

141–150 of 178 posts

Re: Suppose I wanted to kill a lot of pilots

#141

Post by ARandomerDude »

Kalium wrote: post #118
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…

> So why not explicitly ask them to? "So now we have our estimate, what would cause us to miss it?" I didn't used to take this seriously. Then one project I was on was delayed by several weeks when members of the team got jury duty, got injured, and had other medical emergencies in a rather short period. We still got it done, but I got a lesson that month in planning.

> I got a lesson that month in planning

What a great perspective. Many would turn to self-pity, you've turned to learning.

Re: Suppose I wanted to kill a lot of pilots

#143

Post by ARandomerDude »

BLanen wrote: post #68

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.

Oh good grief. Eat the meat and throw away the bones.

Re: Suppose I wanted to kill a lot of pilots

#144

Post by TeMPOraL »

formerly_proven wrote: post #84
mananaysiempre wrote: post #56

Earlier quoted context omitted.

For what it’s worth, theory of inventive problem solving is not a very good translation of теория решения изобретательских задач teorija rešenija izobretatelʹskih zadač : as far as I can see, it parses as [ inventive [ problem solving ]] with inventive meaning something like “unconstrained by convention, prolific intellectually, embodying the spirit of invention”, for which the proper Russian is изобретательный izobr…

> (and doesn’t afford a snappy acronym) TOSPOI even sounds Russian!

It still rolls off the tongue better than TANSTAAFL ("There ain't no such thing as a free lunch").

Re: Suppose I wanted to kill a lot of pilots

#145

Post by kortex »

macintux wrote: post #62
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…

It was mostly a quip that the first two anti-optimizations result in distributing the application across tons of machines. Since this is only the basis of the entirety of distributed computing, I thought it was only fair to include an instance where distributed computing patterns win out (fault tolerance and parallelization).

Re: Suppose I wanted to kill a lot of pilots

#146

Post by macintux »

kortex wrote: post #145
macintux wrote: post #62

Earlier quoted context omitted.

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

It was mostly a quip that the first two anti-optimizations result in distributing the application across tons of machines. Since this is only the basis of the entirety of distributed computing , I thought it was only fair to include an instance where distributed computing patterns win out (fault tolerance and parallelization).

Absolutely, it was a very solid post overall, including the nits I picked.

Re: Suppose I wanted to kill a lot of pilots

#147

Post by kortex »

marcosdumay wrote: post #136
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 -…

> The latter kind of feels like a criticism of FP It may feel like that for somebody with little experience with FP, but half of those points are design decisions that aren't changed by the language paradigm, and most of the rest is a non-sequitur where the stated problems aren't caused by the characteristic that precedes them. Immutability makes chaching easier, not harder, the same for propagating by reference. Bes…

Because it's not meant as a criticism of FP, or a list of FP things, in fact I actually really like FP. It's just that if you anti-optimize for bloat and slowness, you coincidentally end up with a lot of features that FP has.

Centralized state, immutability, wrapping, indirection, and nested data structures with garbage collection are very FP things. They are also almost always slower than mutate-everything imperative style, and require a lot more under the hood to make them performant. You basically need a clever compiler to really reap the benefits. Contrast with C with a dumb compiler, easy to get a fast, albeit buggy, program.

IO, bad caching, etc are very much not in the spirit of FP. The other points are just other bad things that I've seen a lot of apps do.

> Anyway, most of both lists apply perfectly to the modern "mandated microservices" architecture some place use, that I think was your point.

That was exactly my main point.

Re: Suppose I wanted to kill a lot of pilots

#148

Post by kortex »

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.

Yes, that's exactly what I was getting at. It was less a criticism of FP (which is why I say it feels like it might be - it's not) and more a criticism of the bevy of techniques common in modern full-stack development.

Even then I'm not saying it's bad to do thing that way. They absolutely have their place. OOP has its place. FP has its place. Distributed computing has its place and vertical scaling has its place. The point is, dogmatically latching onto "X bad! Y good!" blinds you to potential solutions.

Re: Suppose I wanted to kill a lot of pilots

#149

Post by kortex »

AussieWog93 wrote: post #77
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…

> 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.

Isn't that like, the main cause of most software headaches? insert joke about cache invalidation and naming things.

It sounds like you're saying bad caching can be worse than no caching. I can absolutely see that being the case.

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

Totally agree.

Re: Suppose I wanted to kill a lot of pilots

#150

Post by kortex »

jhgb wrote: post #73
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.

The problem is, semantically and linguistically, there are two OOPs. There's Smalltalk OOP and Java OOP. I haven't worked with Smalltalk but from everything I've heard, it "does object-oriented right". Unfortunately, Smalltalk just isn't popular (not even in the top 50 on the Tiobe index, though it fares slightly better on Redmonk).

For better or worse, Java is massively popular, and thus the Java conceptualization of OOP, which is just frankly bad, is what most people think of when they think OOP.

OOP encapsulation works when you can't have objects with invariants violated, and when you can't cover the combinatorial space with tests. The problem is, Java-style setters and getters are an almost guaranteed way to get the above properties. That's why it's better to be able to just have a small number of course-grained state stores that you can interrogate easily (REST, Reactors, databases, and Kubernetes data models all exhibit this). Class Employee inherits Person, doesn't. Too fine-grained, too easy to mutate yourself into an absolute mess.

Post reply on HN