The Servers Are Burning • Hacker News Board

Re: The Servers Are Burning

#151

Post by Jeff_Brown » Fri, Sep 07, 2018, 4:42 PM UTC

bunderbunder wrote: post #89

noelwelsh wrote: post #10

How could such a tiny change have such an outsized impact on the site? “That same story happened so many different times,” my old boss David told me. “Someone launched a small, relatively innocuous change that did one of the millions of unexpected things it could have done, which then happened to break some part of the site, and then bring it all down—sometimes bring it down to the point where we couldn’t recover it…

By definition, pure functions can't read from or write to disk, can't read from or write to the database, and can't read from or write to a socket. If you aren't able to do any of those things, there is no "at scale" - you're trapped in a single process on a single computer, spinning away but not able to communicate with anyone else. Pure functional programming helps within an individual component by letting you quar…

> I'm not sure it makes sense to worry about whether > it's been quarantined, Haskell-style, or not. > It's still there

True, but the quarantine makes the bug much easier to find.

Re: The Servers Are Burning

#152

Post by mreome » Fri, Sep 07, 2018, 9:28 PM UTC

TheDong wrote: post #35

mreome wrote: post #20

Earlier quoted context omitted.

While I can understand some of the benefits of functional programming within a single sub-system, or within academic research, I struggle to understand how pure functional programming can address the need for the large amounts of state information and abstraction layers required for a large scale system. I work with systems where (large/numerous) sub components require very specialized domain knowledge to understand…

> Do you have anything that explains this complex topic? > Something that assumes I don't know anything about the pre-requisite topic would be helpful Unfortunately the only way to gain a deep understanding of the powerful tools functional languages do give you is to gain a deep understanding of functional paradigms. Me saying "Monads can help with state abstractions" doesn't help you. The fact that large non-trivial…

Unfortunately the only way to gain a deep understanding of the powerful tools functional languages do give you is to gain a deep understanding of functional paradigms.

If I didn't know what 'functional' was in this context, I'd be entirely convinced you were tying to convert me to your religion with that statement. This attitude from the functional-programming community is the main reason I have avoided learning more. I was asking a legitimate question and instead of providing something useful you decided to assume I don't know anything about the pre-requisite topic and spout verbose dogma at me that does nothing but attempt, and fail, to make you appear intelligent.

Re: The Servers Are Burning

#153

Post by mreome » Fri, Sep 07, 2018, 9:47 PM UTC

kbenson wrote: post #61

TheDong wrote: post #35

Earlier quoted context omitted.

> Do you have anything that explains this complex topic? > Something that assumes I don't know anything about the pre-requisite topic would be helpful Unfortunately the only way to gain a deep understanding of the powerful tools functional languages do give you is to gain a deep understanding of functional paradigms. Me saying "Monads can help with state abstractions" doesn't help you. The fact that large non-trivial…

> Unfortunately the only way to gain a deep understanding of the powerful tools functional languages do give you is to gain a deep understanding of functional paradigms. > I don't see why you need any more evidence that you should simply learn functional programming so that you may first-hand answer your own question. It is possible to interpret the GP comment as a request for good resources to learn FP. You seem lik…

Thank you. Basically I was looking for the functional-programming equivalent to the OOP factory-equipment analogy, or asking if such an analogy does/can exist (if it can't, the why might also be a valuable explanation). That analogy can be used to explain the main ideas behind encapsulation, interfaces, and internal state, and why they are valuable, before having any understanding of how those are implemented in practice, and even without any programming knowledge at all. So far everything I've found on functional programming starts with implementation details and provides no initial framework for understanding the broad-strokes of organisation and value proposition.

Re: The Servers Are Burning

#154

Post by mreome » Fri, Sep 07, 2018, 10:09 PM UTC

scns wrote: post #81

mreome wrote: post #20

Earlier quoted context omitted.

While I can understand some of the benefits of functional programming within a single sub-system, or within academic research, I struggle to understand how pure functional programming can address the need for the large amounts of state information and abstraction layers required for a large scale system. I work with systems where (large/numerous) sub components require very specialized domain knowledge to understand…

Maybe the blogpost "Functional architecture is ports and adapters" by Mark Seemann may be of help to you. "fsharp for fun and profit" by Scott Wlashin is really approachable. Cant post links since on mobile.

Thanks, I will take look at both of those.

Re: The Servers Are Burning

#155

Post by franzwong » Sat, Sep 08, 2018, 2:10 AM UTC

Sometimes I want to see how a piece of code work, I can just run the unit test. Otherwise, I may need to start the server, prepare some unrelated data, send a request to the server.

Re: The Servers Are Burning

#156

Post by chrisweekly » Sat, Sep 08, 2018, 2:20 PM UTC

berti wrote: post #137

shady-lady wrote: post #99

Earlier quoted context omitted.

what site? i can only see manning for $36. not on amazons.

I'm guessing this one (with a slightly different title: Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing) http://a.co/d/6tGlrUc

Yes, that's the $4.99 one I found.

http://a.co/7gJYjIx

Re: The Servers Are Burning

#157

Post by lavayya » Sat, Sep 08, 2018, 5:41 PM UTC

mreome wrote: post #153

kbenson wrote: post #61

Earlier quoted context omitted.

> Unfortunately the only way to gain a deep understanding of the powerful tools functional languages do give you is to gain a deep understanding of functional paradigms. > I don't see why you need any more evidence that you should simply learn functional programming so that you may first-hand answer your own question. It is possible to interpret the GP comment as a request for good resources to learn FP. You seem lik…

Thank you. Basically I was looking for the functional-programming equivalent to the OOP factory-equipment analogy, or asking if such an analogy does/can exist (if it can't, the why might also be a valuable explanation). That analogy can be used to explain the main ideas behind encapsulation, interfaces, and internal state, and why they are valuable, before having any understanding of how those are implemented in prac…

You might like Rich Hickey's talks, especially "The value of values", "The language of the System", and the 2018 conj key note. The Talk in transducers also has a nice analogy: the conveyor belt.

Re: The Servers Are Burning

#158

Post by toss1 » Mon, Sep 10, 2018, 9:04 PM UTC

nitrogen wrote: post #101

toss1 wrote: post #84

Earlier quoted context omitted.

Yup, classic. "...no time/resources to do it right in the first place, but plenty of time/resources to fix it when the customers complain..." I always thought it better to find the bugs in-house before shipping, but so many others don't see it...

The logic kind of makes sense if you consider that customers will only find a small fraction of the bugs that your team will. Sometimes the cost of removing all bugs is greater than the cost of losing customers to the few unlucky bugs that get found. But you really need experienced people deciding where that tradeoff lies for each company and project.

Yes, each individual customer is likely to find only a fraction of the bugs that your team finds.

But, many customers will collectively find much more.

the cost is more than an individual customer. It is everyone that customer comes into contact with and spreads word of the grief your bugs caused them.

Reputation can be very fragile.

The "deciding where the tradeoff lies" can easily lead to the Ford Pinto fiasco, where it was decided that the costs of the few lawsuits were less than the costs of the fix. After they'd _killed_ dozens of people and then got massive fines, that decision didn't look so good.

Quality is its own excuse. And yes, you cannot let the Perfect be the enemy of the Good and insist in fixing every nit, but Good should be Damn Good, not merely 'just ok, ship it infested with known bugs'.

You are supposed to make people's lives easier with a product, not merely extract their money.