4 ms·

> Again, it's pseudo-code, so no, it need not be a "generic 2-tuple", not even needs to be a "tuple" (whatever that means in a given PL). In a real implementati

> Again, it's pseudo-code, so no, it need not be a "generic 2-tuple", not even needs to be a "tuple" (whatever that means in a given PL). In a real implementation the types are known precisely (Just like the types of the alternatives in an ADT are known precisely). There is no kind of "matching" whatsoever. s1 and s2 are simply two variables (for example pointers, in C) of precisely known type. It's the simplest kind of code. That's not different syntactically or even mechanically from pattern matching over a generic 2-tuple. So if you want to do this as a social convention, that's fine. I'm not sure why other people would adhere to such a convention. > The whole point of the discussion was whether to design the output as a single stream of ADT values, or as multiple streams of precisely known values. No. The whole point of the talk we're discussing is that a single stream of chained operations that have failure states is difficult to cleanly assemble without ADTs. You've backed away from the error contingency in your argument. To the uncharitable onlooker, this appears to be because ADTs solve the problem elegantly and procedural programming turns into am error prone, one-off pile of if-then-else spaghetti. See also: every complaint about Golang error handling. Ignoring the Success-or-Failure nature of the talk is to fundamentally ignore the problem it's trying to solve. If you DID have two streams of values that had no contingency, we wouldn't write code this way in any runtime with async primitives. > Sorry to call you "dude". I had already decided to remove that word before reading your answer. Thank you.

jstimpfle 8y ago
> The whole point of the talk we're discussing is that a single stream of chained operations that have failure states is difficult to cleanly assemble without ADTs And I suggested that this is overly complicated and procedural approaches are better. In procedural code we don't "assemble chained operations". We do them one-by-one and handle errors appropriately. And we can typically arrange the data and control so that error handling is much easier. That was my point. > one-off pile of if-then-else spaghetti. ADTs and FP techniques provide only syntactic sugar to avoid this spaghetti in the source code. But due to that they just encourage having the worst mess of control actually happen on the machine. On the other hand, I demonstrated how to avoid this mess by decomposing data into individually homogeneous bins/streams/arrays/whatever. My example does not have a single if statement (yes, you might argue there are if statements hidden in the for loops). I clearly stated that it's often possible to choose this approach.
- KirinDave 8y ago
  > And I suggested that this is overly complicated and procedural approaches are better. In procedural code we don't "assemble chained operations". We do them one-by-one and handle errors appropriately. Go does this. It's widely and I think rightly criticized for this. It's "easy" to do but not "simple" because it's prone to human error. > And we can typically arrange the data and control so that error handling is much easier. That was my point. You can do more work to validate in a separate pass if we're discussing data transforms. It's harder to do this for a series of chained imperative steps. The talk details an example making a series of API queries. It's fantastic to handle a CRUD loop with the ADT method because it lets you write a simple specification and collect errors out in the end, while reserving exception handlers for truly exceptional cases like network faults. F# is incredibly good at this kind of flow. > ADTs and FP techniques provide only syntactic sugar to avoid this spaghetti in the source code. But due to that they just encourage having the worst mess of control actually happen on the machine. You've said this multiple times, but it's just not true. The F# code is just a function that calls functions. F#, ML and Haskell compilers all aggressively inline these calls. You pay the exact same costs for validating an error exists in the Golang style, in practice. Indeed, lots of people generate Go from liskov-style templates JUST to get ADTs to make error handling less painful. It's gaining popularity in Swift and Rust as well. Folks there aren't trying to impress people with their FP knowledge, they're cribbing a technique that works and scales well. > My example does not have a single if statement (yes, you might argue there are if statements hidden in the for loops). I clearly stated that it's often possible to choose this approach. Your example, by your own admission, doesn't address error handling flows. You need conditional logic to work with operations that don't always succeed. You say, "Structure it so you never have them." I think a lot of FP people would agree with this (in fact, there is a really cool functional pearl about doing exactly this at scale: https://github.com/matt-noonan/gdp-paper/releases/download/june-2018-draft/gdp.pdf https://github.com/matt-noonan/gdp-paper/releases/download/j...) but they'd think about it less as a function of assurances and "thinking very hard" and more about using methods to make inconsistent code provably false at compile time. Very few languages can actually encode formal notions of correctness, right now. Recently languages like Idris, Agda, Coq, and TLA come up as tools for formal correctness, where you can actually have your compiler prove your invariants and their implications.

jstimpfle 8y ago

> The whole point of the talk we're discussing is that a single stream of chained operations that have failure states is difficult to cleanly assemble without ADTs And I suggested that this is overly complicated and procedural approaches are better. In procedural code we don't "assemble chained operations". We do them one-by-one and handle errors appropriately. And we can typically arrange the data and control so that error handling is much easier. That was my point. > one-off pile of if-then-else spaghetti. ADTs and FP techniques provide only syntactic sugar to avoid this spaghetti in the source code. But due to that they just encourage having the worst mess of control actually happen on the machine. On the other hand, I demonstrated how to avoid this mess by decomposing data into individually homogeneous bins/streams/arrays/whatever. My example does not have a single if statement (yes, you might argue there are if statements hidden in the for loops). I clearly stated that it's often possible to choose this approach.

KirinDave 8y ago
> And I suggested that this is overly complicated and procedural approaches are better. In procedural code we don't "assemble chained operations". We do them one-by-one and handle errors appropriately. Go does this. It's widely and I think rightly criticized for this. It's "easy" to do but not "simple" because it's prone to human error. > And we can typically arrange the data and control so that error handling is much easier. That was my point. You can do more work to validate in a separate pass if we're discussing data transforms. It's harder to do this for a series of chained imperative steps. The talk details an example making a series of API queries. It's fantastic to handle a CRUD loop with the ADT method because it lets you write a simple specification and collect errors out in the end, while reserving exception handlers for truly exceptional cases like network faults. F# is incredibly good at this kind of flow. > ADTs and FP techniques provide only syntactic sugar to avoid this spaghetti in the source code. But due to that they just encourage having the worst mess of control actually happen on the machine. You've said this multiple times, but it's just not true. The F# code is just a function that calls functions. F#, ML and Haskell compilers all aggressively inline these calls. You pay the exact same costs for validating an error exists in the Golang style, in practice. Indeed, lots of people generate Go from liskov-style templates JUST to get ADTs to make error handling less painful. It's gaining popularity in Swift and Rust as well. Folks there aren't trying to impress people with their FP knowledge, they're cribbing a technique that works and scales well. > My example does not have a single if statement (yes, you might argue there are if statements hidden in the for loops). I clearly stated that it's often possible to choose this approach. Your example, by your own admission, doesn't address error handling flows. You need conditional logic to work with operations that don't always succeed. You say, "Structure it so you never have them." I think a lot of FP people would agree with this (in fact, there is a really cool functional pearl about doing exactly this at scale: https://github.com/matt-noonan/gdp-paper/releases/download/june-2018-draft/gdp.pdf https://github.com/matt-noonan/gdp-paper/releases/download/j...) but they'd think about it less as a function of assurances and "thinking very hard" and more about using methods to make inconsistent code provably false at compile time. Very few languages can actually encode formal notions of correctness, right now. Recently languages like Idris, Agda, Coq, and TLA come up as tools for formal correctness, where you can actually have your compiler prove your invariants and their implications.