The general value of typed functional programming lies in leaving no edge cases • Hacker News Board

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

#151

Post by edflsafoiewq » Tue, Feb 25, 2020, 1:29 AM UTC

eru wrote: post #72

lmkg wrote: post #37

Earlier quoted context omitted.

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.

Personally I've found that although this argument sounds good in theory, in practice I don't find loops harder to read than chains of combinators.

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

#152

Post by [deleted] » Tue, Feb 25, 2020, 2:24 AM UTC

heartbeats wrote: post #121

Spivak wrote: post #78

Earlier quoted context omitted.

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.

C. typedef struct{int filled; union{void* data;} val;} maybe;

[deleted]

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

#153

Post by mac01021 » Tue, Feb 25, 2020, 2:37 AM UTC

ken wrote: post #144

saagarjha wrote: post #113

Earlier quoted context omitted.

How should it handle NaN? It's not clear where an incomparable value should go when sorting.

Why is NaN even a concept in modern languages? We don’t have a special “not a string” that all string functions return when they have no useful value to return.

Because what is the CPU supposed to do if you divide zero by zero or take the square root of -1?

It's actually not exactly a decision being made by the language designers. The IEEE standard governs the floating point logic embedded in ALU hardware. Programming languages tend to expose floating point math in its rawest form for performance reasons.

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

#154

Post by mac01021 » Tue, Feb 25, 2020, 2:39 AM UTC

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…

Interesting talk, but does that retry logic really provide me with more confidence about its correctness than equivalent impure code?

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

#155

Post by mac01021 » Tue, Feb 25, 2020, 2:52 AM UTC

fctorial wrote: post #123

OTOH it's nice to be able to do: try { // 500 lines catch (e) { return 4; }

As a mere mortal reading the code, I would rather not have to reason about try blocks longer than a couple of lines.

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

#156

Post by dpc_pw » Tue, Feb 25, 2020, 4:28 AM UTC

juskrey wrote: post #49

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…

Rust forces you to deal with edge cases using very low-order, often Procrustean bed reasoning. This does not mean there are much more powerful higher level ways of doing this. (Pattern matching I got in exchange have made me cry)

That is simply not true.

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

#157

Post by [deleted] » Tue, Feb 25, 2020, 4:31 AM UTC

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.

[deleted]

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

#158

Post by saagarjha » Tue, Feb 25, 2020, 9:04 AM UTC

ken wrote: post #150

saagarjha wrote: post #145

Earlier quoted context omitted.

Because it's part of IEEE 754.

So? There’s lots of old standards that don’t fit well with modern programming languages, so we abandoned them, or only use the parts that still make sense.

IEEE 754 is one of the standards like two's complement arithmetic which are widely used and have a number of clear advantages, so we continue to use them.

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

#159

Post by dep_b » Tue, Feb 25, 2020, 9:56 AM UTC

davinic wrote: post #75

justAnotherNET wrote: post #58

Earlier quoted context omitted.

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

Also Java has Optional and C# has Nullable .

The big difference is that nullability is the standard in Java and C# while in Swift it's the other way round, it's non-nullable unless you clearly indicate it's not.

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

#160

Post by juskrey » Tue, Feb 25, 2020, 9:58 AM UTC

dpc_pw wrote: post #156

juskrey wrote: post #49

Earlier quoted context omitted.

Rust forces you to deal with edge cases using very low-order, often Procrustean bed reasoning. This does not mean there are much more powerful higher level ways of doing this. (Pattern matching I got in exchange have made me cry)

That is simply not true.

If it forces you to check every single return code, this does not mean you can't have equivalently safe implementation without that level of detail.