Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Urbit: A clean-slate functional OS

urbit.org

Post reply on HN
Print view View original

71–80 of 185 posts

Re: Urbit: A clean-slate functional OS

#71

Post by nwmcsween »

wgd wrote: post #42
ajanuary wrote: post #10

So rather than having a lengthy standard it has lots of small non-standardized and brittle performance optimizations? I remain skeptical over whether this tradeoff is worth it.

I think it's a fascinating tradeoff. A typical approach with JIT-compilation is to write relatively inefficient code and hope that the JIT compiler picks up on it and optimizes it for you. Their approach seems to instead be to say "if you generate particular sequences of instructions, we'll detect those and instead execute a more efficient version, every time". IMO this is a really cool idea because the performance o…

This is what about 90% of the libc libraries out there do as well. Also tracing jits also do the same thing they see a trace that has a known optimization and it is performed.

Re: Urbit: A clean-slate functional OS

#72

Post by zzzmarcus »

Just some background, this is by Mencius Moldbug, a.k.a. Curtis Yarvin, a.k.a. C. Guy Yarvin of Unqualified Reservations fame. It's been in the works for a long time and is certainly a serious project.

http://unqualified-reservations.blogspot.com/2010/01/urbit-f...

http://moronlab.blogspot.com/

Re: Urbit: A clean-slate functional OS

#73

Post by stuaxo »

urbit wrote: post #33
saidajigumi wrote: post #30

For a project ostensibly inspired by K&R C, the copy on this site is amazingly opaque and full of its own rhetoric. Recommendation: delete all the linguistic posturing and get down to the hard work of casting light on your ideas. Let that speak for itself. By way of example, the K&R C book had a beautiful clarity and ability to fluidly move between the realms of reference, spec, and tutorial. If you're going to hold…

That's an excellent criticism. Of course the problem is exacerbated by the HN link pointing to the philosophy doc. The greatest philosophy is to have no philosophy at all, but perhaps we're not quite there yet. Actually the K&R equivalent for Hoon doesn't exist yet, and when it does it will be the first thing to read. Since it doesn't, the Arvo tutorial is the first thing to read: http://www.urbit.org/2013/08/22/Chap…

I really enjoyed reading this + a some of the pages.

Very mindbending, got up to watching the video.

Am thinking it looks like it could be quite fast, I guess it would make sense to implement something like ContextFree in it as a start.

Re: Urbit: A clean-slate functional OS

#74

Post by Peaker »

urbit wrote: post #54
Touche wrote: post #51

Earlier quoted context omitted.

Lisp has no reserved words.

Yes, but Hoon would need them. Lisp gets a lot of things for free because it's based on the lambda calculus, which some regard as trivial but I don't. So, for example, lambda in Hoon is not a primitive but a relatively high-level built-in macro. This means it is part of a larger family of lambda-like things, many of which are (IMHO) quite useful. On the other hand, all these things demand either reserved words, digra…

The Lambda Calculus is so tiny how can you view it as anything but trivial?

Just 3 syntactic forms building up an expression tree:

  Expr = Lam Name Expr | Var Name | Apply Expr Expr
And one reduction rule:

  reduce (Apply (Lam name body) arg) = subst name arg body
At least assuming unique names (no shadowing nonsense), you can't get much simpler than this...

Re: Urbit: A clean-slate functional OS

#75

Post by urbit »

yebyen wrote: post #57

I distinctly get the impression that the authors of this project will already know what Lojban is. This language (especially when you get to the part about reserved words, actually made up with special characters as runes, and how to pronounce them) made me think of the structure of Lojban right away. For anyone who hasn't heard of it, http://www.tlg.uci.edu/~opoudjis/lojbanbrochure/lessons/ Urbit of course having th…

mi prami la lojban .ui

Re: Urbit: A clean-slate functional OS

#76

Post by urbit »

Peaker wrote: post #74
urbit wrote: post #54

Earlier quoted context omitted.

Yes, but Hoon would need them. Lisp gets a lot of things for free because it's based on the lambda calculus, which some regard as trivial but I don't. So, for example, lambda in Hoon is not a primitive but a relatively high-level built-in macro. This means it is part of a larger family of lambda-like things, many of which are (IMHO) quite useful. On the other hand, all these things demand either reserved words, digra…

The Lambda Calculus is so tiny how can you view it as anything but trivial? Just 3 syntactic forms building up an expression tree: Expr = Lam Name Expr | Var Name | Apply Expr Expr And one reduction rule: reduce (Apply (Lam name body) arg) = subst name arg body At least assuming unique names (no shadowing nonsense), you can't get much simpler than this...

You can get rid of the whole name reduction system. Which is hardly trivial. If you assume it, though, it's true that everything else is trivial.

Getting symbol tables, functions, environments, free and bound variables, etc, etc, out of the fundamental automaton, frees you up to design them right at the higher layer where they (IMHO) belong.

This philosophical argument has serious practical ramifications, I think, because it leads directly to the Question of Why Lisp Failed. Why did Lisp fail? Many people say, because it couldn't be standardized properly.

Why couldn't it be standardized? Because the Lisp way is not to start with a simple core and build stuff on top of it, but to start with a simple core and grow hair on it. So you end up with a jungle of Lisps that are abstractly related, but not actually compatible in any meaningful sense. This is because the lambda calculus is an idea, not a layer.

Basically the point of Nock is to say: let's do axiomatic computing such that it's actually a layer in the OS sense. The way the JVM is a layer, but a lot simpler. Lambda isn't a layer in this sense, so it doesn't provide the useful abstraction control that a layer provides.

Re: Urbit: A clean-slate functional OS

#77

Post by theonewolf »

yebyen wrote: post #7
theonewolf wrote: post #4

I'm pretty sure this is a giant joke ? Or nothing is implemented yet (and still, kind of jokish especially in description)?

Is this comment a joke? I haven't tried compiling it, but even if large parts of the documentation say "this isn't finished yet" there are code and compilation instructions for Linux and OSX. If it's a joke then it's a joke that two contributors seem to have taken very seriously for a number of months now. EDIT: Not like, say, Flynn... jab jab

I meant in a similar vein to say, esoteric languages or subsests like jsfuck.com.

I see this is considered more art, and I would agree with that.

It appears as if it is a large art + learning experience, and I appreciated that after I watched the movie.

Not a lot of _novel_ ideas per se, but an interesting mixture of things.

Re: Urbit: A clean-slate functional OS

#80

Post by jahewson »

wgd wrote: post #42
ajanuary wrote: post #10

So rather than having a lengthy standard it has lots of small non-standardized and brittle performance optimizations? I remain skeptical over whether this tradeoff is worth it.

I think it's a fascinating tradeoff. A typical approach with JIT-compilation is to write relatively inefficient code and hope that the JIT compiler picks up on it and optimizes it for you. Their approach seems to instead be to say "if you generate particular sequences of instructions, we'll detect those and instead execute a more efficient version, every time". IMO this is a really cool idea because the performance o…

"if you generate particular sequences of instructions, we'll detect those and instead execute a more efficient version, every time"

This is what JITs do. At least the good ones.

Post reply on HN