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

The general value of typed functional programming lies in leaving no edge cases

np.reddit.com

Post reply on HN
Print view View original

31–40 of 172 posts

Re: The general value of typed functional programming lies in leaving no edge cases

#31

Post by dpc_pw »

Mirioron wrote: post #17
melling wrote: post #2

Edge case removed: for i=0 to 10 {print(a[i])} vs for x in a {print(x)} With functional programming it gets even better: a.filter {}.map{print} Pseudo code, of course. I list several “functional“ examples in Swift here: https://github.com/melling/SwiftCookBook/blob/master/functio... Functional programming is also a higher level language. map, reduce,filter, flatten, flapMap, drop, take, zip, ... Learn the concepts in…

While it does remove edge cases, the code also becomes more opaque. At least to me, functional style programming seems much harder to read and then reason about.

It takes some time to get used to and change mental model from "program describes step by step what to do" to "program describes logical flow of information".

I moved from first camp to the second one somewhere during my adult life. And IMO: Both are valid, sometimes first one is necessary (because that's how the machines actually work), but second one is clearly better most of the time for humans, especially in business-logic heavy cases.

Re: The general value of typed functional programming lies in leaving no edge cases

#32

Post by jcelerier »

seren wrote: post #19
jayd16 wrote: post #14

Earlier quoted context omitted.

You can use a functional style in those languages as well. Or do you mean with Rust's borrow checker you have less mutability to worry about?

If you have a Rust enum with Color{Red,Green,Blue), if for some reason you update to Color{Red,Green,Blue,Yellow}, the rustc compiler will force you to manage the new Yellow case wherever you want to "match" a pattern on Color, so overall you have less chance to forget to manage the new case everywhere. This kind of error is not managed by a C or C++ compiler (as far as I know). But from my understanding, this is not…

> This kind of error is not managed by a C or C++ compiler (as far as I know).

C++ had boost.variant which did exhaustiveness checking since ... 2002 (and an std version since C++17).

Re: The general value of typed functional programming lies in leaving no edge cases

#33

Post by vippy »

Mirioron wrote: post #17
melling wrote: post #2

Edge case removed: for i=0 to 10 {print(a[i])} vs for x in a {print(x)} With functional programming it gets even better: a.filter {}.map{print} Pseudo code, of course. I list several “functional“ examples in Swift here: https://github.com/melling/SwiftCookBook/blob/master/functio... Functional programming is also a higher level language. map, reduce,filter, flatten, flapMap, drop, take, zip, ... Learn the concepts in…

While it does remove edge cases, the code also becomes more opaque. At least to me, functional style programming seems much harder to read and then reason about.

This is a learning thing, honestly. Once you start thinking in types, it clicks: you're thinking at a higher level of abstraction, so the code is less important than understanding how the programmer put the types together in their head to solve a problem.

Re: The general value of typed functional programming lies in leaving no edge cases

#34

Post by hinkley »

AndrewDucker wrote: post #16
dleslie wrote: post #13

Earlier quoted context omitted.

The problem in my domain, games, is the frequent boxing and unboxing of values when using functional iterator interfaces in languages common to the industry, particulalry C#. It just thrashes the heap and forces often too-frequent gc.

I was under the impression that the way C# did generics meant that there was no need to box values. (Unlike Java, which treats all values as objects, even value types.)

Two ways to interpret boxing here:

1 Storing a primitive as a first class object

2 packaging and repackaging data

There may be situations where the former is not an issue, but the latter often is. If you don’t have a way to treat filter() as a generator/coroutine it means your traversing one collection and inserting those values into another, only to pass it to map() which iterates again and creates a third. If you’re doing that once a frame, maybe not a big deal. Three times per object per frame? That’s a lot of temporary data structures.

If the other responder is right, I speculate that the borrow checker forced someone’s hand in Rust and they found that a generator keeps the borrowed objects on the call stack where they already had tools to track ownership.

Re: The general value of typed functional programming lies in leaving no edge cases

#35

Post by ZephyrP »

AsusFan wrote: post #29
seren wrote: post #19

Earlier quoted context omitted.

If you have a Rust enum with Color{Red,Green,Blue), if for some reason you update to Color{Red,Green,Blue,Yellow}, the rustc compiler will force you to manage the new Yellow case wherever you want to "match" a pattern on Color, so overall you have less chance to forget to manage the new case everywhere. This kind of error is not managed by a C or C++ compiler (as far as I know). But from my understanding, this is not…

This isn't particular of Rust. Nim also forces you to deal with all possible branches of a case statement. I'm pretty sure other languages do so as well. This is just basic type safety stuff.

plenty of other languages do so, but it's both unfairly diminishing to the parent & questionably correct to refer to it as "basic type safety stuff"

Re: The general value of typed functional programming lies in leaving no edge cases

#36

Post by saityi »

Paul Snively (the author of the linked reddit post) also gave a great talk entitled 'Typed FP on the Job - Why Bother?' at LambdaConf a couple years back, that spoke strongly to me:

https://www.youtube.com/watch?v=8_HsFrXhZlA

> And now you can do the most important thing you can do with any piece of code... stop thinking about it! Go home! Pet the cat! Watch House with the wife! ... I love Friday deployments ... you know why? Because I know what my code is going to do before it runs!

Re: The general value of typed functional programming lies in leaving no edge cases

#37

Post by lmkg »

Mirioron wrote: post #17
melling wrote: post #2

Edge case removed: for i=0 to 10 {print(a[i])} vs for x in a {print(x)} With functional programming it gets even better: a.filter {}.map{print} Pseudo code, of course. I list several “functional“ examples in Swift here: https://github.com/melling/SwiftCookBook/blob/master/functio... Functional programming is also a higher level language. map, reduce,filter, flatten, flapMap, drop, take, zip, ... Learn the concepts in…

While it does remove edge cases, the code also becomes more opaque. At least to me, functional style programming seems much harder to read and then reason about.

It's subjective. My experience is exactly the opposite. A pipeline of sequence operations is something I can skim at a glance, but a for-loop is a pile of code that I need to stare at before I understand what it represents.

This does not invalidate your experience. It's common, and with good reason. This sort of dissimilar experience with the same code is why coding standards need to be views as social norms for the team using them, and not just technical things.

Re: The general value of typed functional programming lies in leaving no edge cases

#38

Post by hinkley »

finolex1 wrote: post #5
cryptica wrote: post #3

The goal of software development should be about reducing the number of edge cases to the absolute minimum. If a tool makes it easier to keep track of all edge cases, it is bound to encourage developers to write code which contains more edge cases. But fundamentally, it still reduces code quality. Code with more edge cases is less flexible and not good at handling changing requirements. I've seen this over and over i…

Isn't this akin to saying I don't like wearing seatbelts because it makes me more complacent in my driving?

Someone once describing the forces acting on a race car pointed out that the horizontal forced in a curve were high enough to throw you from the car if not for the five point harness (F1 probably doesn’t have this behavior due to the cockpit design).

Sometimes safety equipment lets you go faster.

Re: The general value of typed functional programming lies in leaving no edge cases

#39

Post by [deleted] »

saityi wrote: post #36

Paul Snively (the author of the linked reddit post) also gave a great talk entitled 'Typed FP on the Job - Why Bother?' at LambdaConf a couple years back, that spoke strongly to me: https://www.youtube.com/watch?v=8_HsFrXhZlA > And now you can do the most important thing you can do with any piece of code... stop thinking about it! Go home! Pet the cat! Watch House with the wife! ... I love Friday deployments ... you…

[deleted]

Re: The general value of typed functional programming lies in leaving no edge cases

#40

Post by threatofrain »

ZephyrP wrote: post #35
AsusFan wrote: post #29

Earlier quoted context omitted.

This isn't particular of Rust. Nim also forces you to deal with all possible branches of a case statement. I'm pretty sure other languages do so as well. This is just basic type safety stuff.

plenty of other languages do so, but it's both unfairly diminishing to the parent & questionably correct to refer to it as "basic type safety stuff"

JS has this too in TS, so I’m pretty sure the perception among users of typed languages is that this is a basic part of what type systems do. What does this have to do with FP?
Post reply on HN