Hacker News Reader

Comment by jobeirne | Hacker News Reader

This project is reinventing a bunch of stuff that's completely orthogonal to the goal of a decentralized app platform. They've written an OS, a filesystem, a networking layer -- all in a completely new language that looks incomprehensible (https://github.com/urbit/arvo/blob/master/arvo/clay.hoon).

I doubt very much this project will get much traction due to the enormous conceptual overhead of working within its ecosystem. There's a huge learning curve approaching something like this from the Unix/C ecosystem, and I don't think it's merited.

View on HN

“[I]n many ways nonsense is a more effective organizing tool than the truth. Anyone can believe in the truth. To believe in nonsense is an unforgeable demonstration of loyalty. It serves as a political uniform. And if you have a uniform, you have an army.” ― Mencius Moldbug (a.k.a. Curtis Yarvin author of Urbit)

This guy sounds more and more like the L. Ron Hubbard of software.

The language designer must be a fan of writing assembly language, combined with some LISPy syntax, or something... that's the closest analogy I can think of from looking at it. Maybe it requires some IDE type of editor to make it comprehensible.

From the authors:

    Its syntax is entirely novel and initially quite frightening.

    [...]

    If I can summarize Hoon's goal, it's to be the C of functional 
    programming. 

    [...]     

    On the other hand, the apparent complexity of Hoon is very high. 
    When you open a Hoon file, you are confronted with an enormous
    avalanche of barely structured line noise. Again this reminds us
    of C, which makes no attempt at the kind of abstract prettiness
    we expect from a Pascal or a Haskell. Learning Hoon involves
    learning nearly 100 ASCII digraph "runes."

    Is this a harsh learning curve? Of course it is. On the other hand,
    it is not a mathematical task, but a mechanical one. It is trivial
    compared to the task of learning the Chinese alphabet, memorizing
    the Qu'ran, etc, all rote mental tasks routinely performed by normal
    human 11-year-olds.

From the languages even more confusing documentation: https://github.com/cgyarvin/urbit/blob/master/doc/book/0-int...

I think you're probably better off reading the current docs: http://urbit.org/docs/

For entertainment value, might I suggest the Hoon syntax page?

http://urbit.org/docs/hoon/syntax/

My current pet theory is that they obfuscated Urbit so much because otherwise, the artificial scarcity of address space would be unenforceable. As it is, you have to make a huge investment in learning their tech to understand everything, and if you wanted to launch a competing network, no one would help you establish your network effect. Everyone else who has gone through the same elaborate hazing ritual has developed enough camaraderie to keep the defection rate low. The profitable strategy is to cooperate, buy a star, and build software people will want.

I have some skepticism, but if Urbit and its peer-to-peer network are actually useful things, the incentive system for building useful apps for it exists. It might be strong enough.

I feel like at any point this functionality becomes desirable it would be trivial to implement in any language humans actually use.

There's no reason a more comfortable language can't be implemented on Hoon; it's just that no one has done it yet, because no one has come along who both understands Hoon well enough to do it and finds Hoon unpleasant enough to bother.

This may mean Hoon once learned is easier to cope with than it looks (which I doubt, because it looks like vaguely Lisp-flavored assembly) or it may just mean that nobody like that has come along yet.

Also:

* pretty much everything actually useful is implemented as a jet

* the jets often don't actually match the supposed code they're accelerating (e.g. the Markdown jet has different bugs)

Isn't that just the Markdown jet? Or are there other examples I haven't yet heard about?

Worse, there is no formal spec or particular commitment to either the jets or the means by which the VM communicates with its host environment or nodes communicate with each other; this makes it impossible, not just impractical, to replace the environment with an alternative rather than merely wrap what exists - Nock on its own is simply not enough to build on.

Instead of the stated intent of giving you control of your own environment, the actual goal appears to be the opposite.

Communication between urbits appears to be well defined, although my lack of close familiarity with the codebase makes it impossible for me to point at precisely where; ask someone at Tlon, or someone in Urbit :talk. Communication between an urbit and its host is precisely defined by the u3 implementation.

The C standard library lacked a formal specification for over a decade after its creation. Lisp lacked one for almost thirty years. At least one of these should be an argument in favor of "build it first, formalize it later".

That language is atrocious! That has to be compiled / transpiled from something higher level

That criticism applies very well to javascript in 2016 as well, so I don't think it's a very big deal.

It will be.

Looking at that file made me feel like I had aphasia.

That's what you get when you mix assembly and brainfuck.

Reply on news.ycombinator.com