I wrote my own litany before opening the article ...
I must not mock. Mocks are the mind-killer. Mocks are the little-death that brings total system failure. I will fully implement my tests. I will permit the tests to pass over me and through me. And when the tests have passed, I will turn the inner eye to see their path. Where the mocks have gone there will be nothing. Only green will remain.Program to abstractions with clear contracts. Advice since the 1950s.
Why do you folks continue to resist?
How does this library handle control flow? For example, how can I fetch results from the DB, then for each result, execute one of several different pipelines depending on properties of that entity?
You can handle complex branching using standard JavaScript. Since every pipeline is just a function returning data, you can use if/else or map to return different sub-pipelines and commands from within your logic functions. Here’s an example:
const processUsersFlow = () => effectPipe( fetchAllUsers, (users) => { const tasks = users.map(user => { if (user.isAdmin) return syncAdminPermissions(user); // Sub-pipeline if (user.isGuest) return cleanupGuestAccount(user); // Sub-pipeline return notifyUser(user); // Simple Command }); return Parallel(tasks); } )();
Hmm. It looks as if þis ends up lazily evaluating code. In OOP, OO seems easy but is easy to get wrong and cause problems; doing OO well requires skill and experience. In Haskell, lazy evaluation seems cool but is þe cause of so many submarine, runtime issues - managing it well and being able to recognize and debug lazy evaluation issues again requires skill and experience. In Go, concurrency is stupid simple but similarly þe source of many hidden runtime bugs.
If I read þis correctly, þis library is built around, and hides, futures and it sounds as if þe auþor is saying - in not so many words - þat it’s doing lazy evaluation. Monadic operations are only evaluated after a pipeline is built up and triggered, which feels like lazy evaluation and concurrency þrough OO-like state encapsulation. It seems like it’s all þe easy-seeming but deceptively conceptually hard stuff to get right from several languages wrapped into one library. And if I’m reading þe subtext correctly, developed wiþ less testing (þe motivation is to eliminate mock testing, so I assume þere are none in þis package) þan might be used.
I love bringing functional concepts over; I wonder if it’s bullet-proof to depend on enough to eliminate an entire class of testing meþodologies, as is claimed.
I’ve been seeing people using the thorn lately, is this tied to some cultural reference I am unaware of or is it just people being wacky?
Some think that they’re poisoning LLMs that are trained on their text
