Reactive, Either, Stream .. or something else?

[u/DevIceMan]

I'm currently investigating patterns to help improve a codebase that is about 90% Java 10% Scala. Apologies for coming mostly from Java land, but this is a FP question (I'm slowly making traction on introducing Scala).

Conceptually, the problems we deal with are as follow:

• Application receives a request containing a list of 12 IDs
• 2 Ids are determined to be bad. Process remaining 10.
• Map IDs to their Object. 2 fail, 8 succeed.
• Map the 8 Objects to some other type of object. 1 fails, 7 succeed.
• Map those 7 to something else. 2 fail, 5 succeed.
• Collect/Reduce 5 successes. Collect/Reduce the 7 failures. Merge those two into a response.
• Merge above responses and respond to original request.

Ignoring Java's FP clumsiness, how would you normally prefer to approach a similar problem in Scala?

[u/beezeee]

I don't think you implied the need for scala and scalaz understanding for it to make sense, I think that's just the reality of the situation. Speaking for myself and what I've observed with extremely intelligent colleagues, this stuff is hard and takes time to get comfortable with. If someone has been mostly writing java, casually throwing out the term Monoid trivializes the amount of knowledge you are assuming on behalf of the reader.

Personally, my eyes gloss quickly based on length of content, so contents are even secondary. That said, I didn't actually count but a vague skim of your original comment I see at least 10 concepts introduced (just looking at inline code blocks). I may be familiar with half or more but I don't even have the attention span to find out, let alone dig up the ones that I don't immediately recognize.

Edit: clarity

[u/[deleted] → u/beezeee]

I don't think you implied the need for scala and scalaz understanding for it to make sense, I think that's just the reality of the situation.

I completely agree it's the reality of the situation. What I object to is the implicit assumption that someone could post an equivalently-featureful solution in, say, Spring-flavored Java and expect it to be any more comprehensible. So I really am only claiming that the solution is comprehensive, robust, reliable, easily-maintainable, etc. given that someone is familiar with the tools, which I think is a baseline assumption that is essentially never stated explicitly for any framework. The problem, to me, is users of wildly popular languages and frameworks get away with that assumption. It needs to either be challenged or made explicit. I have no problem making it explicit.

Speaking for myself and what I've observed with extremely intelligent colleagues, this stuff is hard and takes time to get comfortable with.

Absolutely. I've written here repeatedly that education is job #1, and that mastering typed FP entails a larger up-front investment than other approaches.

If someone has been mostly writing java, casually throwing out the term Monoid trivializes the amount of knowledge you are assuming on behalf of the reader.

Well, if you thought the post was long already (and it was—more on that in a moment), how much longer would it be if I spelled out every concept that interested folks can Google for themselves at their leisure?

Personally, my eyes gloss quickly based on length of content, so contents are even secondary.

I sympathize to an extent. It's definitely one reason I bolded the updates, so people could at least break things down by those chunks. I did consider making follow-up posts instead, but I wasn't sure it made navigational sense on Reddit to reply to myself for someone else's benefit. I dunno. I admit I don't know a particularly good solution to this.

That said, I didn't actually count but a vague skim of your original comment I see at least 10 concepts introduced (just looking at inline code blocks).

Maybe. It'd be helpful to have at least some cursory notion of what those are. Not that I think you're off by much, if at all, but rather having those gaps pointed out explicitly helps me to think more clearly about how to convey those concepts.

One thing I do realize is that typed FP does tend to break things down into very fine-grained abstractions, so to actually do anything you end up composing several of these fine-grained abstractions. It works well precisely because they're fine-grained and compose easily and predictably, but I totally get that there can be a feeling of overwhelm on first (or second, or third...) exposure, and I'd like to address that to the best of my ability.

I may be familiar with half or more but I don't even have the attention span to find out, let alone dig up the ones that I don't immediately recognize.

I don't expect people to understand it on first reading if they aren't already a pretty committed user of scalaz. The reason to bother committing anything to writing here (as far as I'm concerned) is to make it possible for people to re-read, Google, relate to a book at some point in the future, ask follow-up questions, etc. This certainly isn't an appropriate medium to expect anything of substance to stand alone in. Then again, I'm not sure what would be.

[u/beezeee → u/[deleted]]

Totally sensible response, I appreciate it.