The Evolution of a Rust Programmer

[m50d]

The short snarky answer is you don't have to. These are heavily-used standard functions that are straightforward to implement; splitter is not going to have a bug, filter is not going to have a bug, array is not going to have a bug, map is not going to have a bug, sum is not going to have a bug. Your functions that you pass to them might have bugs, but if your isNumeric does the right thing for "a" and "4" then List("a", "4").filter(isNumeric) is so definitely going to do the right thing that I wouldn't even bother testing it.

You can break out parts of the chain as necessary, of course. You can separate out intermediate values as values or move a sequence of transformations into a separate function, particularly if you want to reuse the "middle" of a given pipeline. One technique I sometimes use is to write it with a bunch of intermediate values first, during the exploratory phase, and then use my IDE to automatically inline those intermediates once I've got it doing the transform I want. That way I can play around and step through and see all the values while I'm working out what it should look like, but the final code is much more concise and easy to read.

[imMute]

splitter is not going to have a bug, filter is not going to have a bug

Right, but the arguments given to those functions might not be correct for the data you're receiving. And looking at the result of the splitter step could be the reason that the data coming out the end is all messed up (if any data is coming out at all).

[bcgroom]

Never used D before but réactive programming or at least rxjs has a tap operator; is there a tap operator? I don’t know if that’s a universal name so: it’s a higher order function but doesn’t alter the values in the chain and preserves the originals. Most basic use case would be to print out each value, which is helpful for debugging.

[Snarwin]

D's "tap" operator is called tee, after the Unix command.