Let’s just say that if you wanted to understand lenses, this is not where you should start; and if you wanted to move to more advanced scenarios, I wouldn’t start here either.
My biggest piece of advice for people using lenses is to ditch all the operators. Things like ^. or ^.. or ^? or ^@.. or even <<|>~ are all real operators. Yet they look like line noise. Nobody fully remembers them anyways. Just ditch all operators. Use named functions. The function toListOf is immediately clear what it's doing (that it takes a structure and a fold to convert to a list) but ^.. is not.
In general I avoid all custom operators and only use operators that are in packages preinstalled by the compiler (basically just base and containers).
I understand where you are coming from, but in a large number of cases this advice does not really make sense.
Sure, a Haskell programmer does write toList when relevant. The lens library also has operators named each or over or _Left.
But let's say I write <$> and you tell me to use fmap. Is that any better? Not particularly. If you didn't know what Functor is, you wouldn't automatically be able to infer it by reading the name `fmap`.
A large number of Haskell concepts simply have no analogue in everyday English.
I don't understand why Haskell can't provide an imperative interface (at the grammar level, not semantic level) to get/set values in a type. If you can provide the do-notation to "simulate" imperative code, then why not?
Everyone is like "Haskell is such a cool language, it's so much more clear concise and understandable than that stupid language you like so much" (their words, not mine). Then you ask them how they write `foo.bar.baz = 1` and you get 50k words of documentation, 113 new operators[1] like `<<<>~`, and a library with 20 new dependencies. I make fun of them only because I love them - I think Haskell has brought us a lot of cool things like Maybe and Either - but how has no one ever taken a step back and gone "wow, this seems a tad complex for what we're trying to accomplish"?
Because foo.bar.baz = 1 has a side-effect, and side-effects, though powerful, are extremely prone to error. Lenses take more effort, but give us the same amount of power without all the errors. Many people believe the trade-off is worthwhile.
I learned lenses from the mentioned Edward Kmett video but wish I'd learned from the "Optics by Example" book instead; it's more cohesive, comprehensive and can save you a bunch of time - https://leanpub.com/optics-by-example/
If you're in the Clojure world and feel an appetite for something like Optics, checkout the Specter library from RedPlanetLabs/Nathan Marz; it's Optics by another name, but functionally/philosophically quite similar.
12 comments
[ 4.4 ms ] story [ 35.9 ms ] threadIn general I avoid all custom operators and only use operators that are in packages preinstalled by the compiler (basically just base and containers).
Sure, a Haskell programmer does write toList when relevant. The lens library also has operators named each or over or _Left.
But let's say I write <$> and you tell me to use fmap. Is that any better? Not particularly. If you didn't know what Functor is, you wouldn't automatically be able to infer it by reading the name `fmap`.
A large number of Haskell concepts simply have no analogue in everyday English.
I find it to be a lot more comprehensible and transparent than the Haskell version.
https://www.stackage.org/haddock/lts-23.27/base-4.19.2.0/Dat...
https://hackage-content.haskell.org/package/bluefin-0.0.16.0...
[1]: I'm not even exaggerating - https://hackage-content.haskell.org/package/lens-5.3.5/docs/...
https://github.com/redplanetlabs/specter