> Writing abstracted enough code often requires inventing new languages to hide the complexity behind abstractions.

Human attention may pick out symbols more easily, but human comprehension benefits from things that actually have meaning. Otherwise you end up with a soup of ASCII symbols that very few can parse since every library in Haskell seems hellbent on inventing new and useless ascii combinations for function names and operators.

Even the article goes (emphasis mine):

--- start quote ---

The basic operators here are ^., .~, and %~. If you’re not a fan of funny-looking operators, Control.Lens provides more helpfully-named functions called view, set, and over (a.k.a. mapping)

--- end quote ---

And then proceeds to use the ASCII soup instead of the more helpful function names.

It doesn't help in the least that there are multiple get operations ^. ^? ^.. Or this idiocy: "Here, a single < before the operator signifies that it returns the updated value, while a double << signifies that it returns the old value. This gets a little weird with the monoidal operator; <<>~ returns the updated value, not the old one". Bonus points. What does this do: <<<>~

Because "why have useful names when you can pretend your fake intellectual superiority by using confusing ascii symbol combinations"

> Software development in Haskell is particularly focused on DSLs, lens language being one of them.

The domain specific language for lenses is view, set, traverse, update etc. Not whatever this is.

Yes and you tend to use ^. in Haskell where you'd use . in python, say. And . is also an operator. Similarly, you'd likely be using = in python where you'd use .~ in python. As for ^.., I'm not sure there's an idiomatic python equivalent - certainly nothing as simple as adding an extra . to the operator.

> Human attention spans on symbols, the more succinct the code is, the more meaning it can encompass in the same number of characters.

I could make it even more succinct by LZW compressing it. That would not improve comprehension, though...

I agree that FP languages sometimes exaggerate with the opeators (I think introducing new operators has its uses but the learning curve has to be traded off against the supposed benefits), but...

Perl is IMHO worse because it relies much more on global mutable context. For example, the diamond operator <> behaves differently depending on whether the magic global variable @ARGV is set.

By contrast, Haskell is typed and purely expression based, so that at least in principle you can pull apart expressions, examine them (and test them!) individually and then understand how they combine.

Lens is not an introductory topic in any Haskell tutorial I know.

And Perl is not line noise. It's a very nice language.

I take your point, but this is not a language design problem -- it's a library design problem. These are just function names.