1. 21
    1. 4

      Backward composition of lenses. It’s a minor issue, and I wouldn’t mention it if it wasn’t a great demonstration of how lens goes against the conventions of Haskell.

      Counter: Lenses don’t compose backwards. They just compose.

      1. 2

        Well - the more important point here is that the reason they’re written such that composition, uh… does what it does… is that a lot of people just flat-out refuse to use them unless they syntactically resemble the C struct-member operator.

    2. 4

      To quote one of the things I said the other day:

      Want to write code in a direct, imperative/mutation-y style for changing a value or two in a nested structure without having to explicitly rebuild the rest of my data structures? lens.

      Want to ignore the other possibilities of a sum type (~union) and collapse everything I didn’t handle into a single case in a composable manner that can handle nested sum types? prisms in lens.

      That’s not everything lens has or can do either.

      lens is no more unidiomatic than fmap. I could probably find somebody complaining about fmap during the Haskell 1.3 days if I looked hard enough.

      It doesn’t have to be lens specifically either, if you find the operator-itis offensive. lens-family-core and lens-family have the more common stuff and are inter-compatible. I use lens in part because I find myself wanting/needing stuff like prisms and Control.Lens.Fold on the reg.

    3. 2

      The idea of idiomatic code only leads to mediocrity.

      1. 7

        Well, it also leads to learnability. Choosing idiomatic code over otherwise-better code makes it worse in an absolute sense, but lets developers who are new to the project but experienced with the idioms start contributing more quickly. Depending on how often onboarding happens at your organization, the trade-off may be worth it.