It has the cult-like approach of Xanadu - use new terminology, tie it to an economic model, and re-invent everything. Also, there seems to be a cult leader.
Jargon: noun (data), nock (interpreter), mint (compiler), span (type), twig (expression), gate (function), mold (constructor), core (object), mark (protocol). It's Newspeak for programmers.
The overall concept seems to be a federated social system, like Diaspora. Everybody has a online presence which they own. But you can take your ball and go home, moving your online presence somewhere else, and it still gets found by others. Somehow. (That's a hard problem at scale.)
There's a claim that nobody can create vast numbers of identities for spam purposes because there are only 2^32 possible human identities. (That number should have been at least as big as the population of the planet. 2^36, maybe.) Apparently you have to buy address space, which is a profit center for somebody.
There's a download, which gets you their "OS" (which runs on top of another OS), an interpreter for their Hoon language and access to their chat environment.
Not sure what to think of this, but someone put in a lot of work.
Bignums themselves are somewhat expensive data structures to pass around, so runtimes that use them usually don't use them for everything; instead, they have an Integer type that has Bignum (data-structure on the stack, or pointer to data structure on the heap) and Fixnum (regular integer machine-register) implementations, and write a glue layer to treat the two interchangeably.
So, you've got a runtime where your only "type" is an integer, but it breaks down into "cheap integers" and "expensive integers."
Now, in most dynamic-language runtimes (i.e. runtimes where type-tagging and pattern-matching doesn't all happen at compile-time), you want a type that "represents itself" to use for type-tagging, dictionary keys, function references, etc. This is usually a Symbol or Interned String (or Atom!) type, with the runtime keeping a symbol table mapping fixnums ('cheap integers') to strings (which are effectively, in Nock, 'expensive integers'). You need this table, because dynamic language functions manipulate/build/pass around/compare a lot of symbols, and the interpreter would be really slow if you were passing and comparing 'expensive integers' by value.
But Nock can't really keep a symbol-table, because every "atom" ID embedded in a Nock program is a universal ID, a handle any other Nock runtime might be passed and attempt to manipulate. (And you can't even use a global symbol-table that uses hashing—i.e. a DHT—because Nock doesn't differentiate the "Symbol" atoms from any other atoms, so you'd have to treat every atom the same and hash them all—and, even pretending that's cheap, you're eventually going to get collisions that way.) The only symbol table that works in a globally-distributed system is one that maps bitstrings to themselves. And that's as good as no symbol table at all.
So what do you do when you can't make your strings ('expensive integers') into interned strings ('cheap integers')? Just use the cheap integers from the start! In Nock, this means that all the runtime-defined symbols—all the atoms in the language and the stdlib—are bitstrings that are short enough to be encoded directly as fixnums. Since Nock has the requirement of running on 32-bit machines, that means 32-bit bitstrings: four-ASCII-character strings. Thus most of the jargon.
Do note, it's not required to use four-letter names for "symbols" you manipulate in the Nock runtime; but doing otherwise means passing around 'expensive' handles instead of 'cheap' ones.
---
I find Urbit's solution here interesting—but they probably chose it for purity's sake.
I would like to contrast it to the implementation in Erlang's BEAM runtime (which also, coincidentally, has 'atoms', but where these are simply its particular symbol type):
• an atom table is kept by each "node", with no need for the atoms in each node to have identical mappings;
• atom IDs are mapped back to their original bitstrings when serializing any data structure including them, even if just for internal persistence;
• each distributed-RPC connection between nodes is stateful, keeping its own atom table (kept synchronized on both sides by additional messages) as a cache to speed up communication between nodes. This can be seen to be similar to a streaming compression algorithm's Huffman tree cache, but it's interesting to look at it as the connection being its own virtual 'node' that has this particular atom table, which both nodes are then modelling and translating to/from.
Addresses can actually be up to 128-bit. I think the idea is that addresses longer than 32-bit are just assumed to be bots, but that convention would probably be changed if Urbit gets popular enough for the 32-bit limit to matter.
I'm trying to think of a 32-bit address space that was found to be too small... I know there was one, it's on the tip of my tongue...
No, it's much uglier than Newspeak.[0]
> Urbit is a new programming and execution environment designed from scratch. Any resemblance to existing languages or operating systems is coincidental, cosmetic, or inevitable.
It was based on this idea: suppose that a different civilization (Martians specifically) had invented computing long before humans. Then by now they would have perfected it. What would their system look like? Urbit is an attempt to rethink computing without the bias of human research and our current intuition. At the heart of Urbit is Nock, a “functional assembly language”. Zero is intentionally used to denote “true” to defy programmer intuition.
[1]: https://moronlab.blogspot.com/2010/01/urbit-functional-progr... [2]: https://github.com/cgyarvin/urbit/blob/master/doc/book/0-int...
OK, that was just perverse. Except check out the latest iteration of point of sale credit card terminal keypads. "0" is Yes and "X" is no.
https://www.reddit.com/r/urbit/comments/4okcm6/were_the_core...
There are more interesting insights in that thread about Urbit’s unorthodox decisions.
It's not a terrible idea. In most types of computing there's often only one way for something to be true but N ways for it to be false.
The C language and the standard library are distinct things. C originally did not define any values at all for booleans (true / false), but later implementations did and even in the oldest C compilers (0 == 0) would evaluate to '1', which caused the most repeated lines of C preprocessor input ever written:
#define TRUE 1 #define FALSE 0
Guarded by some #ifdefs if your compiler supported that.
Some standard library functions return nonzero on error (which can be < 0 or > 0), zero on 'success' which is not the same as true, and others (annoyingly) return 1 on 'success' or 'true' (such as the isalpha function/macro).
This is all apparently very novel.
* Everything on the VM is purely functional, and inputs essentially cause transactions which can fail/succeed - the result being that it's supposedly easier to implement certain types of network protocols, specifically the ones that Ames implements
* A somewhat decent revision-controlled filesystem with push/pull/merge, static typing of files, and a built-in build system of sorts
And last but not least...
* Feudalism built into the core p2p protocol as an explicit design decision
But joking aside, about a month ago this well-articulated writeup was posted on their site: https://urbit.org/posts/overview/
There was an HN thread on it: https://news.ycombinator.com/item?id=11817721
The gist is it's some sort of distributed datastore network vaguely similar to IPFS [1], Freenet [2], but instead operates at a different level of abstraction from files. It ships with several other components, like an OS and a programming language, to flesh out that ecosystem.
A core axiom of Moldbug's philosophy is that the mathematicalization of computing is an elitist conspiracy. As an example, he thinks that the lambda calculus is intrinsically mathematical, hence elitist, whereas his own concatenative language is non-mathematical, hence non-elitist, by conforming to human nature. It's bizarre to say the least given that his proposed language has an obvious relationship to combinator calculi like SKI calculus, and you'll have to look long and hard to find anyone who thinks the SKI calculus is more intuitive than the lambda calculus.
I'm jumping through the hoops of "Debianizing" something now, and I have to say the Debian project uses similar techniques to limit participation to the committed. The Debian packaging guidelines are very arcane and the docs are kind of scattered and the whole "experience" seems (probably unintentionally) built to keep casual "spam" out of the repo. Not necessarily a bad thing.
[1] /s
[0] Extra-Obfuscated Perl-Lisp
https://popehat.com/2013/12/06/nock-hoon-etc-for-non-vulcans...
http://reddragdiva.tumblr.com/post/141832812938/argumate-all...
The real reason is probably to generate some buzz for Bitcoin, because some of the valley nouveau riche like to gamble and have long positions.