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

51–60 of 172 posts

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

#51

Post by ken »

They say that, and then turn around and show an example using IEEE-754 Doubles. You've got two infinities and two "not a number" values. What your type system thinks is a number isn't even necessarily a number. Maybe.

Better be sure to call the "isNaN()" and "isInfinite()" methods all over the place, because those are the worst edge cases of all and your language provides no help in detecting or avoiding them. It's like having 3 or 4 other None values, where they don't even use the same system as your standard Option type.

If I had a nickel for every time I saw "NaN" appear on a webpage or a web browser console log ... We throw up our hands and say, yeah, well, JS is terrible -- but no static functional language I know of is any better.

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

#52

Post by arcticbull »

jerf wrote: post #28
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…

This is also one of the problems with programming with exceptions. You lean on the fact that an exception will be thrown and just propogate up until it finds something, so the normal mindset of an exception-based programmer is to program for the happy-case and only vaguely think about what happens if it goes wrong. I know, I've written a lot of code in this style for many years myself. In some cases, that's not a pro…

Exceptions are the worst because there's a hidden nested world of control flow you can't barely begin to reason about. Exceptions are a "comes-from" statement, like a "goto" but much worse.

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

#53

Post by arcticbull »

cptskippy wrote: post #48
jerf wrote: post #28

Earlier quoted context omitted.

This is also one of the problems with programming with exceptions. You lean on the fact that an exception will be thrown and just propogate up until it finds something, so the normal mindset of an exception-based programmer is to program for the happy-case and only vaguely think about what happens if it goes wrong. I know, I've written a lot of code in this style for many years myself. In some cases, that's not a pro…

> the normal mindset of an exception-based programmer is to program for the happy-case and only vaguely think about what happens if it goes wrong. I'm not sure that's such a bad thing. Exception handling doesn't mean you should be handling all exceptions, just that you can recover if one does occur. If an exception is 100% relevant to what you're doing then yes absolutely handle it, or even clean up your own state be…

> Exception handling doesn't mean you should be handling all exceptions, just that you can recover if one does occur.

You can't because you don't know where it came from so you don't know what happened, why, or if it was recoverable. You can take a stab at it, but that's it.

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

#54

Post by SAI_Peregrinus »

seren wrote: post #27
ZephyrP wrote: post #24

Earlier quoted context omitted.

If you compile with `-Wall` GCC will emit a warning for failing to exhaustively check enum values inside a switch statement (I don't remember the specific underlying feature flag name, sorry). EDIT: It's called `-Wswitch`

Yes, apparently, there is a -Wswitch statement in gcc, which looks quite similar, maybe I have used too old compilers... > Warn whenever a switch statement has an index of enumerated type and lacks a case for one or more of the named codes of that enumeration. (The presence of a default label prevents this warning.) case labels outside the enumeration range also provoke warnings when this option is used (even if ther…

The issue with -Wswitch (and thus -Wall) is that the presence of a default case suppresses the warning. Which you may not want, if you need non-default behavior because you're adding a new value! There's -Wswitch-enum (not turned on by -Wall or -Wextra) that stops this being suppressed. This is good, though the (possible) list of cases that are well-handled by the default at the end of switches that just fall-through can be ugly.

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

#55

Post by JoelMcCracken »

ken wrote: post #51

They say that, and then turn around and show an example using IEEE-754 Doubles. You've got two infinities and two "not a number" values. What your type system thinks is a number isn't even necessarily a number. Maybe. Better be sure to call the "isNaN()" and "isInfinite()" methods all over the place, because those are the worst edge cases of all and your language provides no help in detecting or avoiding them. It's l…

Haskell is so much better, and you would learn that with about 5 minutes learning about the number types

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

#56

Post by adamch »

ken wrote: post #51

They say that, and then turn around and show an example using IEEE-754 Doubles. You've got two infinities and two "not a number" values. What your type system thinks is a number isn't even necessarily a number. Maybe. Better be sure to call the "isNaN()" and "isInfinite()" methods all over the place, because those are the worst edge cases of all and your language provides no help in detecting or avoiding them. It's l…

You can always use a fixed-precision numeric type.

You might be thinking "what about libraries that require floating-point", and that's a good concern. Luckily in Haskell there's the Num typeclass, so your libraries can let users use whatever fractional number type they'd like.

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

#58

Post by justAnotherNET »

hristov wrote: post #44

I am not sure this is the only value, but it is generally true. And this is one of the great advantages of haskell. By the way, now that I know some haskell, I see this edge case sloppiness all the time and it is really annoying. For example, here is something that annoyed me just recently. You go to yahoo finance and there they will show you the revenues of a company as well as the revenue growth from past year. But…

Swift has this as well, but calls them “Optional”. The concept is definitely useful!

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

#59

Post by thewebcount »

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…

I program mainly in C++, and I often start off writing things as:

    for (auto x : someContainer) { //do something with x }
But inevitably, I end up needing either an iterator pointing to a particular item at the end, or I need an index to pass to some other function, and this style makes that impossible. Perhaps it's just the domain I work in, but even after years of trying to make this work, it still only works about half the time for what I'm doing.

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

#60

Post by Naac »

phibz wrote: post #57

For me the value of typed functional programming has been it's ability to encode business logic in to the type system and thus validate some of my logic at compile time.

What's specifically functional about this advantage. Can't you encode the buisness logic into types in non-functional languages as well?
Post reply on HN