The grandparents post's first argument about semantic reading was much more important than the speed reading bit.
What you'll find if you look at Hoon is about 100 combinator runes, which are digraphs like "%=" ("centis") or "|-" ("barhep"). (There is of course a power-law usage distribution -- a few common runes dominate.)
If we had to invent and remember semantic names for each of these runes, that binding would really be a lot of work to remember. We could say "mutate" instead of "centis" and "loop" instead of "barhep". Remembering these bindings would be quite a lot of work.
Of course, we could use reserved words directly; you can experiment with translating Hoon into reserved words. (The earliest experiments used keywords with a sigil, like ":loop".) To my eye the keywords look hideously verbose and are easily confused with symbols.
You also lose the ability to classify, say, "|=" and "|-", as closely related runes. This is especially useful with unusual, rarely used runes; what is "|/"? You might not know, but you know that it starts with "|", so it makes a core.
So is remembering what all the runes do; if the names and the functions relate, they're both easier to remember.
To get to reasonably precise, meaningful keyword bindings for this set of combinators in particular, perhaps you'd be replacing ":-", ":_", ":+", ":^", ":*", and ":~" with ":pair", ":reverse-pair", ":triple", ":quadruple", ":tuple", and ":list" respectively. This is a pretty benign and easy case, and you may have to trust me on what kind of hash this search-replace alone would turn a Hoon file into. Then again, I suppose it all looks like hash to you.
Language design is hard; you can't please everyone. Probably the best-case scenario is that you please some people, and the rest are dragged kicking and screaming. And that's a best case.
I just don't think it makes sense to invent fanciful names for them based entirely on their symbology, rather than their function.
It's your language; you can call things whatever you want. But I've seen many languages that I would like to succeed fail or grow very slowly because they failed to engage well with prospective users. And when you already have a nearly-asymptotic learning curve, why add more to it?
As I always say, there's a difference between real and apparent learning curves. I don't think your perception of the apparent learning curve is wrong. But some things are easier than they look; one of those things is remembering associations. I've seen a good number of people walk the real learning curve for this language, and it's not that steep. Hopefully reality also gets a vote.
I'm almost convinced it's a bad idea, but not entirely. It gives me the feeling of conflating conciseness and simplicity - taking something that is (overly) complex and attempting to make it simple by making the representation more compact.
On the other hand, different (from the norm) can be a good thing in itself. Still haven't gotten around to play much with it. I strongly suspect that, if we consider this the first incarnation of what will be the future of this system, the third or fourth re-iteration might be getting to the core. (If you can't explain something simply, you don't yet understand it etc).
Haskell people invent and a lot of new and strange things. Renaming punctuation is not one of them.
I guess it doesn't matter as long as you never use your new names in writing. (And why would you, you can use use the symbols themselves.) But then, of course, why bother with these names at all apart from creating an oral tradition.
I can't fault Haskellers for their daring in pushing the limits of programming languages as a UI. For instance, the idea of custom, library-specific "line noise" terrifies me. Hoon has no macros, no custom syntax, no operator overloading, etc. Once you've learned the line noise you've learned it.
The lens library in particular is a DSL by anyone's definition. Arguably (well, I'd argue it anyway), the ease of constructing DSLs is a trap that's impeded adoption of both major families of FP, Lisp and Haskell/ML. Plenty of people have made the "DSL == write-only" argument, so hopefully it's sufficient to just reference it.
Lens is in a sense the quintessential expression of Haskell; I don't know how anyone grounded in reality could expect the average Java programmer to learn and master it. And yet, everything it's doing is beautiful and true and right. Basically, resolving this contradiction strikes me as the essential problem of functional programming, if not just programming, in the next decade. I personally am very far from being the most qualified person to solve this problem. But I feel not enough people are working on it.
That's one of many reasons I wouldn't want to switch even if it was more efficient, for much the same reason that I have no plans to learn Esperanto or switch to Colemak. That's also precisely why I suggested it was much like requiring a custom keyboard.
I can say "x mod equal y" to almost anyone technical, and they'll immediately understand it as "x %= y". One syllable for understandability. And considering how rarely I actually speak exact syntax aloud, that seems well worth it. (It occurs to me that someone designing and using a new programming language seems far more likely than average to have to communicate syntax verbally.)
I like the Haskell approach to operators as just a funky syntax for functions. No need to bake any operators as keywords into your language. +, =, etc are all just part of the standard library. (I also like the Lisp stance of mostly just not caring about line-noise symbols vs letters.)