3 ms·

Not to be a lens hater, but I would definitely flag it in PR review if someone came up with that instead of something like this: > sum $ map (fromMaybe 0)

by WJW 4y ago

Not to be a lens hater, but I would definitely flag it in PR review if someone came up with that instead of something like this: > sum $ map (fromMaybe 0) <some list of Maybe Int> Possibly with a different default value for Nothings. A lot of the optics libraries seem to focus a lot on making the general case as easy as possible while overcomplicating the specific case. `sumOf (folded . folded)` does have some advantages in working for lists of other types but I question how often you would reuse such a function for different types the first place. It just doesn't come up all too often in my own code, perhaps it is different elsewhere.

ParetoOptimal 4y ago
> `sumOf (folded . folded)` does have some advantages in working for lists of other types but I question how often you would reuse such a function for different types the first place. The common refactor here would be to Either: > sumOf (folded . folded) [Right 1, Right 2] 3 I don't like the "unwrap the Maybe" or "get rid of the pesky monad in my way" intuition that fromMaybe and catMaybes give beginners. > A lot of the optics libraries seem to focus a lot on making the general case as easy as possible while overcomplicating the specific case. I kind of agree with this, but contend the universality of a single powerful and composable lens syntax simplifies things more overall even if it makes a single use site more complicated.
ParetoOptimal 4y ago
> `sumOf (folded . folded)` does have some advantages in working for lists of other types but I question how often you would reuse such a function for different types the first place. Just remembered another refactor that comes up a lot for me: Refactoring `[a]` to `NonEmpty a`. A lot of times this tightens your code up, but i find if the call chain is monomorphic to list most won't bother with the refactor. So I like lens for pushing away from that level of monomorphism that is resistant to better architecture.

by WJW 4y ago

ParetoOptimal 4y ago

> `sumOf (folded . folded)` does have some advantages in working for lists of other types but I question how often you would reuse such a function for different types the first place. The common refactor here would be to Either: > sumOf (folded . folded) [Right 1, Right 2] 3 I don't like the "unwrap the Maybe" or "get rid of the pesky monad in my way" intuition that fromMaybe and catMaybes give beginners. > A lot of the optics libraries seem to focus a lot on making the general case as easy as possible while overcomplicating the specific case. I kind of agree with this, but contend the universality of a single powerful and composable lens syntax simplifies things more overall even if it makes a single use site more complicated.

ParetoOptimal 4y ago

> `sumOf (folded . folded)` does have some advantages in working for lists of other types but I question how often you would reuse such a function for different types the first place. Just remembered another refactor that comes up a lot for me: Refactoring `[a]` to `NonEmpty a`. A lot of times this tightens your code up, but i find if the call chain is monomorphic to list most won't bother with the refactor. So I like lens for pushing away from that level of monomorphism that is resistant to better architecture.