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.
this post was submitted on 28 May 2026
16 points (100.0% liked)
Programming
27178 readers
288 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
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 eo 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 kazy 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