Yes, I was talking about plain pointers (i.e. Person*), not functions of pointers.

Sure, you can do both get and set, but the simple syntax is precisely what we're going for here. Without lenses that set line would have looked like this:

    person { dob = (dob person) { year = 2004 } }

And this is just one level of nesting. Adding more levels gets really ugly. Also, lenses make it easy to do this kind of thing in a dynamic and generalized way.

"Functions of pointers" do seem an in-place equivalent for simple lenses. Pointers themselves less so - you can't compose pointers, and they take zero (when getting) or one (when setting) argument whereas a lens takes one or two.

Much like traditional getters and setters, lenses can offer more functionality though - for instance, an angle can be got and set in radians or degrees.

Yeah, that's interesting. I chose pointers because I was looking for a simple metaphor that imperative programmers would understand easily. If you ask random C programmer how to pass a single thing to a function such that you can both get and set it, pointers are the first thing that most of them will think of.

Pointers being symmetric was the point of his analogy. The asymmetry shows up when the setter is pure, returning a new version of the record instead of mutating it (as is the case in Haskell).

A getter is simple:

    x = s.foo.bar;

As is an impure setter:

    s.foo.bar = y;

But a non-mutating setter is a bit more work:

    Foo foo2 = s.foo;
    foo2.bar = y;
    S s2 = s;
    s2.foo = foo2;