I think you're assuming I'm less experienced than I actually am! > If this genuinely relates to your example above then the only possible consistent ordering w

I think you're assuming I'm less experienced than I actually am! > 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).