> What's really neat about lenses to me (more of a practitioner than a theoretician) is that while the level 0 explanation of them is "they're like getters and setters in your OOP language" they extend the concept much further.
This doesn’t tell me anything since getters/setters are almost useless in my experience.
Right ... And lenses are not. Imho a better comparison would be to (safe) pointers that can point to multiple, conditional positions in a data structure.
Example: in a game you want to update the health points of all enemies that are affected by an area of effect attack. With lenses you would compose a lens from multiple simpler lenses:
```enemiesAtDistanceToPoint (10,20) 5 . health -= 5```
The benefit here is that you abstract the work of extracting the enemies and can reuse it elsewhere. Also note the lack of any loop to affect multiple entities.
Somewhat, but even my pointer analogy just scratches the surface.
Filtering/selecting is big, but another interesting thing is that there are lenses (which I think are called prisms?) that only provide a view of something.
Eg you have a text document in Unicode, select all words marching a certain pattern, and then look as if they were encoded in ASCII. (No idea why this would useful :-) ).
A "lens" that only provides a view of something is just a plain function. Prisms are first class constructors: a `Prism a b` can build a `b` from an `a`, or attempt to match on a `b` and `Maybe` get an `a` that could construct it.
The OP means accessing instance variables really. That is, the `.x` in `this.x` or `that.x`. They're not making a distinction between manually created getters and setters and what the compiler generates.
This doesn’t tell me anything since getters/setters are almost useless in my experience.