This is not about "already know". This is about "in how many ways you can plausibly parse the chunk of text you are looking at". Haskell and Forth come to mind as the worst languages when it comes to humans being able to parse them. The language in OP is, well, a close relative of Haskell. It's awful to read and work with in general because human readers cannot parse the structure of the program easily.
Another aspect / problem: humans vocalize (well, adults, usually, using their "inner voice") anything they read. This is why, for example, people deaf from birth struggle more with reading comprehension. So, when programmers read programs they use some made up language to read it out loud to themselves. When a language is just a string of punctuation / non-typographical symbols it's a struggle for any human to read it to themselves in any way that they could process it.
Try it yourself:
Pipe underscore increment dollar pie colon colon hash open paren...
Probably, with some experience, it will be more like
Pipe unimportant list-add variable pie namespace hashtable with arithmetic expression?
In other words, this is not a language anyone would use in a setting where they just need a computer to write useful programs. This is a crypto-arithmetic puzzle for people with too much time on their hands.
Given that a few people can master high-level math that is impenetrable to most, and programming itself is impenetrable to some people, it might be that some languages require minimal cognitive level to get into. That is, easy for some, challenging yet possible for others, and unlikely at all for others. But sometimes it sounds like struggling to learn something only takes place in school, and once we're out of high school it's just easy things thereafter.
The question of "useful" is good. Useful for what? There are lots of different needs and purposes in the world.
I wouldn't bring math into this. Math is genuinely hard for everyone. Some people just have enormous amounts of dedication and sheer xxx will. The hardships extend far beyond learning the language.
For myself, I rarely read out Haskell code ‘literally’ (to the extent that I read any code literally at all; I’m not sure I have much of an internal monologue). Instead I tend to perceive it at a higher level: say, ‘modify a state variable s to fromMaybe s (f s)’ for ‘modify $ \s -> fromMaybe s (f s)’. Reading it out character-by-character would be as pointless as reading an ordinary word that way, like reading ‘cee-aye-tee’ instead of ‘cat’.
I forgot the name of the reseacher, it was one of Chomsky's students who also researched how people (learn to) understand music. He also researched the subject of reading comprehension in people who lost hearing at different stages of their lives.
His research convinced me that any tool that wants to parse any spoken language absolutely has to incorporate vocalization information. Also, it convinced me that while it's possible that some people (esp. deaf from birth) can learn alternative ways of reading that don't involve vocalization, these are unnatural for humans, hard to learn and have poorer yield.
So, yeah, maybe some people don't read their code out loud to themselves, but most do, and for most of those who do this makes things easier. So, even if there's a way around it, it's not worth considering when we are talking about ease. People who don't do it are "playing with a handicap", they aren't in the competition for the easiest way to do things.
Also, I'm not convinced that having an internal monologue is the same as reading text using inner voice. Most people learn to read by first reading out loud, and only later learning to use inner voice. Only few people continue on to learn advanced reading techniques which allow to skip selectively and to perform some other mental manipulations on the text, but these techniques also often involve some internal vocalization, but it wouldn't produce the equivalent of speech. More like how people who have to control their computer with voice commands learn all kinds of shortcuts / ways to invoke functionality hard to describe using regular speech elements with clicking noises, whistles etc.
I don't know Ruby, and I'd argue it has dissimilar syntax to many other languages I use regularly (that's changed over the years but whatever, my point still stands).
I can still read ruby code, because it's still readable. Same with Lisp, which I never bothered to sit down and learn until about a year ago. Prior to that, I still had no problem reading and understanding it (perhaps not as intuitively as someone who writes it regularly).
The quoted example is, for all intents and purposes, gibberish to me. And I have worked with CoQ.
Well, and to me this syntax makes sense intuitively. And to most beginner programmers, all code looks very hard to understand. I'm really bad at understanding pgsql, I dont't like it at all. People just have different experiences.
Ruby still has algol-like structure, like most common languages. And basic lisp syntax is "normal" function calls with the parens moved around.
Of course, some things are objectivly more complex than others, but making that argument here requires a bit more evidence.
I'm with you about all code is difficult to beginners. About language designers, they should decide who they want to address with their language and how popular they want it to be. If they want to become mainstream and they don't have a way to force people to use it (example: Apple with Objective C and Swift) then they should make a language with a syntax similar to something already mainstream. Example: Elixir got reasonably popular and in its early days it was common to think about it as a functional Ruby. It is not. Anybody using it would find it very different from Ruby by the end of the first day. However there is at least a correspondence between many Module.function / Class.module names in the standard library and the same do / end general structure of code blocks.
My advice to any language designer aiming to mainstream status is to copy some curly braces language (Java, JS, C++) or Python. Then do any weird thing to them, but don't scare away millions of developers with your hello world.
Coq is quite readable imho. I work mostly with k, Ocaml and Haskell (trading); I find ruby unreadable. I find it extremely ugly and my brain simply sees it as line noise, while k (and Egison by the way) reads fine. Each their own, I guess.
do what? write programming languages that you don't already know?