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

The Servers Are Burning

logicmag.io

Post reply on HN
Print view View original

61–70 of 158 posts

Re: The Servers Are Burning

#61

Post by kbenson »

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.

> 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 like you could probably point one or two out. Since they've already expressed a desire to understand, that might be more beneficial for them than the equivalent of "just do it".

Re: The Servers Are Burning

#62

Post by tobr »

macintux wrote: post #45
ddebernardy wrote: post #39

Earlier quoted context omitted.

The big problem I've noticed when reading unit tests in various projects is that they frequently test the implementation rather than the outcome: https://softwareengineering.stackexchange.com/a/304910/24932

That's one reason I really like functional programming: it's easier to test pure functions, vs code with side effects that requires you to look at the internal state afterwards.

On the other hand, pure functions are also much easier to reason about, thus much less likely to cause bugs from "a tiny change" in the first place. It's in the messy imperative stuff things tend to break in incomprehensible ways, and where you really need tests.

Re: The Servers Are Burning

#63

Post by TeMPOraL »

jerkstate wrote: post #53
matt2000 wrote: post #18

When making something new where you're not sure of the value yet, I've found that you can get 80% of the benefits of unit tests with around 20% of the tests you'd write to get "full coverage." My main goal is to at least have the code run in an expected way and produce an expected result. This doesn't catch everything, but it does seem to catch enough problems to be worth it for the time invested. Edit: I should ment…

I'm not a great programmer, I can't usually write code that does exactly what I expect the first time, so I use unit tests with a debugger in my IDE to run small portions of my new code until it works the way I envisioned it before I started writing it. This is a lot faster than my old method of writing code that doesn't quite work, and running the whole program over and over with small changes and print statements e…

> so I use unit tests with a debugger in my IDE to run small portions of my new code until it works the way I envisioned it before I started writing it.

In languages like Lisp, this is what you use REPL for. It's an insanely more efficient way of working than the usual edit->recompile->run the whole app again.

However, couple of years working with Common Lisp and (recently) Clojure taught me that, even with a good REPL at your disposal, properly testing code as you write it can get pretty unwieldy - especially if the inputs are complex/large. I found it beneficial to write unit tests and call them from REPL instead of testing the code in REPL directly, as it's easier to maintain and develop individual test cases, as well as re-test all of them when I alter the code I'm working on.

(That's of course apart from the fact that unit tests are more permanent, and provide value later on.)

TL;DR: thumbs up for writing unit tests even when working in an interactive programming environment.

Re: The Servers Are Burning

#64

Post by mikestew »

fhood wrote: post #40
mikestew wrote: post #19

Earlier quoted context omitted.

Mine do.

You can't possibly say that with any confidence. I literally just finished reproducing a memory leak caused by an insane combination of circumstances. This was not something valgrind or any similar tool would find. It was not something that any rational human being would have thought to write tests for. Once code is no longer synchronous, and tasks are being juggled around and swapped between, it becomes virtually im…

You can't possibly say that with any confidence

In answer to the original question, I stand behind my answer with 100% confidence. The test infrastructures I build catch memory leaks all of time, and I do not consider it abnormal for them to do so. If you mean to say that I cannot be confident that I have caught all of the memory leaks, well duh, of course I can't. But that's not what was asked, and that's not what I said.

To expand on what was actually asked, though, whether a framework catches all, some, or no memory leaks is irrelevant. Because if a team is at least testing for it, I'll bet they're just a bit more rigorous in their coding than a team that just deploys to production and waits to see what breaks.

Re: The Servers Are Burning

#65

Post by ozim »

3pt14159 wrote: post #41

I appreciated this article because I so infrequently get to hear from people that hold this view of testing, which I do not share. To me, the importance of tests are a function of the consequence of failure and the likelihood that failure will happen. It's a question of hazard and risk. One thing to realize is that code that lasts longer is more likely to fail because the people and libraries that support it are pron…

I think just SSHing to box and doing deploy is not function of users as you noticed but function of how many devs are working on project. For 1-2 devs manual deploy might be ok, when 3rd comes in, it is time to get rid of any magic that might happen when deploying by hand. Because you know someone will do something special and not document that, when he updates automated deploy he does not have to document or talk with other guys, it is documented in deploy tool.

Re: The Servers Are Burning

#66

Post by Jeff_Brown »

Static typing helps.

Higher order programming helps.

These are two reasons I love Haskell. The compiler does a lot of work of understanding your code for you, and makes it easy to query that metadata interactively, and refer to it from other parts of static code.

Haskell is of course not the only statically typed language, but its type system encompasses more, and more uniformly, than any other I am aware of. A lot of things that used to have to be part of the comments can now be first-class citizens.

Re: The Servers Are Burning

#67

Post by pjc50 »

bunderbunder wrote: post #44

> in order to write effective tests, a programmer had to know all of the ways that a piece of software could fail in order to write tests for those cases No. In order to write effective tests, a programmer has to think of the piece of software's entire input domain, carve it up into a set of equivalence classes, and then determine what the expected behavior should be for a piece of input from each of those classes. W…

> think of the piece of software's entire input domain, carve it up into a set of equivalence classes, and then determine what the expected behavior should be for a piece of input from each of those classes

This is an extremely good way of putting it. Doing some of this at the requirements stage if possible can be very helpful too, because you can detect nonsensical or conflicting requirements before you even write any code.

Re: The Servers Are Burning

#68

Post by selimthegrim »

fhood wrote: post #40
mikestew wrote: post #19

Earlier quoted context omitted.

Mine do.

You can't possibly say that with any confidence. I literally just finished reproducing a memory leak caused by an insane combination of circumstances. This was not something valgrind or any similar tool would find. It was not something that any rational human being would have thought to write tests for. Once code is no longer synchronous, and tasks are being juggled around and swapped between, it becomes virtually im…

Interested to see an AAR

Re: The Servers Are Burning

#69

Post by TeMPOraL »

pjc50 wrote: post #67
bunderbunder wrote: post #44

> in order to write effective tests, a programmer had to know all of the ways that a piece of software could fail in order to write tests for those cases No. In order to write effective tests, a programmer has to think of the piece of software's entire input domain, carve it up into a set of equivalence classes, and then determine what the expected behavior should be for a piece of input from each of those classes. W…

> think of the piece of software's entire input domain, carve it up into a set of equivalence classes, and then determine what the expected behavior should be for a piece of input from each of those classes This is an extremely good way of putting it. Doing some of this at the requirements stage if possible can be very helpful too, because you can detect nonsensical or conflicting requirements before you even write a…

Seconded. I haven't seen it summarized so well before, and the sentence you quoted is the very one that made me favourite that comment.

Re: The Servers Are Burning

#70

Post by TeMPOraL »

mabbo wrote: post #28
andrenotgiant wrote: post #4

Earlier quoted context omitted.

An outrageously unprofessional software process that created a product worth $50M! https://techcrunch.com/2011/02/02/match-com-acquires-online-...

That's not skill, that's luck. If the bug in question had instead leaked every customer's personal data there wouldn't be a $50m company, there'd be a multi-million dollar lawsuit.

I agree with your thinking, but with this particular example: you'd wish. See: every other data leak that happened over the last decade. It seems data leaks are harmless to companies.
Post reply on HN