4 ms·
> Deriving it instead of naming and explaining it will make it harder to understand any code using the derivation because you can’t look up what Promise.all doe
by sfvisser 3y ago
> Deriving it instead of naming and explaining it will make it harder to understand any code using the derivation because you can’t look up what Promise.all does. If the code and explanation is written in terms of Arbitrary instead of Future then the explanation will be difficult to write and difficult to read.
To the contrary! Because I’ve already used that function (traverse) a million times and know exactly how to write it myself I understand exactly what it does without any knowledge about the details of your Future or Optional or whatever. True and meaningful abstraction. Which is truly an amazing super power!
- skybrian 3y agoThat's okay if you're just writing for yourself. But the next person reading your code might never have used traverse and won't get it. Then this becomes a question of what sort of common language we should expect of programmers. That's always going to depend on context. Here are some people trying and mostly failing to explain what 'traverse' does: https://stackoverflow.com/questions/7460809/can-someone-explain-the-traverse-function-in-haskell https://stackoverflow.com/questions/7460809/can-someone-expl...
- themk 3y agoIf you use a language which has monads, then these things quickly become second nature. traverse, sequenceA, etc are all sorely missed when I use rust, as they are quite fundamental in languages which allow the abstraction. It honestly provides so much for free when using a new library.