Live data from Hacker News

Urbit: an operating function

urbit.org

41–50 of 177 posts

Re: Urbit: an operating function

#41

Reading anything from them always reminds me of TempleOS. There are some hilarious gems if you skim it, like "Urbit is highly intolerant of computation error, for obvious reasons, and should be run in an EMP shielded data center on ECC memory."

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.

> being different for the sake of being different

Urbit has brilliant technical insight into perhaps the hardest problem our industry currently faces: why does everything always turn into a big ball of mud?

Urbit may turn out to be incredibly important. Parent comment is unjustified, uninformed, poor tone and ad hominem.

Re: Urbit: an operating function

#42
post #13

Earlier quoted context omitted.

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?

When both succeed, certainly. :-) We certainly don't try to solve the CDN problem that IPFS is solving.

Re: Urbit: an operating function

#43
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…

I admit that I have a fondness for learning esoteric languages. That said I've actually gone far enough down the urbit rabbit hole to write a set of tutorials[0].

urbit has a high startup cost and is hampered by a lack of documentation as well as a desire to reinvent terminology as well as a fast changing API to write too. All of which means that it's more suitable for the curious and hobbyists right now.

I'm withholding judgement on whether it will manage to succeed despite these.

[0]: http://hidduc-posmeg.urbit.org/home/pub/hoon-intro/

Re: Urbit: an operating function

#44
post #37
post #30

Earlier quoted context omitted.

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.

The notion that Urbit believes it can solve all the problems, rather than tackling a single important problem, is one of the things that makes it unserious to me.

The inflexibility of the Internet service model is a serious problem. Poor formal methods for verifying protocols is a serious (albeit not lucrative) problem. Programming languages that make it difficult to express correct programs: serious problem. It is not clear to me how the solution to all three of those problems is the same startup.

Re: Urbit: an operating function

#45
post #27
post #25

Earlier quoted context omitted.

One example is that they flipped the meaning of 0 and 1 in their new language. >We should note that in Nock and Hoon, 0 (pronounced “yes”) is true, and 1 (“no”) is false. Why? It’s fresh, it’s different, it’s new. And it’s annoying. And it keeps you on your toes. And it’s also just intuitively right.

This is exactly the way it's used in shell scripting, and honestly, it's more useful that way for us because it makes booleans default to true instead of false. If we're going to redo everything, we may as well do it right this time.

> This is exactly the way it's used in shell scripting

You say that like it’s a good thing.

Re: Urbit: an operating function

#46
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…

This right here is what I mean when I suggest Urbit is unserious. "Green is just yellow and blue. Why do we call it 'green'? That name sucks. From now on, we're going to call it 'yellue'."

There's overreaching first-principles boil-the-ocean dorm room rethinking of concepts, and then there's renaming the ASCII characters.

Re: Urbit: an operating function

#48
post #46
post #36

Earlier quoted context omitted.

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…

This right here is what I mean when I suggest Urbit is unserious. "Green is just yellow and blue. Why do we call it 'green'? That name sucks. From now on, we're going to call it 'yellue'." There's overreaching first-principles boil-the-ocean dorm room rethinking of concepts, and then there's renaming the ASCII characters.

You know someone's going to pop up and talk about the Russian names for blue, and how changing the word allows us to change the way we see things, right?

http://www.pnas.org/content/104/19/7780.full

Re: Urbit: an operating function

#49
post #46
post #36

Earlier quoted context omitted.

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…

This right here is what I mean when I suggest Urbit is unserious. "Green is just yellow and blue. Why do we call it 'green'? That name sucks. From now on, we're going to call it 'yellue'." There's overreaching first-principles boil-the-ocean dorm room rethinking of concepts, and then there's renaming the ASCII characters.

[deleted]

Re: Urbit: an operating function

#50
Awesome.

'For example, %= sounds like "centis" rather than "percent equals." Since even a silent reader will subvocalize, the length and complexity of the sound is a tax on reading the code.' This is great. Clever how some of the sounds are reminiscent of existing readings.

Post reply on HN