> For your C++ example, I have to know the type of v and i (and that in C++, it's possible to overload operators). For your example, I have to know what an "optic" is, what a "Getter" is, what Haskell thinks a "subfield" is (and that means that 'x' can't be any type, but has to be the kind of type that contains a subfield), and I suspect several other background things that I don't even know what they are.
I still think this appeal to familiarity is dangerous. You take your knowledge about C++ as obvious and standard, and disparage knowledge about Haskell as a bowlful of jargon. But no-one comes into the world finding C++ intuitive, either; it has to be taught. And teaching C++ without referring to operator overloading, or with other attempts to obscure the way its practitioners actually talk about and practice it, can only be supported so far. Similarly here—I suspect more of the people who code with lenses in Haskell use the symbolic operators than the 'word' operators. Though I have no data to back that up, obviously it's how the writer of this tutorial thinks about them. So why shouldn't they use the format that makes sense to them, and that they hope to teach people to use?
I still think this appeal to familiarity is dangerous. You take your knowledge about C++ as obvious and standard, and disparage knowledge about Haskell as a bowlful of jargon. But no-one comes into the world finding C++ intuitive, either; it has to be taught. And teaching C++ without referring to operator overloading, or with other attempts to obscure the way its practitioners actually talk about and practice it, can only be supported so far. Similarly here—I suspect more of the people who code with lenses in Haskell use the symbolic operators than the 'word' operators. Though I have no data to back that up, obviously it's how the writer of this tutorial thinks about them. So why shouldn't they use the format that makes sense to them, and that they hope to teach people to use?