The nonsense words are all names. This is entirely a style choice. The actual name syntax is roughly Lisp's - for instance, (my-long-function arg1 arg2) does the same thing (roughly) in Hoon as in Lisp.

In the "lapidary" Hoon in which most of the kernel is written, facets (variable names, roughly) are meaningless TLV strings, usually CVC (consonant-variable-consonant).

The user experience is much the same as with Greek letters in math: you remember the binding between symbol and semantics if you know the code you're looking at. If you are learning the code, your first task is to learn that binding. Once you know the code, there is no quasi-semantic intermediary - a meaningful name - between the symbol and the concept.

I think our small sum of experience with this daring idea is that sometimes, it works better than other times. Basically, TLV naming is appropriate for code that is simple, but not trivial. (Trivial code, like "++add", is "ultralapidary" and gets OLV names - like "a" and "b".)

Ideally all of the Arvo kernel and Hoon self-compiler would meet the TLV standard of quality. All of it is written this way, though. In general, if you should be writing lapidary code, you know it, and if you don't know you shouldn't. (And should use more or less normal names as in any Lisp.)

It's very difficult for a language, good or bad, to compete on its own merits or even demerits. C is a better language than Pascal, but people didn't start programming in C because of that - they started programming in C because the native language of Unix was C, and they wanted to program in Unix. Why did they want to program in Unix? Because, relative to its competitors in the minicomputer OS market, Unix was a better way to solve their problems. This is the normal way that new languages achieve adoption - they ride on the back of a new platform, which rides on the back of new solutions to (typically) new problems.

Today you see a lot of apps like Buffer and Slack, which are very successful in terms of userbase and even revenue. From a certain perspective, the value these apps are adding is very minimal - Buffer is... what, cron? And yet, there is a considerable distance between an AWS box in the cloud and a Buffer instance. A lot of value actually is being added.

Most of the code in a product of this type is actually the (usually somewhat) general framework that sits between the Linux ABI and the application logic/UI. Essentially there's a type of Greenspun's Law in play. If you build a layer like this, but as a true operating environment rather than an internal framework, the result is a VM in which the distance from a virgin instance to many of these kinds of apps is much smaller. In a familiar Valley pattern, they then become commoditized and have more trouble extracting rents.

If it's possible to provide this kind of value, which we certainly haven't yet demonstrated, I can assure you quite confidently that a flashcard or two is not an obstacle. I'm in my 40s, so I know how hard it is for a middle-aged dog to learn new tricks. But it's not that hard.

  ++  pimp              ::  traced request
    $:  ful=?           ::  | === HEAD
        fur=(unit mark) ::  type goal
        hen=duct        ::  event trace
        som=seam        ::  logical request
        pez=pest        ::  request state
        sip=marl        ::  injected scripts
    ==                  ::

Now, this style (four-letter lapidary arm names, usually not nonsense strings but nonsense words) works in some places but not others. Frankly, %eyre is not exactly a triumph of the lapidary style...