First of all, this is staggeringly brilliant. You should pay attention to it in the coming months. I am not sure if it's destined to be the future, but I sure as hell hope it is.
I had the privilege of interning at Tlon, the company working on Urbit's development, this summer. It owns most of the namespace (Personal cloud computer IP addresses, essentially.) and is where the architect of the system works full-time. They are funded, well enough, by VCs you know of. Urbit is not really launched yet though - We spent the summer doing a lot of work getting the network, file system, protocols, and application layer in "Industrial grade" shape, and I believe more of that is happening this fall.
Because the system is still unlaunched and the docs are being retooled, I imagine these pages are discombobulating. That's... expected. Urbit has a lot of odd ideas that take time to appreciate. However, if you do take the time to understand the motivation behind the design of everything from Hoon's appearance to the network protocol replacement for TCP to the vision for future social networks, you'll find some of the best and most complete computer science research done in decades in networks, systems, and functional programming. The essential idea is not an outlandish one - We need a new basis of computing and networking to build digital identities with, and 1970s system software is not up to the task.
It's unfortunate that ambition and a sense of humor can be misinterpreted as a joke today. For now, you'll just have to take my word for it [1] that these guys are deadly serious and have the technical chops to back up their ambition. Future documentation and applications built on the OS should soon make that more immediately evident.
[1] Or start reading the tutorials!
There are hundreds of lines of noise. This makes perl and forth look absurdly readable. What on earth do the directory and file names mean?
I dunno how familiar people on HN are but the original author of urbit is Mencius Moldbug, a neoreactionary blogger. His style of writing is absurdly obfuscated and purposely impenetrable if containing some interesting ideas. The exact same thing is true of urbit. Interesting ideas but obfuscated the point of utter inaccessibility.
Here's sort of the wider group of blogs he philosophically aligns with:
http://rationalwiki.org/w/images/d/d5/Scharlachs-visualizing...
His views are likely unpopular around here but I am a fan of a bunch of those other blogs, and I've tried to dive into Moldbug's blog Unqualified Reservations a few times. It's kind of insane—the guy is clearly very intelligent—yet writes in his own discursive style that is absolutely opaque.
Someone just emailed and pointed out that he couldn't check out Urbit on Windows, because it has a file con.c. Oh, right, reserved filenames. How are reserved words different? The difference is - you're used to them.
Also, perceived usability (while it matters for marketing) is not the same thing as actual usability. Actual usability is something you only find out when you try to actually use something. We have a good bit of experience inflicting the syntax on coders of various abilities and backgrounds, and we're pretty satisfied with the result.
It helps that the syntax is quite a bit more regular than it appears at first glance. It's much more regular than Perl, and it also comes with a vocalization model that makes it easy to say out loud.
For instance, "=+", which more or less declares a variable, is "tislus." A lot of things like "=+" also start with "=", ie, "tis." You wind up learning about a hundred of these digraphs or "runes," which is a lot less than, say, Chinese.
Speaking of Perl, have you heard - Larry Wall is a Christian? I don't think this makes Perl a Christian programming language, though.One of the joys of our engineering inheritance from the 20th century, which was really humanity's golden age of political insanity, is that we get to stand on the shoulders of loons. We fly Christian astronauts into space on Nazi rockets programmed by Communist physicists. And it works...
http://www.thebaffler.com/blog/mouthbreathing-machiavellis/
It looks like he thinks that the benevolent-dictator-for-life model is how countries should be run. And Peter Thiel seems to agree with him.
++ lax :: lax:as:go
|_ [her=ship dur=dore] :: per client
++ cluy :: cluy:lax:as:go
^- [p=life q=gens r=acru] :: client crypto
?~ lew.wod.dur !!
?. =(fak.ton r.i.lew.wod.dur) ~|([%client-wrong-fake her] !!)
:+ p.p.q.i.lew.wod.dur
q.q.i.lew.wod.dur
(haul r.q.i.lew.wod.dur)
::It is, believe it not, designed with readability as a first-class priority. However, a common meme in language design today is that "Code should read like prose." This sounds good, because it means languages are easy to learn. Who wants to learn a bunch of symbols and patterns and junk? I want to code (Python, JavaScript, etc.) now!
But when we program, we aren't dealing with the trivial knowledge English is efficient at exchanging in an email, or the subtly it portrays in a novel. We are talking to a computer. The ideas we explain to a computer are often much more complex than we can explain precisely with English in any reasonable amount of time, so complex we often lose ourselves in them.
Mathematicians and physicists gave up on making human language explain specific technical ideas long ago. Have you ever read a paper on cosmic topology or quantum field theory? There's a comforting padded bumper of English framing the ideas, but the reason the paper is published is in symbols which would appear to the uninitiated as "hundreds of lines of noise." The English is usually just an introduction.
I think Hoon is wonderful [1] because it has both power and predictability. Power lets you express complex ideas concisely and easily, while predictability lets you read and understand someone else's code without frustration. Perl is powerful because it's dense, but it does so at the cost of predictably. Mathematics symbols are terribly powerful, but wildly unpredictable [2]. Python is sort of powerful and sort of predictable. The seductiveness of English simulacra programming languages is that you often don't realize how much power you're giving up because it's just so relaxing to not think about symbols and patterns when your code has the predictability of an email.
Hoon's power is in the zoology of runes (Digraphs) and it's predictability is rooted in its homoiconicity. Every symbol on the keyboard is utilized to build powerful runes, each of which in turn is utilized to append predictable structure onto your AST. When you understand the basic patterns of these constructions and reductions, it's not hard to read someone else's library and understand it in an afternoon. I can't say the same for the Java SDKs I come across. [3]
I'm not saying it isn't inaccessible at first and doesn't take time to learn. I am saying it is worth it.
[1] It's my favorite language - It is just plain fun.
[2] That's why the English frame around a physics paper is there - It tells you what each symbol represents in this paper and what they're trying to do.
[3] The language design also includes several decisions to avoid the pratfalls of other homoiconic languages (Primarily the readability of Lisp), but those are explained in the docs.
Of course, Kloc is a deceptive measure of algorithmic simplicity in a functional language, if compared to procedural. Also there is about another 15Kloc of C in the interpreter and another 10K that wraps an event layer on libuv.
Bear in mind that Urbit can also be seen as an ACID database on the log-and-snapshot principle - events are transactions. You can of course export application state to some other storage system, but you don't have to. (If you change the source code, your app reloads - you do have to write a function that maps your old state to your new state, though.) So there is a lot of strange futzing around with mmap at the bottom.
1. A new computing model, similar to how combinators work.
2. A programming language which produces expressions involving these combinators.
3. An operating system built on the above.
4. A cloud computing environment built on the above.
Sorry, but while interesting, this sounds a little too ambitious, even by HN standards :)
Sounds like a 10-year research project, right? Actually I started working on Urbit in 2002, as a sort of "unsupervised PhD thesis." I figured it'd be done by 2008 or so.
We seeded a startup last fall and are busy turning a prototype into a product. You can now write a pretty decent web app in Urbit, but it's still too raw to stand the light of day. For instance, the network works, but we often run global flag days when we shut the whole planet down and change the protocol.
One of the main problems with Urbit is that extraordinary claims demand extraordinary evidence. If you're going to ship something this crazy, it has to work extremely well right out of the box. We had a sort of abortive non-launch last year when the project kind of got accidentally leaked, and decided we had to "unlaunch" and go back into quiet mode. I hate selling things I can't quite deliver.
http://doc.urbit.org/doc/hoon/tut/1/
Reading this feels a lot like dropping acid.
That being said, I'm curious what will come out of this.
There's code that you can run and can play with. It may sound super far fetched (and it is), but the guy behind it is putting sweat into it.
For example, Haskell and GHC took decades to become what they are now (a powerful language and compiler). It seems quite wasteful to rebuild that work. If absolutely desired, Haskell can also be converted into combinator form, and vice versa, so why not use it? Seriously.
There is one ground truth, origin, fixed point like the North Star: zero. There are an infinite number of possible falsehoods: all nonzero numbers. But Urbit chooses 1 as the canonical false.
"As you may remember, to decrement 'a' we need to count up to it."
However, years later I was introduced to boolean algebra, where 1 should be true and 0 — false, if we want multiplication to be "and" and addition "or". And it feels right, because intersection of two sets is (intuitively) multiplication, and joining — addition.
So, yeah, it doesn't seem like a good idea to me as well after all these years.
If you look at where lambda comes from, it comes out of this same project of metamathematics that originates in the 19th century with people like Frege - how do you describe math in terms of math? Then it was discovered that this project could be repurposed as a definition of computing. Reusing old standards is a thing that happens, but sometimes you'd come up with a different approach if you were starting from scratch. As I've pointed out elsewhere on this thread, the shared theoretical foundation of lambda does not lead to a family of languages that are compatible in any meaningful sense.
It was probably a bad decision to make 0 true and 1 false, but not for mathematical reasons. There is always a lot of C coupled to Urbit, and what ends up happening is that the easiest way to handle this problem is to write C in a sort of dialect in which 0 is true and 1 is false. This is slightly cumbersome, and the perceived elegance of 0 == true isn't at all worth it. However, it's also nowhere near awful enough to revisit the question, which would be quite tricky considering the self-compiling nature of the system!
For instance, if you've got anything like regular expressions, then you've got something with a structure where the "unit" (trivial match) is an identity for sequencing, and the "zero" (failed match) is an identity for disjunction and a zero for sequencing. It's not exactly a formal argument for preferring booleans to loobeans, but a failed regex match sure feels like a "false" to me.
I don't doubt that it's not worth changing at this point, but don't throw the semiring baby out with the lambda bathwater.
S: λxyz.xz(yz)
K: λxy.x
I: λx.x
From there, you can express anything from the lambda calculus, and vice-versa. So I think it's reasonable to say that Nock is just a machine-friendly way of expressing the lambda calculus.
SKI is obviously a lot simpler mathematically, but I wouldn't want to try to use it as a compiler target...
You can go simpler still: Iota.
What do people expect when they read a thing like that? I don't know about you, bit I'd expect that I could ignore the obfuscated strangeness of their higher level languages etc and just implement stuff to that minimal spec.
So you expect you can do that. But you can't. That minimal spec might as well not exist; you can't just read it and go on to implement, say, a programming language on top of Urbit.
"But you can!" you might object. Try it. Read nothing but that spec and implement, say, a tiny BASIC on top of it. Compile some simple programs. Run them. Now, what happens? Nothing, for now. But look, my processor core is heating up. Something must be happening! Just wait. Wait. Wait. No, still nothing. Wait some more. Just a few years, maybe? No, still nothing (except heat). Etc.
So no, that elegant spec doesn't give you anything but a way to heat your computing cabinet.
Realizing this, I put Urbit in the "suspicious, may be a con" bin. Hasn't escaped from there, yet.
Last I read something like this (I don't know if it was about Urbit or something else), it turned out that there was no IO included in that spec. So, useless for any real-world purpose, and as you said, insincere.
Urbit is not meant to replace Unix. "They call us, we don't call them" is the fundamental precept in play here. I assure you there is I/O in Urbit, the vanes include an HTTP server, a Hoon-interpreting shell which accepts keyboard input from a terminal, and a UDP layer for facilitating ship-to-ship communications. All of that is written in Hoon, which compiles into Nock.
So you hook up your new Nock back end to your favorite compiler, painstakingly hand-crafted to generate Nock code perfectly conforming to the T-shirt spec. You compile a few programs. You run them. Heat radiates from the CPU... and nothing else happens. You wait, patiently at first, then way beyond patience, yet nothing (except heat). Don't you feel cheated, just a little?
The 25-lines-of-obfuscated-C interpreter is on the very shirt that I wear on my (clickable) homepage picture.
Can you explain what the actual problem is? "Only X lines of code" puffery is endemic in programming so I'm not sure why Urbit should be singled out.
If the spec expands does the guy wearing the t-shirt have to eat lots of pizza?
I like this article which introduces it:
Urbit is perhaps how you'd do computing in a post-singularity world, where computational speed and bandwidth are infinite, and what's valuable is security, trust, creativity, and collaboration. It's essentially a combination of a programming language, OS, virtual machine, social network, and digital identity platform.
http://alexkrupp.typepad.com/sensemaking/2013/12/a-brief-int...
What I'd say is that Urbit is not designed to be a darknet. It is not Tor and it's not Bitcoin. Also, it is not designed for external governments, or even its mysterious and sketchy founders, to govern - it is designed to govern itself. (Through user-level reputation mechanisms which have yet to be built, but are relatively easy to build - because the limited supply of identities controls Sybil attacks.)
In particular, Urbit should be quite good at enabling anonymous free speech beyond the reach of governments. A self-hosted node in your closet is quite practical and effective. There is no anonymization / onion routing (and you can't trivially route Urbit over Tor, because Urbit uses UDP), but someone could build that.
Although I don't want them to. I want to enable anonymous, or better yet pseudonymous, free speech. I don't want to help people buy drug$ or childpron through the mail. Fortunately or unfortunately, there are already much better tools for that.
if no, you're gonna experience even weirder things
I've been watching this since it's started. It has some magical atmosphere around it and you never now whether it's serious or not; whether it's a real technical project or some kind of artistic performance.
I think I have a destroyer somewhere.
Frankly, I'm disappointed. It used to be clearly the personal work of a lunatic. Now it feels more like a quirky open source project.
I'm looking for a virtual machine (or NaCl-like sandbox) which does this.
Edit: To anyone who downvoted me, could you please let me know why?
"While nowhere near the simplest such automaton known, and certainly not of any theoretical interest, Nock is so stupid that if you gzip the spec, it's only 374 bytes. Nock's only arithmetic operation is increment. So decrement is an O(n), operation; add is O(m * n)... "
Don't they mean 'subtraction' rather than 'add'?
edit: This is so fascinating, it has me totally enthralled. Think smalltalk meets lisp meets some wild eyed programmer who knows just how to appeal to the general frustration most programmers should have (do they?) about the state of our art.
Best post on HN in a long time, very curious how this one will turn out in the long term. May all your ships come in ;)
edit2:
Digging around a bit more: Peter Thiel and a bunch of others have apparently invested in this through a vehicle called 'Tion', https://angel.co/tlon (the Thiel reference is that Thiel backed John Burnham, who is co-founder in Tion).
EDIT: It seems they are going for a naive implementation where subtract just repeatedly calls decrement, so yes, that's going to be O(m*n).
It is a reference to something out of Jorge Luis Borges
In fact it reminds me about a massive book on cellular automation that I once picked up, which went to incredible length in interpreting the potential of dynamic patterns in 2D space. It was a monument to extreme intellectual rigour and dedication, if nothing else. If only I could remember the title.
Basically, it can't run out of address space because of the abundance of subs.
And somehow makes it even more magical than when you read the docs.
But I'm not sure that's necessarily the aim. As I understand the project's aims (and I'm not involved, I just read all the docs a few months back), it's more important that the Internet of the future is not a tangled mess of technologies that are insecure on different layers. Then it doesn't matter so what OS people's local machines are running.
I hope the essay at the URL below is still relevant, it seems to describe the aims rather well. "The result: Martian code, as we know it today. Not enormous and horrible - tiny and diamond-perfect."
http://moronlab.blogspot.co.uk/2010/01/urbit-functional-prog...
My brain did not enjoy any wall of text that much since I read the bitcoin whitepaper. Now I want to learn more and be up to date.
"or even readline - this is not readline, it's internal to Arvo"
1: http://xahlee.info/comp/Ryan_Dahl_on_software_complexity.htm...
LibUV: https://github.com/joyent/libuv/graphs/contributors Re2: https://code.google.com/p/re2/source/list
I doubt very much that the average person wants to either fly their own airplane or manage their own cloud computers, no matter how simple you try to make either of them.
You don't think the average person would want to fly their own airplane if it were as easy as driving a car?
And the amount of possible simplicity is constrained by the problem you're trying to solve -- you can't manage to make a plane as simple as driving a car, because the car only has to navigate in two dimensions while the plane has to navigate in three. If a car stops, the car's just sitting there, whereas if a plane stops gravity is going to pull you down in a likely to be fatal incident. You can't make a plane as simple to use as a car without changing it into something other than a plane.
Most people don't enjoy driving. Presumably (for most people) flying would be just like driving - exciting, interesting, and liberating at first, but would eventually become a dull and boring chore.
Do you mean the webshell, or the templating markup language? There is something you might want to look at called "Sail"
Having trouble finding you a link, but there are some mentions about it here:
https://github.com/urbit/urbit/search?utf8=✓&q=sail
Ah..
https://github.com/urbit/urbit/blob/master/urb/zod/main/pub/...
What we're brewing in the lab has diverged quite a bit from what's publicly available. Even these docs are quite out of date.
If you're interested in keeping up with what we're doing: either sign up at http://urbit.org or send me an email, galen at tlon.io.
"It's definitely air travel. It's not exactly flying."
This phrase has an Alan Kay-ish quality, and was enough to pique my interest. Anyone seriously trying to execute on a project that addresses this concern seems worth following. Who knows, you might even succeed :)
i find it an interesting exercise to explain to non-technical folks that i have several virtual computers running in the cloud. .. looks on their faces says it all.
This seems crazy ambitious on its own, and add to it that it's public domain. Very curious where this will be headed.
That said, the more I read about it (a couple of hours so far) the more I'm thinking it will not succeed because of some of the weirder philosophical decisions that have already been cast in stone.
It's basically a variation on the 'landgrab' theme. Think bitcoin or the domain name system with half the space grabbed up by the ruling corporation, with an arbitrary 'ingroup' and a very large 'outgroup'.
You'd think that by now the whole point the web rammed home with its unbridled success is that open is better but I guess the mobile walled gardens have whetted the appetite of future wannabe corporate overlords.
Anyway, I still wish them best of luck, that's an economic move on my part, it costs nothing and I suspect they are self limiting enough that it will not achieve the world domination they are dreaming of. See also: the singularity.
The difference is simply that while there are a limited number of Urbit identities (or at least memorable identities, ie, 32-bit "destroyers") in the world, and therefore they can't possibly be made free as in beer, neither I nor my evil minions have any practical power over a destroyer once we create it.
Moreover, if you genuinely think of any individual or organization involved with Urbit as evil, there are plenty of independent carrier-holders you can get a destroyer from. (~del, for instance, will ship destroyers when we do, I think. He's some guy in Rochester whom I don't know from Adam. So, we'll let him serve the first 16 million people who want to escape from our evil dictatorship.)
Yes, by default the normal way to get onto Urbit will feel like the normal way to get onto Facebook. However, even if you are initially issued and hosted by us, you can move your image at any time to any other host, or to your own machine. Currently there's no way to stop using your issuing carrier for network services, such as firewall hole punching, but this is obviously a 1.0 feature. By design, there is no sort of leverage you can't escape from.
So Urbit strikes a sort of balance between governed and ungoverned networks. The limited address space will hopefully make it economically impractical to abuse the network for profit - a spammer is always a Sybil attacker. But as a destroyer you are not ruled by any master you can't easily escape from. The only thing you can't escape is your own reputation. Which you shouldn't be able to escape from.
We should probably highlight this difference a little more in the doc...
[1] http://www.forbes.com/sites/kashmirhill/2014/04/08/beyond-bi...
[2] https://github.com/maidsafe/MaidSafe/wiki/unpublished_papers...
>We use so many of these ASCII glyphs that we like to be able to read them out loud. A language is meant to be said.
That's a very weird idea there. A painting is a form of language, but can a painting be said?
I suppose if you use a very broad definition of language, that might be true, but in the sense of natural languages, paintings are not generally a form of language. They may be a form of symbolic expression, but that doesn't make them a language.
The long and the short is, there are carriers (I have one), who are enumerated in the source code (like by public keys) and they are not dependant on each other, except for the sake of being able to route to child ships. So if ~zod is down, and everyone depends on ~zod, the network is indeed hosed. Everyone with active links can continue talking to each other, but nobody new can find anyone, and nobody can find anyone new. Every ship depends on a carrier for routing.
By convention, every time you launch from your pier, you get a new random port number and any ship that was looking for you at your old address needs to hear about your new address from a higher-up ship.
So it is distributed, but finitely distributed. There are only 256 carriers allowed, and they are the only ships that are really independent. Though there has been talk about fleshing out how ships can be separable from their "sein" domain, or parent ships, currently almost everyone is from the same lineage and thus depends on the same pair of servers for pretty much everything regarding the network.
This "centralized" design is indeed a core feature of the network, and it even relies on DNS to be bootstrapped, another centralized system. Now, can you show me a decentralized system that doesn't need any of that? I don't know exactly how magnet links or tor, or freenet work, but I am skeptical that they are honestly less centralized than this when it comes to bootstrapping.
> The first time a client joints the DHT network it generates a random 160-bit ID from the same space as infohashes, and then bootstraps its connection to the DHT network using hard-coded addresses of clients controlled by the client developer.
This sounds really quite like the process of creating a submarine, and reaching out to the carrier ~zod. The fact that the init process is hardcoded to trust ~zod doesn't change that you can really init your ship's filesystem from any other ship, provided you can reach it.
Carriers are all found through the existing DNS infrastructure. Other ships are able to be reached "in-band" by asking a carrier for an introduction. Without this seed or hardcoded list (or by conducting a brute-force search), or some kind of broadcast mechanism, bootstrapping a distributed network is not actually possible.
I mean, this http://doc.urbit.org/doc/hoon/tut/1/ is supposed to be a "tutorial" but it's definitely not what anyone else would call a "tutorial". It's more like a "philosophical introduction" to a PhD paper, which would be ok if labeled as such. A tutorial should be about "how do I do X using Y, without bothering to really understand Y" because this is what a tutorial is about, a "mostly wrong" "mental shortcut" that you take in order to gain some kind of "feel for how something works" before actually delving deeper and reading up on the theory.
Our documentation has advanced since this was posted. I'd be interested to talk more out of band, but can't find your email. If you're up for it I'm galen at tlon.io.
Especially this part: > Shapiro also discovered that the group had been working together so long it had developed a kind of private slang. It took months to comprehend what the programmers were talking about. Most of them were book lovers and trivia mongers who enjoyed developing a metaphor based on obscure sources and extending it via even more unlikely combinations. For instance, the object in the Xanadu system that resembled a file was called a bert, after Bertrand Russell. With files called bert, there had to be something called an ernie, and so in the Xanadu publishing system, an ernie was the unit of information for which users would be billed. To understand the details of Xanadu, Shapiro had to learn not only the names for things, but also the history of how those names had come to be.
[1] http://archive.wired.com/wired/archive/3.06/xanadu_pr.html
[0] http://moronlab.blogspot.co.uk/2010/01/moron-lab-goals-princ...
http://unqualified-reservations.blogspot.com/
Note: I myself am unconvinced by his writings, and find him to be just another ironic instance of the ironic nature of American culture, eager to avoid the appearance of naivete by abandoning all hopes that are fragile. Do with that what you will.
Or, something.
This reminds me of the Newton-Liebniz debate on creation.
Personally, I'd rather see the use of some of the new made up neutral pronouns than thinking swapping male to female pronouns is a viable long-term solution.
Although, I read this:
"A pier is an Urbit virtual machine that hosts one or more Urbit identities, or ships. When you run bin/vere -c, it automatically creates a 128-bit ship, or submarine. Your name (a hash of a randomly-generated public key) will look something like:
~machec-binnev-dordeb-sogduc--dosmul-sarrum-faplec-nidted,...
and I laughed. A lot.
Really well done, though!
http://alexkrupp.typepad.com/sensemaking/2013/12/a-brief-int...
BTW - re Hoon ...a reference to the sea faring settlers in Brin's uplift series?