Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Urbit: an operating function

urbit.org

Post reply on HN
Print view View original

21–30 of 177 posts

Re: Urbit: an operating function

#21

Post by yarvin9 »

jitl wrote: 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…

Apparent usability isn't the same as actual usability. Pretty much everyone who learns Hoon is surprised by how easy it was, which may be a good thing or a bad thing depending.

There are about a hundred runes (digraphs) in Hoon, but you mostly see only 10 or 15. Also, they're organized by internal structure (all | runes do the same kind of thing), and most runes are macros which resolve to about 20 built-in forms. It's a couple of orders of magnitude easier than learning Chinese, which again may be a good thing or a bad thing.

Variable names designed to be memorable rather than meaningful are pretty normal in both math and functional programming. Math uses Greek letters for the same purpose, for instance. Also, as we note explicitly, this is a style that's optimal for simple code - in any language, you'd probably write add(a, b), not add(left_argument, right_argument).

Actually, Perl originally won because it was easy to get things done. It's had problems since, but for different reasons...

Re: Urbit: an operating function

#22

Post by gkya »

I do computing daily i.e. I use the internet like anyone else, and I use Emacs for feeds, mail, writing, programming little tools in elisp etc. Now after having read this, I cannot see how it be supposed to improve my daily computing routine. I think that it is indeed revolutionary this Urbit thing, in that it is as opaque and unpractically idealistic as any other revolution.

Re: Urbit: an operating function

#23

Post by yarvin9 »

MichaelAza wrote: post #6
kungfooguru wrote: post #4

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.

It'd be interesting to hear a more detailed description of what you'd classify as "different for the sake of being different."

There's certainly plenty of code in this world that's the same for the sake of being the same. It's not terribly interesting to use CGA graphics for the sake of being different. On the other hand, I do wonder whether my children will grow up learning 1970s programming for the sake of being the same.

Re: Urbit: an operating function

#24

Post by yarvin9 »

tptacek wrote: post #19
kungfooguru wrote: post #4

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

It's too bad, really, because someone should do a serious general-purpose overlay network project, and it's clear that Urbit isn't it.

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

Re: Urbit: an operating function

#25

Post by deegles »

yarvin9 wrote: post #23
MichaelAza wrote: post #6

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.

It'd be interesting to hear a more detailed description of what you'd classify as "different for the sake of being different." There's certainly plenty of code in this world that's the same for the sake of being the same. It's not terribly interesting to use CGA graphics for the sake of being different. On the other hand, I do wonder whether my children will grow up learning 1970s programming for the sake of being th…

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.

Re: Urbit: an operating function

#26

Post by yebyen »

akhilcacharya wrote: post #14
fit2rule wrote: 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.

> 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, core, rune, glyph, ... twig, jet, and so on.

Many of these are either new concepts, or new arrangements of old concepts. A gate is not a lambda or a function, neither is a core, and if either were called those things anyone who hadn't seen them explained before would probably go ahead and take the big word to their nearest search engine, only to become even more confused by idiosyncratic and sometimes conflicting explanations of those ideas that appear slightly differently in hundreds of other languages.

I think that Hoon hopes to be the first programming language for a lot of people one day, so they won't usually be coming expecting familiar things to have familiar names.

Re: Urbit: an operating function

#27

Post by pcmonk »

deegles wrote: post #25
yarvin9 wrote: post #23

Earlier quoted context omitted.

It'd be interesting to hear a more detailed description of what you'd classify as "different for the sake of being different." There's certainly plenty of code in this world that's the same for the sake of being the same. It's not terribly interesting to use CGA graphics for the sake of being different. On the other hand, I do wonder whether my children will grow up learning 1970s programming for the sake of being th…

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.

Re: Urbit: an operating function

#28

Post by yarvin9 »

deegles wrote: post #25
yarvin9 wrote: post #23

Earlier quoted context omitted.

It'd be interesting to hear a more detailed description of what you'd classify as "different for the sake of being different." There's certainly plenty of code in this world that's the same for the sake of being the same. It's not terribly interesting to use CGA graphics for the sake of being different. On the other hand, I do wonder whether my children will grow up learning 1970s programming for the sake of being th…

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.

I'll give you that one! It's an old mistake and not very costly in practice, but the intuitive rightness isn't worth the pain in the butt. But the pain in the butt also isn't painful enough to match the difficulty of fixing it.

I actually got this bad idea from Unix: !strcmp(), etc. It's certainly easier to overload error codes into a 0=true scheme, although Urbit doesn't actually do that.

Re: Urbit: an operating function

#29

Post by GFK_of_xmaspast »

MichaelAza wrote: post #6
kungfooguru wrote: post #4

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.

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.

Re: Urbit: an operating function

#30

Post by tptacek »

yarvin9 wrote: post #24
tptacek wrote: post #19

Earlier quoted context omitted.

It's too bad, really, because someone should do a serious general-purpose overlay network project, and it's clear that Urbit isn't it.

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 think that's unfortunate, because someone should do a serious, pragmatic overlay network.

Post reply on HN