Urbit: a personal cloud computer

Can you explain what the actual problem is? "Only X lines of code" puffery is endemic in programming so I'm not sure why Urbit should be singled out.

But I thought that was the long-term master plan. Isn't the whole point to extricate ourselves from eternal dependence on C and Unix ecosystem?

The question is: Why is my pier not trying to reach any of the available carriers then but only ~zod?

It is, believe it not, designed with readability as a first-class priority. However, a common meme in language design today is that "Code should read like prose." This sounds good, because it means languages are easy to learn. Who wants to learn a bunch of symbols and patterns and junk? I want to code (Python, JavaScript, etc.) now!

But when we program, we aren't dealing with the trivial knowledge English is efficient at exchanging in an email, or the subtly it portrays in a novel. We are talking to a computer. The ideas we explain to a computer are often much more complex than we can explain precisely with English in any reasonable amount of time, so complex we often lose ourselves in them.

Mathematicians and physicists gave up on making human language explain specific technical ideas long ago. Have you ever read a paper on cosmic topology or quantum field theory? There's a comforting padded bumper of English framing the ideas, but the reason the paper is published is in symbols which would appear to the uninitiated as "hundreds of lines of noise." The English is usually just an introduction.

I think Hoon is wonderful [1] because it has both power and predictability. Power lets you express complex ideas concisely and easily, while predictability lets you read and understand someone else's code without frustration. Perl is powerful because it's dense, but it does so at the cost of predictably. Mathematics symbols are terribly powerful, but wildly unpredictable [2]. Python is sort of powerful and sort of predictable. The seductiveness of English simulacra programming languages is that you often don't realize how much power you're giving up because it's just so relaxing to not think about symbols and patterns when your code has the predictability of an email.

Hoon's power is in the zoology of runes (Digraphs) and it's predictability is rooted in its homoiconicity. Every symbol on the keyboard is utilized to build powerful runes, each of which in turn is utilized to append predictable structure onto your AST. When you understand the basic patterns of these constructions and reductions, it's not hard to read someone else's library and understand it in an afternoon. I can't say the same for the Java SDKs I come across. [3]

I'm not saying it isn't inaccessible at first and doesn't take time to learn. I am saying it is worth it.

[1] It's my favorite language - It is just plain fun.

[2] That's why the English frame around a physics paper is there - It tells you what each symbol represents in this paper and what they're trying to do.

[3] The language design also includes several decisions to avoid the pratfalls of other homoiconic languages (Primarily the readability of Lisp), but those are explained in the docs.

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.)