Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The power of Result types in Swift

swiftbysundell.com

Post reply on HN
Print view View original

71–77 of 77 posts

Re: The power of Result types in Swift

#71

Post by cousin_it »

KirinDave wrote: post #64
cousin_it wrote: post #55

Earlier quoted context omitted.

I think "sum-type errors" are the wrong default. They force you to deal with the bureaucracy of different error types, which is useless because error handling almost never cares about error type. And they don't give you a stack trace, which is a lifesaver for development and debugging. Plain old unchecked exceptions work better. Probably cheaper too, because sum types require wrapping and unwrapping at each step, whi…

> I think "sum-type errors" are the wrong default. They force you to deal with the bureaucracy of different error types, which is useless because error handling almost never cares about error type. I hear this parroted a lot, and I really don't get it. When an exception happens, you can't resume control flow (unless you're in Common Lisp, which has an objectively better system for exceptions than any we use). In that…

Yeah, agreed that exceptions make the exceptional path more expensive. But I think the normal path is cheaper.

I'm not sold on resumable exceptions. It makes more sense to pass default values directly. Have you seen this bit in Stroustrup's book: http://www.cpptips.com/term_except

Re: The power of Result types in Swift

#72

Post by pjmlp »

khitchdee wrote: post #68
pjmlp wrote: post #62

Earlier quoted context omitted.

If not even Linux kernel developers with their merge review process and stress tooling are good at it, what to say of the more mundane developer... https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm... http://openwall.com/lists/oss-security/

Some people develop good coding techniques, like Donald Knuth. If you're new, you set out on your own or read up on what they've done or get lucky and work with a good programmer. That's how you pick it up. But, it's all pedal to the metal. Knuth's entire work is for C. Nowadays, everything is done at a high level using some kind of pre-existing framework and the type of code being written is cookie-cutter so none of…

So you are stating no one on Linux kernel development is a match to Donald Knuth, and given the CVE track record they should improve themselves to Donald Knuth level.

If there is anything new about Swift, it is a return to the past of proper programming languages.

"Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue....

Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels?

Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities."

-- Fran Allen interview, Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming

Re: The power of Result types in Swift

#73

Post by KirinDave »

cousin_it wrote: post #71
KirinDave wrote: post #64

Earlier quoted context omitted.

> I think "sum-type errors" are the wrong default. They force you to deal with the bureaucracy of different error types, which is useless because error handling almost never cares about error type. I hear this parroted a lot, and I really don't get it. When an exception happens, you can't resume control flow (unless you're in Common Lisp, which has an objectively better system for exceptions than any we use). In that…

Yeah, agreed that exceptions make the exceptional path more expensive. But I think the normal path is cheaper. I'm not sold on resumable exceptions. It makes more sense to pass default values directly. Have you seen this bit in Stroustrup's book: http://www.cpptips.com/term_except

Actually, I'm not entirely right here. Joe Groff caught up with me on twitter and explained to me that because Swift requires you to check exceptions, it actually generates static logic at the call site. This means handlers have a cost on both sides of the "railway", but it means that exception handling has a fairly optimal codepath.

It'll still be cheaper to do a simple pattern match into a struct for complex handlers, but for depth 1 they should essentially be identical. That's a very interesting tradeoff for the Swift compiler!

Re: The power of Result types in Swift

#74

Post by Smaug123 »

_pmf_ wrote: post #58
Smaug123 wrote: post #2

I've seen this referred to as "railway programming", and there's a wealth of explanation over at https://fsharpforfunandprofit.com/rop/ . In particular, the slide deck from the FP eXchange contains a diagram (slide 75 out of 154) with a happy path along the top, and a sad path along the bottom, and at every stage when you `bind` a Result into an existing Result, you have the opportunity to divert into the sad path. N…

I refuse to see where the difference to exception handling is. My exceptions bubble up to my "sad path" handler.

Your phrasing ("I refuse to see…") makes me very apprehensive of trying to explain, but I'll bite.

Using exceptions is dealing with errors out-of-band. Using Result types is dealing with errors in-band. In-band is somewhat less flexible because you don't have the power to arbitrarily alter the execution flow of your program. Out-of-band is much easier to reason about by that very token.

Re: The power of Result types in Swift

#75

Post by khitchdee »

pjmlp wrote: post #72
khitchdee wrote: post #68

Earlier quoted context omitted.

Some people develop good coding techniques, like Donald Knuth. If you're new, you set out on your own or read up on what they've done or get lucky and work with a good programmer. That's how you pick it up. But, it's all pedal to the metal. Knuth's entire work is for C. Nowadays, everything is done at a high level using some kind of pre-existing framework and the type of code being written is cookie-cutter so none of…

So you are stating no one on Linux kernel development is a match to Donald Knuth, and given the CVE track record they should improve themselves to Donald Knuth level. If there is anything new about Swift, it is a return to the past of proper programming languages. "Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transforma…

I'm not trying to glorify Knuth or downgrade Linux kernel developers. I'm only saying that you can leanr a lot from a good programmer, and an apprentice type arrangement is probably the best way to learn programming and we need more of that than new languages

Re: The power of Result types in Swift

#76

Post by solidsnack9000 »

lmm wrote: post #60
solidsnack9000 wrote: post #10

It seems like a major legacy of practical experience with FP in the 200x and 201x years is going to be result types.

Every decade mainstream programming culture finally picks up one feature from ML.

Technology is spreading much more quickly than training so it makes sense. ISWIM was written up in the fifties.

Re: The power of Result types in Swift

#77

Post by steve_adams_86 »

dep_b wrote: post #19
ryanpetrich wrote: post #15

Earlier quoted context omitted.

We should also remove airbags and seatbelts in automobiles. Surely then better driving habits would form.

Removing protective padding and helmets might help in American Football. Rugby doesn't use them and it's actually a safer sport. But apart from that: the guy is wrong of course! Working in JavaScript still drives me crazy because I don't have decent autocomplete and no IDE warnings I'm using an API wrong.

It's worth checking out Visual studio code. It is a fairly advanced JavaScript IDE in my experience. Using it with TypeScript is amazing if you're willing to put up with the overhead of compiling to JavaScript (though you can run TypeScript without a compile step in the server using node-ts). These tools make JavaScript a lot nicer for me, and actually pretty enjoyable!
Post reply on HN