[amelius]

So let me get this straight. This project is going to define

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 :)

[urbit]

Or as I sometimes say: "on the bottom it's a new kind of math, on the top it's a new kind of social network." This is kind of shameless hype but not as much as you might think.

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.

[amelius]

But can you please explain why you couldn't use existing math (language and compiler) on the bottom layers (1 and 2) before replacing them by your own? That would help me understand the level of your ambition :)

[urbit]

Excellent question!

One, as we know from Church-Turing equivalence, lambda and infinitely many other models of computing have the same expressive power. That doesn't mean they have the same practical utility, though.

Lambda in its Lisp incarnation is actually a rather poor substrate for something like a Lisp machine, I think, because it doesn't layer very well. You can define quite a simple Lisp model, but when you want to turn it into a practical Lisp, you don't add another layer - you grow hair on top of the existing layer. You grow a little hair, you get Scheme; you grow a lot of hair, you get Common Lisp.

I've never seen a lambda model (Qi/Shen perhaps a partial exception, but even there the underlying model is not very simple) that layers a complex language on a simple kernel. I think this is because lambda defines abstractions like symbol tables and function calls, which are user-level language features, in the computational model. The bells and whistles get mixed up with the nice clean math.

Another example is the fact that a modern OS should present itself to the programmer as a single-level store, meaning effectively an ACID programming language in which every event is a transaction. So, you're not constantly moving data across an impedance mismatch from transient to persistent storage, each having its own very different type system and data model.

But, if you're building persistently stored data structures designed to snapshot efficiently and remain maintainable, you really want your data model to be acyclic and not require GC. This goes in a very different direction from almost all the dynamic language work of the last 50 years.

Or, for instance, if your system is designed to work and play well in a network world, it really ought to be able to be good at sending typed data over the network. And validating it when it gets to the other side. Your type system ought to be able to do the same job as an XML DTD or JSON schema or whatever. Well... this wasn't exactly a design requirement when people designed, say, Haskell.

I could go on - there's a lot of stuff like this that is built the way it is because it made very good sense in the 60s, 70s, 80s or 90s. But the requirements really have changed, I think.

[dasvadanya]

Can you, for example, spell out what you mean by "you really want your data model to be acyclic and not require GC"? What is cyclic about the "data model" in e.g. Go or Lua?

[Pxtl]

I can field that one. If a has A reference to B and B has a reference to C and C has a reference to A, then we have q cycle. Cycles play merry hell with garbage collectors and reference count destructors. Languages that force references to be a strict tree or DAG get cheap destruction in return - see C++ without pointers for example - I pop a local object off the stack and it's gone, along with all its children - no non-deterministic GC pause or delay, no Pythonic cycle check. Rust is built somewhat on this principle.

[urbit]

Right. The way I'd put it is: in system software, the iron law is that you don't make the programmer pay for anything she doesn't need to buy.

What you pay (GC) for the privilege of having pointer cycles in your data is grossly disproportionate to the benefit. Yes, there are a lot of things that are O(k) with pointer cycles and O(log n) without them. If what you buy from this optimization is worth the cost of GC, you are doing a lot of these things... a lot.

[FreeFull]

Rust does let you do circular references with Cell<&T> or Rc<Weak<T>>, but yeah, the standard assumption is that there are no circular references.

[dasvadanya]

So "you really want your data model to be acyclic" means, "you want your programming language to forbid construction of cyclic data structures"? So, for example, connected graphs are not objects you can represent?

[azeirah]

Did you mistype q cycle? I tried googling it, but found 0 relevant results.

[dasvadanya]

I love this comment, whether it is serious or satire.

[adamnemecek]

It also appears that the new language defines 0 as true and 1 as false: "A loobean, or just bean, is 0 or 1. 0 is yes, 1 is no:"

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.

[tcdowney]

It's as if it were inspired by all of the bad parts of a Dan Friedman text. :)

[gojomo]

Here's an idea: maybe anyone accusing someone else of being "too ambitious" should share one of their own projects that demonstrates exactly the right level of ambition.

[pyre]

So in your opinion nothing is ever too ambitious? Or is it just that no one should every be allowed to utter the words "too ambitious?"

[gojomo]

No, some projects can be too ambitious, including even recklessly or dangerously ambitious. But I'd rather hear that judgement from someone with a reputation for appropriate, successful ambitiousness, and with some supporting reasoning.

The grandparent comment comes from a pseudonym linked to no evaluable projects. It offers a costless, totally-generic pooh-poohing of a real project as "too ambitious". But that project is actually shipping code that works, with 126 contributors, many with a known history of contributions in related spheres.

Against that, the comment even uses an appeal to "HN standards"! As if, we should all be discounting this sort of stuff, on its face.

I'd prefer "HN standards" encourage such ambition, backed with code – not casually mock it with a ascii-smiley.

[urbit]

Again, the contributor list in github is WAY misleading, because it accidentally somehow pulled in all the contributors of the libraries we bundled (eg, libuv). We need to fix this, I think.

[gojomo]

Thanks for the clarification; I hadn't noticed that caveat earlier.

[pyre]

> But that project is actually shipping code that works

I get that this is more than just vaporware, but getting past the vaporware stage doesn't necessarily prove that something isn't too ambitious. When something is attempting to enact a paradigm shift, the final goal is adoption/usage, not just a working/functional product.

[gojomo]

You seem to be using "too ambitious" as a synonym for "unlikely to succeed". But that's something different.

"Too ambitious" implies someone shouldn't even be trying for this goal. That's a corrosive attitude, and I'd like it kept-in-check by a requirement that sources of such negativity show their reasoning/experience/work.

[urbit]

+1 - I can't emphasize this too strongly.

[grayclhn]

I read less negativity into the comment than that.

[ctdonath]

That logic is like

X < Y => "oh, so X is always zero, huh?"

[pyre]

Nevermind the fact that the parent post believes its possible to quantify "exactly the right level of ambition," the poster believes that the only people that should be "allowed" to comment on whether or not something is too ambitious should be people that are currently undertaking ambitious projects themselves.

This smacks of privilege. Not everyone is or can be in a position to pursue ambitious projects. To say that these people should be barred from commentary is ridiculous.

[gojomo]

I've not suggested anyone be 'barred' from commentary.

Rather, if you want to dump generic negativity on a real, delivering project, you should justify why your negativity is relevant, for example by documenting your own related efforts.

If you want your cynicism to be respected, then yes, that's a privilege that needs to be earned. You can always say it, but it should be called-out as empty bullshit until backed with detailed reasoning or experience.

[GuiA]

s/This project is going to define/This project is defining/

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.

[amelius]

And what is the reason why an existing language and compiler doesn't suffice for 1 and 2?

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.

[cdcarter]

Because it's incredibly fun to work on? It's a brilliant VM once you wrap your brain around it, and the hackers behind it got to really try something new?

[implicit]

Judging by the documentation, Urbit looks to be less about leveraging pre-existing work and more about reinventing computer science and software engineering from the ground up.

[kazagistar]

They already basically have all of the above, as a working tech demo. They actually had it like a year ago or more, but bits are missing or in progress still.

[easytiger]

Ambitious failures with technically brilliant visions have happened before. enlightenment is not easy.

[callahad]

Going to? All of those already exist and run, today. :)