The entire discussion is about railway programming for early exit on error handling. So yeah, there are dependencies there.
> You're purposefully twisting words here.
No. I'm pointing out you pattern matched against a generic 2-tuple in your pseudocode. There's no words to twist, returns in functions on modern hardware are atomic over 1 value in all but the most obscure languages, and it's not a new phenomenon.
If it's valid to say, "I returned 2 values" it's equally valid to say, "I returned one value and restructured it." They represent the same thing.
> And no, that's not "the type", because I was (obviously) just using straight forward pseudocode whose semantics I assumed would be intuitively clear to everyone.
Both statements can be true. I'm simply writing a type that captures your "obviously true" statements. Therefore, both are obviously true.
> There is so much hair-pulling in here and what you say is simply wrong. I was just returning two friggin' variables.
You're the one consistently lambasting folks about paying attention to what happens at the "bare metal" (ha!) level. I encourage you to take your own medicine here.
> Why do you make it seem like it was something more complicated? You must be deliberately hair-pulling just to win a stupid argument. I'm not doing any "virtual object-oriented blah blah" or any kind of types craziness.
Either you wrote something so vague it can be anything you want (e.g., your magical streams that are also not streams). If we remove the nonsensical (or I guess by your admission, non-sequitur) streams bit then you're left with this outcome. I told you exactly what I'd do in my post. You have to recognize the type of the result of each step as either a success or an error.
You've chosen to pretend none of this is about error handling, which is pretty boring IMO. Error handling is what makes code actually hard to write.
> What's wrong with my procedural code? Fill in the error handling between the steps as soon as you have a concrete instance for my abstract example.
I admit I don't know since it seems to mean exactly what you want it to, and no one else is privy to either the viewpoint nor the problem you're actually discussing. You're just here hurling vague insults about how everything other than your "obvious" pseudocode is nonsense.
> Dude, I used a pseudo-code for loop.
Not in any example I reviewed that didn't completely ignore the actual problem to burn down a straw man about streaming constructs. Also, don't call me dude. I'm not.
> I've been there and I know to use FP-ish constructs when they make sense (very rarely. Much easier to restrict to procedural altogether).
Considering you didn't recognize the product pattern match and objected vigorously to the idea that it might be as such; and tuples something nearly every statically typed FP dialect has? I gotta confess that I don't think you know the field or the techniques very well. Fair enough, many modern FP techniques in use today are less than 25 years old. No shame there. But you should probably investigate a bit more before speaking so confidently on the subject.
You really are just advocating for doing what the F# example given was doing, without all that helpful syntax or compile-time verification of correctness & totality. I dunno why you'd want that. Given that you are accidentally reusing FP pattern matches, they can't be that complicated now can they?
"Early" does not have anything to do with "dependency". You can do a million unrelated things in an order of your choice and abort at the first error. There need not be any dependencies.
> returns in functions on modern hardware are atomic over 1 value in all but the most obscure languages, and it's not a new phenomenon.
This is true and totally unrelated to my point.
> No. I'm pointing out you pattern matched against a generic 2-tuple in your pseudocode.
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" (there are no conditionals) whatsoever. s1 and s2 are simply two variables (for example pointers, in C) of precisely known type. And the process_data() function returns two values that get assigned to the variables. It's the simplest kind of code.
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. In this context it's totally clear why my (single) assignment to s1 and s2 is not the "matching" that you need to do on the (many) values of the single stream in the ADT version. Really I don't care how hard you want this assignment to s1 and s2 to be a matching/destructuring of a "tuple"; It doesn't change anything and is totally unrelated to my point.
Sorry to call you "dude". I had already decided to remove that word before reading your answer.
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.
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.
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/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.
> If this genuinely relates to your example above then the only possible consistent ordering without any async/multithreading is to exhaust stream1, then process your errors. [...]
Unless we know there are dependencies between the processing of s1 and s2 (and we don't; we're talking very abstract here) I'm totally unconcerned about the processing order, and I even stated explicitly that in the simplest case they're just append-only arrays. And the processing of the items in s1 and s2 can be done in any order, but why not just do it in a single thread, first process "data" completely, then "s1", then "s2". In many cases of course, it will be possible to run in 3 parallel threads, where the additional two process s1 and s2 as they are emitted from the first thread. But that's just a small optimization and a lot of complexity and not relevant here.
> Your process data is pattern matched on a generic product there. Sorry to disappoint. The actual type of the value is:
You're purposefully twisting words here. And no, that's not "the type", because I was (obviously) just using straight forward pseudocode whose semantics I assumed would be intuitively clear to everyone. That's not the kind of pattern matching we'd been talking about. In my code s1 and s2 are simply two known variables holding the streams. That's something different than a single variable holding either of two distinct cases. I assume you know that and just want to sell the FP cool-aid or troll me; please refrain from this style of discussion.
> This is sort of why folks who know about ADTs roll their eyes at the sizzling invective about their complexity. You often end up using the same solutions, you just don't name them. It seems like the naming itself is objectionable. You've written about 4 posts I can see here about how much you hate ADTs, but then you're happy for an implicit `Either Null a` on every value, no opting out, and `a,b = f(x)` is fine because the name of the ADT is a punctuation mark, I guess?
There is so much hair-pulling in here and what you say is simply wrong. I was just returning two friggin' variables. And why are you talking about "Null"? That's of no interest. There is no use in my pseudocode for any kind of thing resembling what's called "Null" in any programming language. As a Haskell enthusiast you should know that there is always a canonical stream/array, and that's the empty one. Why are you haunting me with Nulls, that's not fair, I don't want them, and I can do without them. (And just to be clear, I don't do OOP either; I think it's at least as bad as FP)
> What's completely confusing to me about your claim here is that you're doing dynamic dispatches and perhaps excess function calls,
No I'm frigging not. I don't get it why you're talking of dynamic dispatches now. What I have given is some pseudo code of the simplest kind, that easily translates to any procedural programming language, including assembly code. Why do you make it seem like it was something more complicated? You must be deliberately hair-pulling just to win a stupid argument. I'm not doing any "virtual object-oriented blah blah" or any kind of types craziness.
s1 is a stream (or let's just say (again), an "array", to hopefully prevent any misunderstandings) of homogeneous things. Let's just say all items in s1 have type S1 and all items of s2 have type S2. It's the simplest kind of problem.
> -- Assuming the steps are: [..]
Congrats. I learned Haskell once, too. Until at some point it became clear that it didn't bring anything practical to the table and only complicates program designs. This "uniform error handling" idea (actually it seems to be more of a necessity/accident) just makes for bad code. Don't do that. Just do the first processing step, handle errors accordingly. Then do the second step, and handle errors accordingly. The second step in general requires different error handling than the first, (and often the only thing they have in common is that they might "die"), and there is no need and only disadvantages in restricting them to have uniform error handling.
What's wrong with my procedural pseudo code? Fill in the required error handling between the steps as soon as you have a concrete instance for my abstract example.
> dynamic dispatches
Nope
> excess function calls
What's that?
> demanding your process functions do null checks
No, I don't have any "Nulls" of any kind, since my data is simple and normalized.
> no clear looping construct
I used a pseudo-code for loop. Every 1-month beginner to programming has an immediate grasp of that. I never heard anyone complain that was somehow not "clear". It's plain, procedural code. You're trolling me so hard it hurts.
> I actually think you like lots of elements of the FP style, you just seem to dislike the names. Perhaps if you could hold your nose with a clothespin and play through the stink of math-ish names, you might find more you like?
I've been there and I know to use FP-ish constructs when they make sense (very rarely. Much easier to restrict to procedural altogether).