[olympus]

My main claim was that Urbit isn't revolutionary. It is really just a Unix server and programming language. However, in an attempt to seem more sophisticated they invented new words so that nobody could figure out what it was. Urbit is purposely obtuse in their terminology, when they really could just use words that programmers already know and use. Here's some examples from the documentation you linked:

"A value in Hoon is called a noun" - or you could just call it a value.

"A gate is a Hoon function" - or you could just call it a function.

"A core has no exact equivalent in conventional languages, but the closest equivalent is an object. An object has methods; a core has functionally computed attributes (arms). An arm that produces a gate is the Hoon equivalent of a conventional method;" - or you could just say that objects in Hoon (the language) can have methods and attributes, and you would never need to invent the core/arm/gate terminology.

They try to give themselves an out by saying stuff like "Hoon has concepts like all these abstractions, but they remain false cognates." When you dig into it, the only unique things are the words. It's like children trying to come up with a code- "instead of door we'll say blorp and instead of close we'll say bleep. Now bleep the blorp before we continue inventing our code.

[pcmonk]

> "A value in Hoon is called a noun" - or you could just call it a value.

A "value" sounds like an abstract concept. A noun is one of two things: a natural number or a pair of nouns. Calling it a "value" makes it sound much more abstract than it is.

> "A core has no exact equivalent in conventional languages, but the closest equivalent is an object. An object has methods; a core has functionally computed attributes (arms). An arm that produces a gate is the Hoon equivalent of a conventional method;" - or you could just say that objects in Hoon (the language) can have methods and attributes, and you would never need to invent the core/arm/gate terminology.

A core is not an object in any meaningful sense. You can create stuff that looks like objects with them, but they're used for a lot more than that. For example, all gates/functions are cores, but there's no sense in which you'd call those "objects".

> They try to give themselves an out by saying stuff like "Hoon has concepts like all these abstractions, but they remain false cognates." When you dig into it, the only unique things are the words. It's like children trying to come up with a code- "instead of door we'll say blorp and instead of close we'll say bleep. Now bleep the blorp before we continue inventing our code.

The thing about revolutionary concepts is that their underlying principles are different than what you're used to, so if they look similar on the surface, you're lulled into thinking they're basically the same. But anyone who's put significant effort into programming in Urbit will tell you the system is fundamentally different. Not in the sense of "you could never understand what's going on here"; but rather, "we made these few different design decisions in the beginning, and that permeates everything".

[tptacek]

For example, all gates/functions are cores, but there's no sense in which you'd call those "objects".

To me, all you're doing here is describing an object-based language in which functions are first-class. Obviously, Urbit didn't invent this concept. Its predecessors used normal names for these terms. Why does Urbit invent new ones?

We could productively stay focused on just this one example, and see if there's a better reason for Urbit to call its objects "cores" and its methods or attached functions or computed attributes "arms".

[pcmonk]

> To me, all you're doing here is describing an object-based language in which functions are first-class. Obviously, Urbit didn't invent this concept. Its predecessors used normal names for these terms. Why does Urbit invent new ones?

That's a pretty (unintentionally) misleading description of it. What is an object? An Urbit function has basically nothing that an OOP object has. No class, no inheritance, no attributes, and no methods. It's just a way of encapsulating a formula (VM assembly expression) in a way that's convenient to call with formulas. It uses the the "core" pattern because it's convenient.

"Arm" is a pretty specific term that refers to the way an "element" of a core is represented in the core. When you want to map a particular use of cores to its underlying representation in the "core" pattern, you want to be able to talk about specific data structures.

In general, Urbit errs on the sides of giving names to concepts that could only otherwise be described in multiple sentences. Most projects just don't give names to those concepts. Urbit needs better human descriptions of its concepts, but using traditional names for them would be misleading.

[tptacek]

How are these not problems that every VM for a high-level programming language also addresses?

[pcmonk]

They absolutely do, with their own terms. Isn't an S-expression just a list? Isn't a method just a "member function", which is really just a function, which is really just a subroutine? Every language comes up with its own terms, especially for things that are a little different from previous work.

Urbit isn't trying to solve many new problems; it's trying to solve old problems in different ways. They just want to be able to talk about the constructs in their solutions.

[tptacek]

Right, I get that. So I guess my question is: in what ways justifying new terminology are the approaches taken by Urbit different? And whether or not they're different enough from prior art to merit obscure new terms, are those differences worthwhile, or are they different for the sake of being different? Because not all of the last 30 odd years of systems and programming research was pointless.

[jerkstate]

> A noun is one of two things: a natural number or a pair of nouns

To most of us, a "noun" is a person, place, thing, idea, or feeling.

I started replying to the other stuff you were saying, but I started getting this feeling like you're in on the joke and I'm not.

[pcmonk]

To most of us an "object" is something you can touch. We overload these terms all the time.

[aboodman]

> A core is not an object in any meaningful sense. You can create stuff that looks like objects with them, but they're used for a lot more than that. For example, all gates/functions are cores, but there's no sense in which you'd call those "objects".

In many, many languages, a function is also an object.

[han-sel]

"It is really just a Unix server and programming language."

You should read https://urbit.org/posts/overview/

The whole reason Urbit exists is that Unix + the internet is broken and needs a complete overhaul

Re: the different names, there are slight differences between gates and functions, but I agree they're not important enough to merit the change in name. But hey, it takes a purist to spend 15 years rewriting the whole stack from scratch!

[occultist_throw]

Yep. Unix and Linux are broken.

So instead, I should load up Urbit, locate on a planet, spin up a garglemitz on the spitzenspeil with the hoon japing over the nock.

If you add Xenu, Body Thetans, e-meters, I think you might be on to something!

--------------------

No seriously. There are wrong things with the monolothic kernel as well as microkernels. Theyre design tradeoffs. But none of the existing, well established methods throw away the language of computing of the last 60 years. Some tech stacks may add a new type, but they are able to describe why a new classification is needed, and how it fits iin the existing model.

What Urbit is doing, is polluting the namespace by turning existing nomenclature into some sort of technofreakish cult. Up is now down. Down is now blarbbliboop. And anyone questioning the "Master" is berated and denigrated by means of 'lack of intelligence'. You all should be defending your way and means.

Because in my eyes, you all are wrong until you can start integrating standard and normal nomenclature - because it's hiding something unsavory.

[jacobush]

Best comment so far - you put words on what disturbs me so much about Urbit. It takes the technobabble to a whole new level. I don't care if they succeed, I want no part of it.

[occultist_throw]

Thank you.

Given my proclivities in the occult, I do indeed have to watch out for real life cults. Now, I know this document is primarily for esoteric religion, it also very much applies to cults in other senses. But there's a few that really sticks out with me.

http://www.neopagan.net/ABCDEF.html

To me, this is a damning list of reasoning that Urbit should be considered a Cult, and thusly stayed away from. The only exception I give is, is to peeling back their crypto-jargon for any new concepts of computer science we in the larger community should document, understand, and use.

Interacting with this community only leads to poisonous cult mindsets that can easily damage your mind. Beware.

________________________________________________________________

1. Wisdom/Knowledge Claimed by leader(s); amount of infallibility declared or implied about decisions or doctrinal/scriptural interpretations; number and degree of unverified and/or unverifiable credentials claimed.

Go look up anyone under Curtis Yarvin. Even in the HN thread. He is "The Master", and you are just too stupid to understand his pure clear thought.

2. Wisdom/Knowledge Credited to leader(s) by members; amount of trust in decisions or doctrinal/scriptural interpretations made by leader(s); amount of hostility by members towards internal or external critics and/or towards verification efforts.

The evidence here is the appropriate HN posts, that give scorn for highlighting major issues with the language, choices in the network architecture, and choices elsewhere in Urbit as a whole. Anyone questioning anything with Urbit is either attacked, derided, ignored, or pushed aside usinng "Whataboutism".

3. Dogma: Rigidity of reality concepts taught; amount of doctrinal inflexibility or “fundamentalism;” hostility towards relativism and situationalism.

You need to Arvo the hoon into the lolwut iron branch thats in a wet case. WHAT HOW DARE YOU NOT UNDERSTAND. You're just stupid, I guess.

4. Censorship: Amount of control over members’ access to outside opinions on group, its doctrines or leader(s).

By definition, they all use Urbit to communicate. I looked in Freenode #urbit , and its something "superior" called tahc.. Yet if you look how Urbit works, any higher class user can disable sub-users' accounts. They call them stars/planets. Whatever. But your superior owners of your network block/address can censor you. And since it's federated, NOT decentralized or distributed, your id is easily blocked.

5. Isolation: Amount of effort to keep members from communicating with non-members, including family, friends and lovers.

Insert all the completely new jargon. Instead, it separates users from IT anywhere else. This is the same thing Scientology does, so people feel special and "connected" only within their clique. Of course it doesn't translate out, so it can be used as a differentiator of "Those who know".

6. Dropout Control: Intensity of efforts directed at preventing or returning dropouts.

Lockin is their way of handling this. Obviously they aren't holding guns to your head. But it's more of not wanting to cut losses because there "could" be something.

7. Grimness: Amount of disapproval concerning jokes about the group, its doctrines or its leader(s).

Mencius Moldbug / Curtis Yarvin. I need say no more.

________________________________________________________________

[Fang_]

Full disclaimer: I recently started working for Urbit, but have been involved in its community for about a year and a half now.

It pains me to see people paint the project and its people in this light. I don't know if I'm taking the bait here or playing into your cards or whatever, but I want to try and clear some things up.

> He is "The Master", and you are just too stupid to understand his pure clear thought.

Not really. He's actually been really helpful in explaining some of the decisions that were made in the past to me, and it never felt like my say in discussions regarding ongoing work didn't matter.

> Anyone questioning anything with Urbit is either attacked, derided, ignored, or pushed aside > You're just stupid, I guess.

I don't know what communities you've been in that people just go "you're stupid" when you don't understand something. In my experience with Urbit's chat rooms (and the forums, subreddit, etc.), people are generally friendly and understanding of the struggles that come with jumping into an entirely new stack like this. We know things can be confusing, we know it's hard when you're just starting out. We're also very much ready to help, and do care about discussing concerns and criticism.

I'd be willing to go so far as to say that, right now, Urbit's community is one of the nicest on the internet, but of course that's a tough comparison.

Aside, maybe interesting: the arcane naming of the Hoon stdlib is getting rewritten to be much more sensical and easily understandable. Why? Some community members were displeased, and someone took it upon themselves to make the rewrite happen. We're happily merging that in once it's done.

> By definition, they all use Urbit to communicate.

And you can reach us without even installing Urbit on your machine. Take a look at http://urbit.org/stream/

> any higher class user can disable sub-users' accounts

"Disable" isn't the right word here. A higher class can choose to stop helping a sub-user with peer discovery and to stop providing software updates to them. But if a sub-user is not content with the service their parent is providing, and/or they feel like they were unjustly blocked, they are free to find a parent that wants to adopt them.

Using that mechanism, communities that oppose each other can cleanly separate and continue doing their own thing without any bloodshed on either side.

> not wanting to cut losses because there "could" be something.

Doesn't this apply to pretty much anything happening in the decentralization and crypto spaces right now?

> I need say no more.

Well, I've never experienced "disapproval concerning jokes about the group". We're not above joking about the weirdness of our own system, it's something we're very much aware of.

[occultist_throw]

> It pains me to see people paint the project and its people in this light. I don't know if I'm taking the bait here or playing into your cards or whatever, but I want to try and clear some things up.

Indeed not. I looked at Urbit as a way to do untrusted computation spread across multiple nodes. Think of a distributed Lambda not dissimilar to that of IPFS, but for computation. I tried to give it a fair shake. However roadblocks were everywhere. I would have to throw out most of my computing knowledge and start over to even analyze it. And writing programs in Hoon is ridiculous. My current tooling - nonfunctional. It not only disregards current nomenclature, but any sort of tooling I have to develop, make, and troubleshoot.

In the end, the further I try to get the 10,000 mile view, its just a federated system with a screwy network topology. And as tptacek has noted, the base code has very strongly written "bad choices", CS-wise.

> I don't know what communities you've been in that people just go "you're stupid" when you don't understand something. In my experience with Urbit's chat rooms (and the forums, subreddit, etc.), people are generally friendly and understanding of the struggles that come with jumping into an entirely new stack like this. We know things can be confusing, we know it's hard when you're just starting out. We're also very much ready to help, and do care about discussing concerns and criticism.

My experiences with Urbit have been primary documentation (which I am told elsewhere is the last place to look ?! ), people who show up from the "woodwork" on any thread that mentions Urbit, and some very hostile conversations on the 'web primarily discussing Yarvin's statements.

And unlike libraries like JQuery or Node.js , I can use them without being "part" of the community. I import them, load them, and use them. No muss, no fuss. Whereas, Urbit's community is inexorably tied to the foreign code and systems. I cannot simply download and use it - there's tons of content that is shared within the community. In coded language of Urbit, no less.

To understand, I have to use. To use, I have to understand. Both of these are going to take a great amount of time; and the knowledge here is non-transferable.

And strangely, once people start using that language, they seem to fail to explain the fundamental principles on which they rest on. I note this as the same type of trap that esoteric and religious cults use. They fail to explain what their terms really mean - and then it is a mixture of giving up, ignoring them, anger, or derision.

> And you can reach us without even installing Urbit on your machine. Take a look at http://urbit.org/stream/

Thank you. I saw that earlier. It looks something like Disqus or IRC on a website. It's obviously done with Urbit, but alas, it still doesn't help with deciphering any of the nomenclature.

> "Disable" isn't the right word here. A higher class can choose to stop helping a sub-user with peer discovery and to stop providing software updates to them. But if a sub-user is not content with the service their parent is providing, and/or they feel like they were unjustly blocked, they are free to find a parent that wants to adopt them.

So it's not true that Tlon can't just say $user's compute node is hereby expelled? Because my initial understanding was that Yarvin implemented instead of Galaxies/Stars/Planets, it was Dukes/Generals/Earls, and his compute node was the unique role of "Prince" - with the ability to expel anyone he saw fit.

> Doesn't this apply to pretty much anything happening in the decentralization and crypto spaces right now?

Indeed.. But that's a whole other ball game there. And yes, some of the cryptocurrencies most certainly have their own very cult-like status and effects. But you and I digress. I'm only here speaking of Urbit.

Ideally, what I want is the following:

1. Provide first principles how the system works. Use standard topologies, algorithms, and other established analytical methods.

2. Disambiguate the coded words describing primitives in the language. If the VM is emulating a non-Von-Neumann architecture, discuss it!

3. Network Protocol analysis: these should be well documented and established. I'm guessing they're also written in Hoon, which means they're nigh unreadable and excludes any existing tooling.

4. Fully document and vet the mathematical principles in the implemented crypto. Because I dont trust black box systems - and yes, Hoon is most certainly "black box" for 99.99% of programmers.

I'm sure there's something in Urbit that isn't documented elsewhere, or a algorithm that the world outside Urbit hasn't seen. Im interested in seeing they get their rightful place as part of mathematical tools we all use. In that end, Urbit is a neat project.

But for the reasons I've highlighted, I believe it would be an error to put any sort of time in this system outside of a curiosity.