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

71–80 of 172 posts

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

#71

Post by eru »

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.

Depends. Though some black-boxing is intended: thanks to enforced information hiding the compiler (and you) can make additional assumptions about what your code can not do.

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

#72

Post by eru »

lmkg wrote: post #37
Mirioron wrote: post #17

Earlier quoted context omitted.

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…

The problem with loops is that they are too powerful. They can do almost anything.

The functions map and filter are nice and restricted. If you want more power, you use eg a fold. And if you need even more power, you write a new recursive function.

So a quick look at the code will tell you what to expect.

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

#73

Post by heavenlyblue »

waheoo wrote: post #63
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…

Ive noticed other languages with this feature, they call them optional types, you can pass in a null or a type value. /s slightly, maybe more snarky, but seriously, optional types are way overhyped. Null objects are far more useful than optionals. Optionals tend to leak all over the show.

Only if you are speaking of Scalia?

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

#74

Post by Smaug123 »

waheoo wrote: post #63
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…

Ive noticed other languages with this feature, they call them optional types, you can pass in a null or a type value. /s slightly, maybe more snarky, but seriously, optional types are way overhyped. Null objects are far more useful than optionals. Optionals tend to leak all over the show.

Nulls leak exactly as badly as optionals, except it's additionally impossible to tell where nulls have leaked to.

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

#75

Post by davinic »

justAnotherNET wrote: post #58
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!

Also Java has Optional and C# has Nullable.

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

#76

Post by eru »

hinkley wrote: post #38
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?

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.

> Sometimes safety equipment lets you go faster.

Even simpler: brakes let you go faster.

When I was cycling a while ago, my brakes broke in the middle of a cross-country ride. I didn't want to push the bike back all the way, but you can bet your hat that I rode extremely slowly and cautious.

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

#77

Post by eru »

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.

The selling point of types (and type inference) is that they save you from having to write half your tests.

And of course, lines of code that you didn't have to write are less likely to have bugs in them.

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

#78

Post by Spivak »

munchbunny wrote: post #68
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…

> You can create a type that can encompass all kinds of edge cases and information about them. This is not unique to functional programming languages. Haskell was definitely a trailblazer for this, but plenty of conventional languages support this now with relative ease.

Any language with a type system at all can create a Maybe type. The difference is that failing to handle the None case is a runtime exception in most languages where in Haskel/Rust it won’t compile.

I don’t know of any mainstream language that has bolted on that level of verification.

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

#79

Post by Mirioron »

vippy wrote: post #33
Mirioron wrote: post #17

Earlier quoted context omitted.

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.

But I am already thinking about what the code should do. The problem is that if I read functional code I get bogged down in the details of what limits are set by the operations, because they're usually not as explicit. It's like reading a chain of functions on some element (actually, it quite literally is that).

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

#80

Post by swirepe »

heavenlyblue wrote: post #73
waheoo wrote: post #63

Earlier quoted context omitted.

Ive noticed other languages with this feature, they call them optional types, you can pass in a null or a type value. /s slightly, maybe more snarky, but seriously, optional types are way overhyped. Null objects are far more useful than optionals. Optionals tend to leak all over the show.

Only if you are speaking of Scalia?

>Scalia

:)

Post reply on HN