the concepts expressed in the first section "Obstacles" are interesting and make for good reading, but the implementation strategy in "Definition" are nuts. The authors completely disregard human nature and usability when designing Hoon. Random variable names? Sigils-only syntax? If they want to replace Unix and the Internet, they should remember why Unix won: because it was easy tp get things done.
In Urbit new developers not only have to learn all the new concept words, they also have to suffer through a brainfuck/perl syntax and a hostile programming style. Success seems impossible.
I'm not exactly unbiased to Urbit, but I found Hoon as usable as they say it is. It seems like everyone that hears about Hoon's rune syntax comments about how insane it is, but it really is easy to get into.
I'm partial to calling it "Chinese Lisp" - Hoon runes are converted directly into AST nodes, but instead of using friendly words it uses weird diagraphs. The fact that the runes are grouped into families makes it much simply, however. You don't have to know what "|*" does exactly, just know that all runes that start with bar (|) create the equivalent of functions, so it has to be related to that. Instead of memorizing 100+ runes that are all completely different from eachother, most of them are just variants of others and are even macros to other runes.
While it may look like garbage, programs such as a brainfuck vm[1] are easy to scan when you can get the gist of the program structure very easily.
While some of the names are quite a pain, a good portion of the stdlib's arms are teniously named related to their subject, or are very easily grouped with their function. snag is index, scag is prefix, slag is suffix.[2] The docs for the stdlib, along with examples of how to use it, are shipped with every planet at http://localhost:8080/home/tree/pub/doc/hoon/library, although the initial page generation takes a bit. I'm not that big of a fan of the CVC variable names, however.
Apparent usability isn't the same as actual usability. Pretty much everyone who learns Hoon is surprised by how easy it was, which may be a good thing or a bad thing depending.
There are about a hundred runes (digraphs) in Hoon, but you mostly see only 10 or 15. Also, they're organized by internal structure (all | runes do the same kind of thing), and most runes are macros which resolve to about 20 built-in forms. It's a couple of orders of magnitude easier than learning Chinese, which again may be a good thing or a bad thing.
Variable names designed to be memorable rather than meaningful are pretty normal in both math and functional programming. Math uses Greek letters for the same purpose, for instance. Also, as we note explicitly, this is a style that's optimal for simple code - in any language, you'd probably write add(a, b), not add(left_argument, right_argument).
Actually, Perl originally won because it was easy to get things done. It's had problems since, but for different reasons...
Every time I look at Hoon I think "this looks like the same sort of cliff-steep startup followed by 'woah' as vi", but I can never quite get past the cliff as yet.
The random three-letter variable names are only used in the kernel, and they're meant to only be used in code that's small/simple enough that they're warranted. In my opinion, we use too many of them, and I've been converting many of them to longer, more descriptive names. The rule that "punctuation is syntax, text is content" is useful, and it becomes very natural with a bit of practice.
Hoon is very much not designed to be apparently usable, it is designed to be actually usable. Personally, I find it to be one of the most usable languages I've ever used.
In Urbit new developers not only have to learn all the new concept words, they also have to suffer through a brainfuck/perl syntax and a hostile programming style. Success seems impossible.