The world is moving to cloud computing – which means that the world is moving to giant megacorps that are excessively cozy with the government owning all your data.
Which, as general David Petraeus discovered, can be really bad for you. Google tipped off his enemies, not by reading his email, though they did read his email, but by tracking where he was when he logged in to gmail. Which is why Hillary likes to keep her email server’s database on a thumb drive that she personally controls. Supposedly this is bad for national security, but I am pretty sure it is mighty good for Hillary’s security.
Urbit is intended to fix this:
Your urbit is a personal server: a persistent virtual computer in the cloud that you own, trust, and control.
Unfortunately urbit is also a language, a rather weird language, and a language that is interpreted rather than compiled.
A compiler can compile itself, and usually does. An interpreter cannot interpret itself.
Urbit, as a language, is kind of like Haskell as a language.  Except that Haskell has a compiler, which is a huge advantage.
Let us suppose you want to multiply two times three in Haskell:
Well if you multiply two by three in C++, the compiler generates code that loads the number two into a register, loads the the number three into another register, multiplies the registers together, then stores the result where you tell it to store it.
If you multiply two by three in Haskell, the interpreter first creates a function to multiply any number by two, then applies that function to the number three, and it does not store the result. Which means if you have any non trivial program, it is pretty hard to figure out what the program is actually doing and how much time and memory space the task is going to take. Except that you can be pretty sure it is going to take more time and more memory space than doing it in C++.
Does anyone actually use anything written in Haskell? All alleged successful uses of Haskell are in-house usages – the man who uses the program is the man who wrote the program.  We don’t see someone writing something in Haskell, and then large numbers of other people using his software. If you google any standard language, you get lots of hits of people wrestling with vast amounts of data used by vast numbers of people. If you google functional languages, you get academics playing interesting and clever games for the entertainment of other academics.
I rather suspect that no one except Yarvin is likely to be able to write any large efficient program in Urbit.
In order for Urbit “your personal server on the cloud” to be useful, your personal server needs to provide tools that are the functional equivalent of blogging, tweeting, reddit, facebook, Github, email, the pirate bay, the silk road, ebay, and such. Tools whereby you can use your personal server to securely interact with other people.
Not seeing specs for such tools.  Such tools seem like a lot of work.
The huge advantage of a language such as Urbit is that the cloud is inherently massively parallel, and Urbit is designed to be inherently adapted to massive parallelism. Your personal server on the cloud can scale – enormously. Which is more of an advantage if you are a giant corporation. And even so, giant corporations do not use such languages, because they are hard.
Something like Urbit is the right way to do things in a massively networked environment. But it is an enormous and difficult task. Writing a compiler would not be such a big job compared to all the other jobs that have to be done to make Urbit useful.
Urbit is a bright idea. It is a correct idea. But it is a really big job.
@Does anyone actually use anything written in Haskell?
haskell itself? i’m under the impression it’s mostly written in itself like lisps usually are.
more seriously, we’re stuck with posix/windows, c/c++, on x86 for, probably ever. certainly a premature optimization, but it’s soldily ingrained.
no way in hell urbit, or anything else dislodges it anytime soon.
http://www.paulgraham.com/icad.html
Paul Graham answers your question here; Orbitz was based on Lisp, the original functional language. Whenever a competitor added a new feature, Orbitz had the same feature two days later.
Functional languages grow seamlessly as you add more functions (that is, there’s no clear boundary between “the language” and “your additions thereto”), but it’s not easy to hand off such a program to another person.
If your IQ is less than 150, you’re probably better off to stick with procedural languages.
» Functional languages grow seamlessly as you add more functions (that is, there’s no clear boundary between “the language†and “your additions theretoâ€)
does that mean operator overloading, or something like tail recursion instead of iteration that I’m too stupid to understand?
It means Lisp macros, which basically allow you to write your own language, and most people programming in Lisp tend to do that.
every large program is written in its own language of specialized library functions and datatypes
Lisp macros are executed at compile time or read time, which is different.
That’s an interesting point.
From observation, large programs in (old-school) Java – which is a language designed to not let you write code that is hard to read by others – do not give rise to domain-specific languages in the same way large programs in Lisp do.
But I’m having trouble articulating why this is so. In principle, specialized library functions and data types are, indeed, a domain-specific language.
It’s probably a combination of compile-time metaprogramming, higher order functions, generic functions and types, flexible syntax, and 150+IQ programmers.
if you’ve written enough javascript, you’ve probably written code to write javascript, since javascript is missing so much. but c++ has good enough types that it’s better to use what’s already there instead of doing it yourself
lisp lets you write code that writes code easier than other languages, but it’s also annoying to write
whenever i hear someone talking about functional programming, i imagine a nazi with well shined jackboots, a crisp armband, and an IQ of 115 talking about the glorious future in which all programs are lisp and loopink, printink, and assignink sind verboten
lol.
look, haskell is cool but it’s kind of a clusterfrak. lisp isn’t a language, but it’s fundamentally the highest paradigm that has ever graced computer “scienceâ€, courtesy of the greatest computer nerd who has ever lived and died under our fair sun.
obviously macros are to be used as sparingly as possible. which is fine, because the genius of lisp to the end user is not that lisp can be easily written in lisp, but that you can loop with a tail call and you write a tenth as much code to do the same thing and it all fits on your screen.
there’s no way paul graham has an iq of 150.
Looping by tail call is apt to be unintelligible.
it’s the 21st century, gramps
(loop [i 0]
(when (< i 10000)
(if (= (mod i 101) 0)
(print i " "))
(recur (inc i))))
This seems to demonstrate my point – that when a loop is expressed as tail recursion, it tends to be unintelligible.
You are coding a loop in a language that is hostile to procedural code, instead of the compiler coding it for you as a loop.
fill in the indentation yourself
if you find lisp unintelligible then any lisp will be unintelligible
(defn ??? [n k]
(if (and (> n 0) (> k 0))
(recur k (mod n k))
(if (> n 0) n (max n k))))
what is this function doing?
Nothing at all, other than cause the interpreter to abort.
You may have intended to write
defun. You may be writing in a specific dialog of lisp, clojure, whose user community and supporting environments are even less than for common lisp. If so, try using common lisp, as just about everyone using lisp does these days.Now you will undoubtedly explain that actually trying your code in a standard lisp interpreter was beneath your lordly intellect.
While you are berating me for my inability to comprehend what code that does not run would do if it actually did run, explain the reasons for the this actually useful and in use code, which compiles on every C++ compiler that supports C++11 and higher, which is every compiler in common use in every mainstream environment: What is it doing and why is it doing it?
In the third template function, why
decltype(std::declval().blob[0] What is the end purpose and useful effect of this code fragment? How does it get used to give effect to the intent? It is in the signature of iserialize, but cannot have any effect on the signature. How does it affect what gets done at run time by the low level bit bashing code? What is this idiom? If you toss around the name of the idiom, people will be more impressed that than by tossing around the idiom “tail recursion” in a context where you obviously do not comprehend what tail recursion is or why it matters.ironically, that code doesn’t compile
but this is the sort of thing that happens when you try to hire yourself
“lisp lets you write code that writes code easier than other languages, but it’s also annoying to write”
Good thing that Hoon is a considerable improvement.
Why urbit is the wrong idea: urbit was designed to never delete anything, and to make it very obvious to everyone exactly who is saying what. That’s bad for my security.
No it’s not designed to make it very obvious to everyone who is saying what.
And I’m glad Jim changed his mind from post title to last paragraph. Bravo Jimbo.
you wouldn’t run an interpreter in an interpreter because performance would be poor. it would run. so essentially correct – good compilers are important. if urbit’s interpreter lacks an ‘eval’ like, that’s probably for security. is the language less than turing-complete?
Is such a thing really a requirement? As opposed to, say, new roads and bridges? I have my doubts.
Urbit is bits, roads/bridges are atoms. Atoms are heavily regulated, bits are not (yet.) Smart people can innovate in bits, not in atoms.
The graphic is still probably relevant:
https://s-media-cache-ak0.pinimg.com/736x/b8/68/15/b8681575ee176ba12e4e514b5678f9f0.jpg
http://www.infoq.com/news/2015/04/web-frameworks-benchmark-2015
The technical stuff is above my head, but Moldbug said in a recent reddit interview that urbit is very likely going to eliminate lots and lots of jobs. Does anyone here have any idea as to how or why this would happen?
linux is 15 million lines of buggy, insecure code, mountains and mountains and mountains of technical debt. buffer overflows, buffer underflows, string format errors, time and date bugs, and did i mention undefined behaviors? so many undefined behaviors. no one person is capable of comprehending 15 million lines of code.
urbit is 50 thousand lines. it’s purely functional and side-effect free. signed integer overflow isn’t undefined behavior. a smart person can fully understand 50 thousand lines in a year or three. once complete it will never need to be updated.
nock uses 12 opcodes and will probably get its own processor architecture at some point.
at some point tlon will realize yarvin was trying to solve identity before facebook was trying to solve identity, but identity isn’t urbit’s killer app.
so-called Javascript Jockeys that are employed by many/most enterprises in order to provide websites/GUIs to internal and external users. They could all be replaced by urbit and a clean API. Just need a handful to create the GUI for the API to run on Urbit. The guy(s) making the API can stay to make APIs.
Urbit: The Deduplication of Development
I don’t think Urbit maps onto the underlying hardware very well. The whole “Jets” thing seems like a huge security hole. Smart idea, but the abstraction boundaries are in the wrong places.
Urbit reminds me of an old story. This is a story about a kid loved Broadway tunes, and wanted to be a composer to make fun, enjoyable music. So he went to Julliard, and they taught him 12-tone rows. He studied very hard, and they made him a professor. One day he sat down. Now! I am ready to start writing show-tunes, I know everything about writing music! He wrote his first show-tune. It came out sounding like a 12-tone row. I think this is what happened to Curtis. Too bad; I read what he had to say about Haskell, and Computer Science, and I agreed with all of it; Haskell is a giant boondoggle and Computer Science is a giant fraud.
I was too dumb to understand Lisp 20 years ago, so surely I’m too dumb to understand Urbit today.
But! I think it’s great-great-great that IQ-180’s have still SOME place where they can thrash and struggle to create something powerful and potentially revolutionary. A dindu-proof safe-space for the hyper-intelligent. I love that part.
It is surely no coincidence that all of NRx thought and analysis is coming out of computer geniuses. Not even rocket engineers. They’re too blue-collar, too hand-cuffed to the proletariat.
Nope! In the greater economy, computer work is the last safe space where they can bankroll themselves with relative impunity politically-speaking. I’m so glad that that well still has water in it.
To be honest it reminds me of Jews and banking/accounting, back in the day. They couldn’t own land and castles, but they could do that stuff all day long as long as they kept their heads down.
And considering this, my envy turns to worry. Computer work involves no blood nor soil. Perhaps computer work as Last Refuge for the Intellectually Superior is also a safe space for their degeneration, like the Jews without their Israel. I’m too dumb to know for sure.
“I’m too dumb to understand Urbit today.”
You’re in good company.
It’s actually quite extraordinary IMO.
It is. It’s also a bit alien. Probably from Mars.
http://moronlab.blogspot.bg/2010/01/urbit-functional-programming-from.html
The premise of the post appears to be in error. According to the whitepaper, Urbit is written in a functional language called Hoon, which is compiled to Urbit’s version of machine code, called Nock.
http://urbit.org/docs/theory/whitepaper
And how does this constitute an error in the post? What is the supposed premise of the post that this contradicts?
Nock is indeed interpreted in its current implementation (albeit not at all naively, and also assisted by jets), but does not in principle have to be (my hunch says it can be compiled to the machine code of major contemporary architectures quite well, actually). Hoon is definitely compiled (to Nock).
So instead of rolling out the tired (and ill-defined in general) interpreted/compiled dichotomy, it’s more correct to say that Urbit is designed to run on a (Nock) virtual machine. Think of Nock as sort of analogous to the JVM bytecode. Nobody today is seriously claiming that Java is “interpreted”, right?
The post says “urbit is also a language, a rather weird language, and a language that is interpreted rather than compiled,” but according to the whitepaper that language (properly called Hoon) is compiled, not interpreted.
Hoon is compiled to Nock, and Nock is the epitome of weirdness.
GWP
And… there’s nock. How did you come up with that, anyway, Curtis?
CY
Gosh, I barely even remember. I started with something much bigger and kept pulling things out. I guess.
GWP
Sort of the Kevin Herbert strategy?
CY
(laughs.) Kids, definitely don’t try this at home.
There’s a more fundamental case against Urbit, which is that it rests on a deceptive foundation.
Says the official description:
“Urbit is a clean-slate system software stack defined as a deterministic computer. An encrypted P2P network, %ames, runs on a functional operating system, Arvo, written in a strict, typed functional language, Hoon, which compiles itself to a combinator interpreter, Nock, whose spec gzips to 340 bytes.”
Let’s assume you don’t like “Hoon”. A rather realistic scenario, given that discussions of Urbit suggest that nobody likes “Hoon.”
But you can replace “Hoon” with something you like better and compile that to “Nock, whose spec gzips to 340 bytes”, right? Right?
No. It wouldn’t work. I leave the “why” as an exercise for the reader.
Likewise, you can’t un-gzip 340 bytes, turn that into your own “Nock, whose spec gzips to 340 bytes” and expect the rest of Urbit to work with it.
Given that Urbit at the very lowest level (the one easiest to check) is already deceptively misleading, why would anybody of sane mind put any trust into the highly obfuscated rest?
There is nothing deceptive about what you have described.
Update: More people got wise to it. Yarvin reacted:
> TLDR: all of computing is a hoax. You can’t compare a hoax to nothing. You can only compare it to all the other hoaxes.
Funny!
(http://urbit.org/posts/objections/)
OK, I get it.
Urbit is to software systems what Unqualified Reservations was to polemical discourse?
“An interpreter cannot interpret itself.”
Dead wrong!
https://scholar.google.com/scholar?hl=fr&q=%22self+interpreter%22&btnG=&lr=
Which does not in fact bring up a list of interpreters interpreting themselves.
Right, the authors of the 479 papers about various technicalities of self-interpreters were just drunk when they wrote their stuff, yet they managed to pass peer review. 😀
You can run an GBA emulator on your Android device that probably has an ARM processor.
Maybe you could modify that GBA emulator to run Android, and then run the GBA emulator in it.
Then you can write a paper about an interpreter of a language that runs in an interpreter of the same language.
Then you can get $$$, swag, and bitchez.
Then you can get shot when the thugly nazis take over, since they take a dim view of book learning.
Fabrice Bellard >> all.
http://bellard.org/jslinux/
“%ford does all its building and execution in the virtual Nock interpreter, mock. mock is a Nock interpreter written in Hoon, and of course executed in Nock. (See the implementation issues section for how this is practical.)”
The Hoon tutorial is the most untutorialish thing calling itself a tutorial I’ve ever seen.
“Well if you multiply two by three in C++, the compiler generates code that loads the number two into a register, loads the number three into another register, multiplies the registers together, then stores the result where you tell it to store it.”
Actually, the C++ compiler loads six in a register. This may seem like pedantry, but it isn’t.
Hoon (or perhaps just Nock, I’m not entirely sure on that point) on the language level does not have multiplication. It does not have addition. It has only increment by one. Decrement by one is O(N), done by a loop. To achieve reasonable performance, it relies on the optimizer detecting the ‘decrement’ loop and turning it into an actual decrement.
So the descriptions of how a non-optimizing C++ compiler works, and how a non-optimizing Haskell compiler works, are irrelevant; Hoon assumes optimizations or it would not work at all.
Yarvin actually states in a few places that Urbit is designed for today’s computers and technology and not those of the 70s, and the design decisions reflect that.
The problem is that it is not obvious to the person writing the code, what in fact is going to be done procedurally – which makes it difficult to write efficient code.
Similar to the problem with SQL. When your database gets complex, it is easy to write an SQL statement that will take until the end of time to execute, even though if written slightly differently, will execute in reasonable time.
And the differences between the SQL statement that will take till the end of time to execute, and the equivalent SQL statement that will execute in reasonable time, are seldom obvious.
That seems to me to be the least of the worries.
Urbit is basically a cult.
“A relatively small group of people having religious beliefs or practices regarded by others as strange or sinister.”
I’m fairly sure that none of us who have commented here understand Urbit, in whole or in part.
If you can read Hoon and then put in 20 hours of study, with prior CS knowledge, should understand the kernel and the message-passing well, though not the specifics of the vanes. “Lapidary” style with sparse comments makes it tough.
Whatever documentation they write quickly becomes outdated. I expect this to improve once they reach beta
I am sure I understand it in part.
I work full time on Urbit, I am not Curtis Yarvin, and I have written large portions of Urbit’s operating system, including its global, revision-controlled, typed filesystem. Urbit sure isn’t going to break any land speed records, but when my code is too slow, I almost always can speed it up with just a little bit of the usual optimization techniques. There’s nothing inherently slow about Urbit, though it is very unoptimized at the moment (premature optimization, yada yada).
As Lex Corvus points out, Hoon is, in fact, compiled to Nock bytecode. The Nock interpreter is written in C, of course.
> In order for Urbit “your personal server on the cloud†to be useful, your personal server needs to provide tools that are the functional equivalent of blogging, tweeting, reddit, facebook, Github, email, the pirate bay, the silk road, ebay, and such. Tools whereby you can use your personal server to securely interact with other people.
You understand Urbit’s goals very well, and you’re absolutely right about this, and it’s what we’re currently spending all our resources on. The tech is cool, but if we actually want to make the world a better place, it has to be useful.
> Something like Urbit is the right way to do things in a massively networked environment. But it is an enormous and difficult task. Writing a compiler would not be such a big job compared to all the other jobs that have to be done to make Urbit useful.
It’s a good thing the compiler has already been written, because the rest of the jobs are difficult, as you say. Fortunately, we’re an open source project (https://github.com/urbit/urbit), so anybody is welcome to help out on each of those individual projects. We’ll write as many as we can as a company, but we recognize that Urbit must succeed as an open source project first and foremost.
Say Phil,
How would you compare/contrast Urbit to Etherium?
They’re solving different problems, so aside from both being crypto-y and Turing complete, they’re not related. Still, a lot of the people interested in the one are also interested in the other. In the future you’ll run Ethereum on your Urbit, just like you’ll store your Bitcoins on it.
Basically, Ethereum uses a blockchain so that you can verify that computation occurred the way it’s supposed to without having to trust anything except that less than 51% of the nodes are controlled by bad actors. This allows all sorts of cool new applications, most of which are just like the old applications except with no trusting of a central authority. Very nice. The massive inefficiency of a blockchain isn’t a problem because the computations being verified are usually very small.
Urbit has no blockchain because our computation doesn’t need to be trusted by anyone else. We compute only for ourselves, so I only have to trust that my particular Urbit isn’t compromised. The benefit is that we’re efficient enough to run a cloud computer. The cost is that we can’t trust completely trust anyone else’s computation (all the normal trust-building techniques are still valid, of course). Network traffic is encrypted, of course, and there’s a built in PKI which allows you to trust certain things about who you’re talking to.
Aw dammit man. I gotta quit flipping burgers and start hanging with smarter people.
A quick comment: “Does anyone actually use anything written in Haskell?”
Pandoc, a popular program for converting any document format that you want into any other document format that you want, is written in Haskell. I compiled a new copy myself a few days ago b/c the version that Ubuntu had wasn’t recent enough.
There is little to prevent you from compiling more conventional programming languages to Hoon (which would be like compiling to C) or directly to Nock. You can even build just enough of a U*IX shim on top of Urbit to make software easier to port.
Unix compiles rather straightforwardly to Nock. C, not so much.
Urbit is Yarvin’s vanity project, but also a ponzi of sorts.
See his recent AMA:
https://www.reddit.com/r/IAmA/comments/4bxf6f/im_curtis_yarvin_developer_of_urbit_ama/
Personally, I find both Yarvin and Urbit irrelevant and extremely boring.
What is a far more interesting project is Maidsafe, and a far more interesting language is Rust.
Rust. Hah. Snort. Snicker.
oh my god, I didn’t even read far enough to see that. Reactionaries are interested in Urbit because they recognize Yarvin’s intelligence, patience, and vision. Urbit is, like NRx, a totally speculative research project that isn’t actually going anywhere but may contribute valuable ideas to the rest of the field.
Rust is bullshit. Every feature Rust has other languages also have, and Rust has a poorly designed collection of features tangled together with poorly designed syntax. It’s no more readable than a subset of C++ that does exactly the same thing as Rust would be. But Rust comes from an SJW converged organization and has SJWs working on it and an SJW code of conduct, and is reasonably easy to learn considering that everyone already knows the C family.
[…] hates to say it, but he’s got some points Against Urbit. Say it ain’t so, Jim! He’s got his reasons. He also has an ode to differences: […]
If your interested in stuff like Urbit you’re really going to like Red Programming Language. RPL or RED is a rewrite of Rebol. Rebol was written by Carl Sassenrath who wrote a lot of the Amiga OS. Rebol just never caught on financially but it got a lot of fervent believers. Carl slowly left off working on Rebol so one of them decided to rewrite the whole thing but make it a complete language. A Systems language like C, general and high level language like HTMLor DSL is all there. It has something called dialects which you can write Domain Specific Languages for upper level stuff.
It’s a bit difficult to wrap your head around because it’s somewhat functional, but not also. I believe RPL will completely take over the language space. It’s extremely productive, not super cryptic and has a small amount of rules. Red is not completely finished yet but you can use Rebol to start and most things will be the same. It’s well worth looking at.
http://www.red-lang.org/
Most of the operation of RPL will be the same as Rebol so looking at Rebol will give you an idea. Here’s a forum for Rebol. Look at “Sticky: USEFUL REBOL DOCUMENTS AND RESOURCES” lots of links there.
http://www.rebolforum.com/index.cgi?f=home
Have a look at this and see how easy it is to get a GUI based program up and running.
http://business-programming.com/business_programming.html
All this is done with a 1.2MB or so code base. No 75MB JAVA or other huge library. RED will be small too because of the excellence of the language.
One last thing. Rebol is interpreted RED will be both interpreted and complied if you want.
Urbit has been growing. It has functional messaging, and a liquid marketplace for its assets. Further comments on the outlook of this project would be appreciated.