Live data from Hacker News

Urbit: an operating function

urbit.org

31–40 of 177 posts

Re: Urbit: an operating function

#31
The architecture is exciting. The problem is that the aesthetics of the tooling seems deliberately designed to alienate new users. For example the whitepaper gives new names to every punctuation symbol!

And poking around the repo, there are gems like this:

"A...variable name is a random pronounceable three-letter string, sometimes with some vague relationship to its meaning, but usually not..."

"Nock, for mysterious reasons, uses 0 as true...and 1 as false..."

The architecture is really cool, but the syntax is terrible.

Re: Urbit: an operating function

#32
post #26

Earlier quoted context omitted.

>Interesting stuff, but in my usual 15 minutes of attention-span for things like this, utterly impenetrable. It's pretty much designed to be as hard to understand as possible. Look at the source/demo videos - it seems like it's designed to be obfuscated. https://github.com/urbit/urbit http://urbit.org/preview/~2015.9.25/materials/part-i Personally, I can't get over the really made up words.

> Personally, I can't get over the really made up words. The idea of having new names for everything is that when you use a name you've already seen before in another context, you carry forward any ideas you have about things with that name based on their implementations in those other languages. There's a specific meaning for the words that are used for the introductory language concepts: arm, gate, battery, sample,…

Interestingly, this same objection comes up when people try to read so-called (normally French) postructuralist theory from the 60s and 70s. Derrida himself, or Rorty writing on Derrida, supposedly advanced a similar argument, that using new terms allowed one to avoid falling back onto old concepts.

I couldn't find a good source quickly, but it's mentioned here: https://en.wikipedia.org/wiki/Jacques_Derrida#Criticism_from...

Re: Urbit: an operating function

#33

Earlier quoted context omitted.

I always think of TempleOS as well. Both project maintainers have created some impressive and/or interesting technology that is hindered by inflated self importance and being different for the sake of being different. Another common point - HN has a soft spot for both and upvotes most content related to these projects.

They're both run by unpleasant individuals who like to post their opinions about black people on the internet, the main difference is Mencius Moldbug uses fancier words.

Their opinions about things unrelated to technology are, of course, highly relevant to their technological insight.

Re: Urbit: an operating function

#34
post #13
post #9

Earlier quoted context omitted.

Like I said, I'm yet to finish boning up on what, exactly, Urbit is .. Sorry - not trying to be pedantic - but how is IPFS not a personal server? I can serve content with it right now, in fact - its what I mostly use it for at the moment. I guess Urbit is more of an 'operating environment' that allows applications to be built, then?

Yes -- Urbit is a "server" in the sense of "computer," which you control and which runs your own apps. IPFS stores and serves your data; so does Dropbox, Cloudflare, etc. In a sense the best way to see IPFS is as a distributed CDN, of course with an immutable namespace that actually works.

Do you foresee Urbit making use of IPFS?

Re: Urbit: an operating function

#35
post #7
post #5

Interesting stuff, but in my usual 15 minutes of attention-span for things like this, utterly impenetrable. Can anyone who has had the privilege of being invited to the Urbit network enlighten us as to just how useful it is shaping up to be in light of, say, the situation with IPFS by comparison? ( http://ipfs.io ) Because to me, it seems that IPFS may well be ahead in terms of actual applicability right now. Am I mi…

I love IPFS, and it's definitely ahead in terms of applicability. IPFS is solving a different problem -- it's a storage network, not a personal server. IPFS is more comparable to Freenet or BitTorrent. Urbit is more comparable to Sandstorm, although of course they're technically very different.

Is Urbit comparable to Ethereum?

Re: Urbit: an operating function

#36
post #31

The architecture is exciting. The problem is that the aesthetics of the tooling seems deliberately designed to alienate new users. For example the whitepaper gives new names to every punctuation symbol! And poking around the repo, there are gems like this: "A...variable name is a random pronounceable three-letter string, sometimes with some vague relationship to its meaning, but usually not..." "Nock, for mysterious…

Traditional punctuation names suck. "Ampersand", "at sign", "caret"? For a language like hoon where we use a lot of symbols, that gets really tiring. Having one-syllable names for glyphs is really convenient, and they tend to roll of the tongue. Everyone's free to use whatever names they want, of course, we just find these useful. Most people love these once they get used to them.

I don't think you can judge syntax by looking at it -- you have to use it for a little while. Hoon's syntax looks hard, but it's actually rather pleasant to use.

Re: Urbit: an operating function

#37
post #30
post #24

Earlier quoted context omitted.

You're probably capable of something more interesting than a "middlebrow dismissal..."

I think Urbit spends a lot of time framing overlay networks in obscurantist and obfuscatory terms, tightly coupling the simple, useful idea of layering a more flexible network on top of restrictive IPv4 networks with less useful ideas like a series of new programming environments with their own ASCII pronunciation guide. I'm not sure what I gave was a middlebrow dismissal; it was just terse. I find Urbit unserious. I…

We'll call it a terse highbrow dismissal, then.

My terse highbrow dismissal: separating the programming environment from the protocol results in serious, pragmatic problems. For instance: protocols specified in English, in which messages are validated by hand and not by a type system.

Re: Urbit: an operating function

#38
post #11

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 deve…

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.

1: https://raw.githubusercontent.com/chc4/sample-apps/master/bf... 2: http://doznec.urbit.org/home/tree/pub/doc/hoon/library/2b#-s...

Re: Urbit: an operating function

#39
post #5

Interesting stuff, but in my usual 15 minutes of attention-span for things like this, utterly impenetrable. Can anyone who has had the privilege of being invited to the Urbit network enlighten us as to just how useful it is shaping up to be in light of, say, the situation with IPFS by comparison? ( http://ipfs.io ) Because to me, it seems that IPFS may well be ahead in terms of actual applicability right now. Am I mi…

>Interesting stuff, but in my usual 15 minutes of attention-span for things like this, utterly impenetrable. It's pretty much designed to be as hard to understand as possible. Look at the source/demo videos - it seems like it's designed to be obfuscated. https://github.com/urbit/urbit http://urbit.org/preview/~2015.9.25/materials/part-i Personally, I can't get over the really made up words.

You mean that out of all the things in this combinator [0] flavored abstract rewrite system [1], programmed via a symmetrical [2], forward-inferenced [3] typed language, exposing modula-2 style per-code-block compilation control [4], all designed to support a content centric [5], natively networked [6] global computing environment with sovereignty-hard siloing capabilities [7], the most difficult part to understand is the naming scheme?

Edit: In the early Urbit docs [8] there was a nigh ad nauseam emphasis on the "stupidity" of the project. What the epiphany of careful inspection revealed was that this stupidity was not that of intellectual deficiency, but rather opposition to "cleverness" of the kind that tends to foster (and infest) Urbit's peer group of deep stack [9] rebuilds. One of the most insightful comments I've heard after springing Urbit on unsuspecting PL professionals was (paraphrased): "It [Urbit] does all the things we've said we wanted, in the worst possible way." All words are equally made up until grounded in referents. The question is, are the Worfian shorthands new words provide worth the cost [10] of expanding the symbol table, as compared to the interpretation overhead of translating new concepts into old? Under the burden of internalizing all the content linked below and more, I judge new vocabulary justified.

[0] http://www.ucombinator.org/

[1] https://en.wikipedia.org/wiki/Abstract_rewriting_system (ARS being the most mechanical of the pure computational models outside reversible logic)

[2] http://tunes.org/wiki/symmetric_20lisp.html

[3] https://en.wikipedia.org/wiki/Forward_chaining

[4] https://en.wikipedia.org/wiki/Modula-2#Description (see Definition/Implementation modules)

[5] https://en.wikipedia.org/wiki/Content_centric_networking

[6] http://netcentriccomputing.org/

[7] https://en.wikipedia.org/wiki/Capability-based_security (not yet fully implemented)

[8] http://moronlab.blogspot.com/2010/01/moron-lab-goals-princip...

[9] I won't say full stack, because the reshaping blade only penetrates OS deep. For a hardware-grounded reset, see good old Loper OS (http://www.loper-os.org/?p=8).

[10] Because words are context dependent, this expansion is only logarithmic with respect to the increase of immediately referable concept space.

Re: Urbit: an operating function

#40
post #36
post #31

The architecture is exciting. The problem is that the aesthetics of the tooling seems deliberately designed to alienate new users. For example the whitepaper gives new names to every punctuation symbol! And poking around the repo, there are gems like this: "A...variable name is a random pronounceable three-letter string, sometimes with some vague relationship to its meaning, but usually not..." "Nock, for mysterious…

Traditional punctuation names suck. "Ampersand", "at sign", "caret"? For a language like hoon where we use a lot of symbols, that gets really tiring. Having one-syllable names for glyphs is really convenient, and they tend to roll of the tongue. Everyone's free to use whatever names they want, of course, we just find these useful. Most people love these once they get used to them. I don't think you can judge syntax b…

Also, the three-letter variable names aren't part of Hoon -- they're just a convention that works well if (and only if) you have short, simple functions.

I've actually taken to using TLVs with a Hungarian suffix in C -- it works well if (and only if) you have short, simple functions.

One way to think about variable names: declaring a variable is a way of saying "I couldn't quite get this into point-free form." Names should be the exception, not the rule. Again, this is much more true in a functional language.

Post reply on HN