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.
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.
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.
Note that relational databases don't have back pointers either. All references between tables are symbolic. Last century, people tried to make databases that were general pointer graphs (google "network database" or "object database") - broadly speaking, it was a disaster.
If I tell you a linked list of atoms (@) is made from this tile (type):
[p=@ q=*]
it becomes obvious, right?
[p=1 q=[p=2 ..]]
[p=1 q=[p=2 q=[p=3 q=[p=4 q=~]]]]
This should look like building a list from 1-4. There are no cycles, ~ is a terminator.
Q is the reference to the next item in the list.
This would constitute a cycle:
z=[p=1 q=[p=2 q=z]]
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.
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.
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.
"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.
X < Y => "oh, so X is always zero, huh?"
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.
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.
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.
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 :)