7 ms·

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 ne

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

dmix 10y ago
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-intro.markdown https://github.com/cgyarvin/urbit/blob/master/doc/book/0-int...
- state 10y ago
  I think you're probably better off reading the current docs: http://urbit.org/docs/ http://urbit.org/docs/
  - smellf 10y ago
    For entertainment value, might I suggest the Hoon syntax page? http://urbit.org/docs/hoon/syntax/ http://urbit.org/docs/hoon/syntax/
ModernMech 10y ago
“[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)
- pavlov 10y ago
  This guy sounds more and more like the L. Ron Hubbard of software.
seibelj 10y ago
That language is atrocious! That has to be compiled / transpiled from something higher level
- 5ilv3r 10y ago
  That criticism applies very well to javascript in 2016 as well, so I don't think it's a very big deal.
- throwanem 10y ago
  It will be.
eridius 10y ago
Looking at that file made me feel like I had aphasia.
imaginenore 10y ago
That's what you get when you mix assembly and brainfuck.
natrius 10y ago
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.
- forthefuture 10y ago
  I feel like at any point this functionality becomes desirable it would be trivial to implement in any language humans actually use.
  - throwanem 10y ago
    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.
    - davidgerard 10y ago
      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)
      - throwanem 10y ago
        Isn't that just the Markdown jet? Or are there other examples I haven't yet heard about?

dmix 10y ago

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-intro.markdown https://github.com/cgyarvin/urbit/blob/master/doc/book/0-int...

state 10y ago
I think you're probably better off reading the current docs: http://urbit.org/docs/ http://urbit.org/docs/
- smellf 10y ago
  For entertainment value, might I suggest the Hoon syntax page? http://urbit.org/docs/hoon/syntax/ http://urbit.org/docs/hoon/syntax/

ModernMech 10y ago

“[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)

pavlov 10y ago
This guy sounds more and more like the L. Ron Hubbard of software.

seibelj 10y ago

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

5ilv3r 10y ago
That criticism applies very well to javascript in 2016 as well, so I don't think it's a very big deal.
throwanem 10y ago
It will be.

eridius 10y ago

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

imaginenore 10y ago

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

natrius 10y ago

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.

forthefuture 10y ago
I feel like at any point this functionality becomes desirable it would be trivial to implement in any language humans actually use.
- throwanem 10y ago
  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.
  - davidgerard 10y ago
    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)
    - throwanem 10y ago
      Isn't that just the Markdown jet? Or are there other examples I haven't yet heard about?