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

91–100 of 172 posts

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

#91

Post by ska »

JoelMcCracken wrote: post #83
eru wrote: post #66

Earlier quoted context omitted.

Haskell still doesn't track NaN in the type system.

You're right, it does, and it exists at the value level if you are using floating point. But in Haskell you have, for example, Rational numbers to avoid many such problems. I was, however, surprised to not see any kind of a (significant) `safeDiv` function on hackage, and no NonZero newtype (outside of quickcheck). But, for this kind of thing its so easy to roll yourself, I am guessing this is what people do (and I h…

> But in Haskell you have, for example, Rational numbers to avoid many such problems.

Hey, it's for sure nice to have a rich numeric stack (see also some lisps), but in numeric work "use something else" is very rarely a practical answer to issues with IEEE-754.

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

#92

Post by LessDmesg »

hellofunk wrote: post #64
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…

Many people have their compilers set to enforce these things, and many of us go a step further and make our compiler warnings into errors so it’s impossible to build a program with these errors. That’s very commonplace, and C++ does it just fine. Missing cases in enums and at least 100 other very common matters can be checked at compile time in C++, the only difference is that it’s not the default as it is in some ot…

Enums are no substitution for sum types, though.

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

#93

Post by eru »

hinkley wrote: post #85
eru wrote: post #76

Earlier quoted context omitted.

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

Both brakes broke, or the front brake did? You can get by with just the front brake. Question is if you had enough tools to do that surgery. Would depend on the brakes. I don't think anybody remembers how shit bike brakes were before dual pivot came along. God bless Shimano and keep it forever. When I got my first set, I started emergency-braking with 2 fingers because I was worried I'd pole vault myself if I actuall…

Was a 'flevo racer' recumbent bike that I was still repairing, and had only one brake (front) at the time.

I was only a few kilometres from home.

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

#94

Post by fjp »

Izkata wrote: post #88
fjp wrote: post #86

Earlier quoted context omitted.

This just gave me the thought... if exception stack traces came with the argument values of each method call, they would be 1000x more helpful. You wouldn't even have to attach a debugger and step through in many cases.

I think they do in python, or at least can be retrieved. I know they show up in the stack trace on Sentry when an unhandled exception occurs.

Interesting, I guess they don't get spit out to the console by default.

Overall Python has really good stack traces, but the hyper-dynamic nature of so many common libraries does make it tough to grok sometimes.

I usually end up reaching for the PyCharm debugger which is fantastic anyway.

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

#95

Post by ridiculous_fish »

JoelMcCracken wrote: post #55
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

Haskell's intro page starts with the infamous minimalist quicksort, which mishandles NaN!

https://wiki.haskell.org/Introduction#Quicksort_in_Haskell

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

#96

Post by dmitriid »

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…

> This is of course a textbook case for Haskells Maybe concept. You can have a type that is a Maybe Int, and that means it have a value or it can be Nothing. Thus, you encompass the edge case of not having the value available

If you encompass it this way. Literally nothing stops you from encoding this behavior in Haskell. Because the behavior you described is *if revenue is equal to zero, display it as N/A".

No magic monad will prevent this.

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

#97

Post by howellnick »

LessDmesg wrote: post #84
davinic wrote: post #75

Earlier quoted context omitted.

Also Java has Optional and C# has Nullable .

That's not important in practice. What's important is that null infects all reference types in Java and C#, whether you asked for it or not. Just today I've spent a half an hour looking for a null dereference error - which the type system should've warned me of but didn't. The sad fact is, neither Java nor C# are fixable, because no new feature will fix the broken, null-unsafe code already written. All because of thi…

C# 8.0 introduced "Nullable Reference Types" (https://devblogs.microsoft.com/dotnet/embracing-nullable-ref...), which, if enabled, can help solve this problem.

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

#98

Post by fulafel »

Izkata wrote: post #88
fjp wrote: post #86

Earlier quoted context omitted.

This just gave me the thought... if exception stack traces came with the argument values of each method call, they would be 1000x more helpful. You wouldn't even have to attach a debugger and step through in many cases.

I think they do in python, or at least can be retrieved. I know they show up in the stack trace on Sentry when an unhandled exception occurs.

It's probably this:

https://docs.python.org/3/library/cgitb.html

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

#99

Post by [deleted] »

LessDmesg wrote: post #84
davinic wrote: post #75

Earlier quoted context omitted.

Also Java has Optional and C# has Nullable .

That's not important in practice. What's important is that null infects all reference types in Java and C#, whether you asked for it or not. Just today I've spent a half an hour looking for a null dereference error - which the type system should've warned me of but didn't. The sad fact is, neither Java nor C# are fixable, because no new feature will fix the broken, null-unsafe code already written. All because of thi…

[deleted]

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

#100

Post by navaati »

adgasf wrote: post #45

Conversely, it's also one of the biggest pain-points when throwing together a quick prototype.

Nah, you can totally use things like holes or undefined (in haskell), unimplemented!() in rust, etc.

EDIT: and, as neighbour says, any in typescript ! But typescript, with its progressive typing, is in a league of its own.

Post reply on HN