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

11–20 of 172 posts

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

#11

Post by Allower »

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…

Last I checked functional programming doesn't have a monopoly on "map, reduce,filter, flatten, flapMap, drop, take, zip", these are functions and can be implemented in any language, object oriented or otherwise.

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

#12

Post by cortesoft »

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…

This doesn't really make any sense. The idea that forcing you to handle all cases will encourage creating more edge cases is nonsensical.

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

#13

Post by dleslie »

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…

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.

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

#14

Post by jayd16 »

nicoburns wrote: post #4

Forget the performance or the fancy memory management stuff, this is one of the best things about Rust: it makes you deal with edge cases by default (while allowing you to write code in a largely imperative or functional-lite style). It's why I think it competes for market share with some of what is currently Java/C# and similar languages. A lot of people who use those languages care about correctness, and Rust is bi…

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?

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

#15

Post by Verdex »

cryptica wrote: post #10
finolex1 wrote: post #5

Earlier quoted context omitted.

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

It could actually be the case that seat-belts make drivers more complacent but the key difference in the case of coding is that you won't die if you make a typo in your code. If designed correctly, your tests will catch it anyway.

Therac-25 [1] disagrees with your statement. Although to be fair, the programmer didn't die. The patients did.

[1] - https://en.wikipedia.org/wiki/Therac-25

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

#16

Post by AndrewDucker »

dleslie wrote: post #13
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…

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

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

#17

Post by Mirioron »

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.

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

#18

Post by cjfd »

cryptica wrote: post #10
finolex1 wrote: post #5

Earlier quoted context omitted.

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

It could actually be the case that seat-belts make drivers more complacent but the key difference in the case of coding is that you won't die if you make a typo in your code. If designed correctly, your tests will catch it anyway.

Your tests? You should despise tests if you want to be consistent with the attitude described in your first post.

In the mean time I will just keep using my strongly typed language and, of course, also automated tests. Thank you very much.

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

#19

Post by seren »

jayd16 wrote: post #14
nicoburns wrote: post #4

Forget the performance or the fancy memory management stuff, this is one of the best things about Rust: it makes you deal with edge cases by default (while allowing you to write code in a largely imperative or functional-lite style). It's why I think it competes for market share with some of what is currently Java/C# and similar languages. A lot of people who use those languages care about correctness, and Rust is bi…

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 directly related to the borrow checker, which tracks who owns a reference and is allowed to modify it or not.

(That being said if you had a "default" case earlier, the compiler won't complain)

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

#20

Post by woah »

jayd16 wrote: post #14
nicoburns wrote: post #4

Forget the performance or the fancy memory management stuff, this is one of the best things about Rust: it makes you deal with edge cases by default (while allowing you to write code in a largely imperative or functional-lite style). It's why I think it competes for market share with some of what is currently Java/C# and similar languages. A lot of people who use those languages care about correctness, and Rust is bi…

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?

The borrow checker takes care of a lot of the things that many functional patterns are supposed to prevent, such as referencing values in two locations.
Post reply on HN