
Urbit: A clean-slate functional OS - tsax
http://www.urbit.org/
======
urbit
A better link would be the front page:
[http://www.urbit.org/](http://www.urbit.org/)

I guess on the Internets, you never release anything - it's released for you.
Please be warned, (a) the doc is incomplete, (b) if you create an Urbit ship
you'll eventually have to destroy it, as we don't have continuity yet.

~~~
Touche
Watching the video blew my brains out the back of my head. Figuratively of
course. Thanks for not letting me get anything productive done for the rest of
the day.

~~~
msutherl
The music is great. I stopped watching and just listened while continuing to
get work done.

~~~
rxdazn
Brian Eno - An Ending (Ascent)
[http://www.youtube.com/watch?v=It4WxQ6dnn0](http://www.youtube.com/watch?v=It4WxQ6dnn0)

------
saidajigumi
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 K&R C up as a model, you'd do well to mimic its documentation
philosophy.

~~~
urbit
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/Chapter-1-arvo.html](http://www.urbit.org/2013/08/22/Chapter-1-arvo.html)

But this itself is incomplete. Watch the video first:

[http://www.urbit.org](http://www.urbit.org)

Then build Arvo and use the sekrit code it generates to, basically, subscribe
to our newsletter.

It's just a bad idea to document anything before it works completely, because
you end up with doc that validates this criticism. The right way to build a
language is to build it, use it, get comfortable with it, actually master it
and become an expert of sorts... then document it. Sadly, not too many of us
can live up to this ideal.

~~~
bjz_
I for one love the whimsy. We need more LearnYouaThings and Shoes and runtimes
that spit out lovecraftian quotes...

------
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://unqualified-
reservations.blogspot.com/2010/01/urbit-functional-programming-from.html)

[http://moronlab.blogspot.com/](http://moronlab.blogspot.com/)

~~~
clarkm
Someone earlier in this thread mentioned his apparent disdain for PL research.
If you want some background on his experiences, as well as some great musings
on the current state of CS grad programs, I recommend these two articles:

[http://unqualified-reservations.blogspot.com/2007/07/my-
navr...](http://unqualified-reservations.blogspot.com/2007/07/my-navrozov-
moments.html)

[http://unqualified-
reservations.blogspot.com/2007/08/whats-w...](http://unqualified-
reservations.blogspot.com/2007/08/whats-wrong-with-cs-research.html)

~~~
mietek
I will not comment on the judgement passed upon the education system. The
second article exhibits eristic tricks, obfuscatory language, and a plain
confusion of ideas, especially when speaking about proof-carrying code and
type theory.

It's interesting to see the author wishing for a Python of functional
programming, and yet Hoon's syntax appears deliberately obscure.

However, there is one paragraph with which I wholeheartedly agree:

 _> I think the world could use a charity that funds creative programming. The
software systems that people use today — don't even start me on "Web 2.0" —
are awful and ancient, and hardly anyone has any reasonable plan to improve
them. Free-software programmers are not at all bad at supporting themselves,
but nothing like Xerox PARC exists today, and it should._

It should, and, hopefully, it will. Soon.

~~~
drewhk
Deliberately obscure, yes:

>We should note that in Nock and Hoon, 0 (pronounced “yes”) is true, and 1
(“no”) is false. Why? It’s fresh, it’s different, it’s new. And it’s annoying.
And it keeps you on your toes. And it’s also just intuitively right.

~~~
clarkm
Well, it's no different than Unix:

[https://en.wikipedia.org/wiki/True_and_false_(Unix)](https://en.wikipedia.org/wiki/True_and_false_\(Unix\))

------
colanderman
""" _Its self-compiling kernel, 7000 lines of code, specifies Hoon
unambiguously; there is no Hoon spec._ """

You realize there's such a thing as over-specifying something, right? You
realize that using source code as a spec does this?

If you don't realize; consider that non-data aspects of a program, such as
runtime and memory usage and bug compatibility, can sometimes form part of a
specification, and sometimes don't. A specification says as much what is _not_
required of an implementation as what _is_ required. By claiming your one true
implementation is _the_ spec, one has no means of ascertaining what behavior
is incidental, and what is actually required/able to be relied upon.

I'm not normally an XKCD fan, but this strip sums it up perfectly:
[http://xkcd.com/1172/](http://xkcd.com/1172/)

.

""" _Hoon can be classified as a pure, strict higher-order static type-
inferred functional language, with co /contra/bivariance and genericity.
However, Hoon does not use lambda calculus,_"""

A higher-order functional language does not "use" the mathematical definition
of higher-order functions? In that case, what do you mean by "higher-order
functional language"?

EDIT: I was going to make an analogy to the hypothetical claim that language
X's arithmetic system doesn't use Church numerals (i.e. the mathematical
formulation of natural numbers)… _but Hoon is actually implemented using
Church arithmetic_. Go figure.

.

""" _unification,_ """

By what mechanism does Hoon implement type inference? Honestly, that's kind of
like saying Hoon doesn't use, say, queues. Great, but, why?

.

""" _or other constructs from “PL theory.”_ """

Disdainful much? I'm really curious what's the background behind the scare
quotes here.

.

EDIT: Just to be clear, I'm not claiming your project is uninteresting or not
worth your while. I just feel you're being overly dismissive of the, let's say
"traditional" schools of thought, with invalid justification.

~~~
urbit
As for the type inference, you don't need unification to do type inference.
Hoon infers only forward, not backward. Of course you could say it's a subset
of unification, as it is.

I find Hindley-Milner inference systems too powerful. The programmer has to
model what the inference system is doing in his or her head, and it's a source
of significant cognitive load. Hoon's inference algorithm is slightly too
smart in some cases, and requires slightly too much typing in others, but I
think it's generally well matched to human capacities - especially for those
of us who are not natural mathematicians.

~~~
tikhonj
What? Why do you have to think about what the type inference is doing? I've
never needed that with H-M in practice, and I've spent a fair amount of time
with both Haskell and OCaml.

When I use a good inference system like that, I simply don't think about the
typechecker most of the time. It just doesn't come up. The types simply work
out, largely because the inference is sufficiently good.

The only times I've had to model the inference in my head is when it is
_insufficiently_ powerful, like with OCaml objects or certain typeclass
patterns in Haskell. That is, it's only a problem when the inference _breaks
unexpectedly_.

Type inference just works, until it doesn't. And that's the only place I've
had difficulties: when it doesn't.

The solution to a problem like that is not to make it break _more_ often! That
just exacerbates things.

A less capable system (say Scala or, god forbid, Go) just makes life more
difficult. Even if it's easier to run the algorithm in your head. Especially
then, in fact: you shouldn't be thinking about it on the first place.

~~~
urbit
My feeling is that there's a relatively small subset of programmers who adapt
well to unification inference, and they think the way you do - they grok the
logical problem the inference engine is trying to solve, and don't worry at
all about how it does it.

There is a larger set of programmers who try to understand it and run into,
well, stuff like this:

[http://en.wikipedia.org/wiki/Hindley%E2%80%93Milner](http://en.wikipedia.org/wiki/Hindley%E2%80%93Milner)

I hope you're not seriously suggesting that this content is on the same
intellectual level as, say, a good RFC.

A good RFC in fact works very hard to be as stupid as possible, and one source
of irritation from the RFC-producing world to the PDF-producing world - so to
speak - is that the PDF-producing world doesn't seem to even understand that
they _have_ this job, much less are making any particular effort to do it.

The way people should understand the Hoon type inference engine is to think
about the concrete reality of what it's doing, not the abstract mathematical
problem it's trying to solve. This is simply because human beings aren't very
good as a species at mathematics. Hate that that's true, but that it is true I
don't think anyone can deny.

~~~
tikhonj
I think you're just projecting your familiarity with things like RFCs as
somehow more intuitive. People have _plenty_ of problems with the network
stack and its associated abstractions! TCP/IP or even just HTTP lead to plenty
of confusion. In a vacuum, I am not convinced the RFC would be any easier than
a paper on Hindley Milner. (Wikipedia is not a good replacement for either.)

"Intellectual level" isn't exactly a well-defined term. It inevitably
conflates the inherent complexity of something with the background needed to
quickly understand it. The difference in the two articles is not in how
accessible they are to somebody with no relevant background--both the RFCs and
H-M would make no sense to a layperson!--but in the fact that they target
different audiences.

Both are very stupid in the same way: they are very explicit about every
little detail. It's just where an RFC uses technical terminology mixed with a
legalese-like language (SHOULD and MUST and so on), H-M uses mathematical
notation and inference rules. I do not believe that one of these is so much
more inherently difficult to understand than another; it's much more a matter
of experience and background knowledge. Without that, reading either is going
to be relatively slow and laborious. Having gone through both RFCs _and_ type
theory, I've found both similarly slow in terms of content; the main
difference is that the mathematical notation happens to be much more dense. So
perhaps it takes me five times longer to get through a page about type theory
as a page of an RFC, but that single page contains the same amount of
information, just encoded differently.

Also, I don't buy that you have to understand how the inference works to use
it, any more than you have to understand or think about the OSI model to write
networking code. You can use both perfectly well--and most people do--without
needing to think about or understand everything. Moreover, you won't be able
to learn either without a good deal of work and the relevant background. I
suspect that it just happens that the background for one matches much more
closely with yours than the background for the other.

Sure, humans as a species are not very good at mathematics. But they aren't
very good at engineering either! They are really bad at keeping a bunch of
details in memory and running (even simple) algorithms in their heads. All
told, it's better to avoid it.

~~~
urbit
For the source of my bias, I have actually spent a considerable amount of time
working with people in the "RFC world." For example, I wrote the kernel of the
Openwave WAP browser, which shipped about a billion units, even if it sucked
and no one used it. I have spent just about no time in the PDF world, and even
when I was in grad school I was an OS guy. (Here's a fun old paper of mine:
[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7...](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7414)).
So, zero time in the "PL theory" world.

I can tell you how this world sees the "PL theory" world. They say: look, you
have your own way of formalizing computing, there are infinitely many ways of
formalizing computing, the one we use seems to work just fine, so why should
we learn yours? Whether they won't, or they can't, or they are too pigheaded
to - the answer is, they aren't.

I don't view language design as an opportunity to change the world to this
extent. And I think many, many good ideas are getting lost in the PL theory
world. So, my goal was to replicate these ideas, as best as I can, for
programmers who think about programming the way I do.

------
jsd1982
I was with you til you introduced the Hoon syntax. Why ruin a great concept
with a shit language? WHAT IS WRONG WITH LANGUAGE DESIGNERS?! Just come up
with a sane language with a sane syntax on a great platform. This is
apparently asking a lot. It's not fucking rocket science.

~~~
urbit
I agree entirely! This is so much better than the typical "middlebrow
dismissive" that I upvoted it...

And actually, if you don't like Hoon you can build your own language on this
platform. So long as it compiles to Nock. You'll probably have to write your
first compiler in Hoon, but we do have pretty decent combinator parsers. If
you can swallow the syntax...

~~~
jsd1982
I like that you upvote your critics. That amuses me greatly. I had not viewed
the video before I made my first comment but after watching the video I'm
impressed with your implementation and solid practical concepts, but I still
abhor your Hoon syntax. I haven't looked into Nock yet but I have a feeling I
might knock its syntax as well, pun intended.

------
gwern
>I ate something I shouldn't have the other day and ended up having this
surreal dream where Mencius Moldbug had gotten tired of the state of the
software industry and the Internet and had made his personal solution to it
all into an actual piece of working software that was some sort of bizarre
synthesis of a peer-to-peer identity and distributed computing platform, an
operating system and a programming language. Unfortunately, you needed to
figure out an insane system of phoneticized punctuation that got rewritten
into a combinator grammar VM code if you wanted to program anything in it. I
think there even was a public Github with reams of code in it, but when I
tried to read it I realized that my computer was actually a cardboard box with
an endless swarm of spiders crawling out of it while all my teeth were falling
out, and then I woke up without ever finding out exactly how the thing was
supposed to work.

[http://lesswrong.com/r/discussion/lw/ipu/open_thread_septemb...](http://lesswrong.com/r/discussion/lw/ipu/open_thread_september_2329_2013/9szc)

------
eli_gottlieb
_Hoon is a high-level language which defines itself in Nock. Its self-
compiling kernel, 7000 lines of code, specifies Hoon unambiguously; there is
no Hoon spec. Hoon can be classified as a pure, strict higher-order static
type-inferred functional language, with co /contra/bivariance and genericity.
However, Hoon does not use lambda calculus, unification, or other constructs
from “PL theory.” Hoon also excels at handling and validating untyped data, a
common task on teh Internets. Its syntax is entirely novel and initially quite
frightening._

Crank detected. Homing in for the kill.

~~~
urbit
Have fun!

I recommend you start with the Nock tutorial:

[http://www.urbit.org/2013/08/22/Chapter-2-nock.html](http://www.urbit.org/2013/08/22/Chapter-2-nock.html)

The build instructions in this file are out of date, use the ones from the
Arvo chapter. Also, probably the best short overview is the header comment in
the Hoon compiler:

[https://github.com/urbit/urbit/blob/master/urb/zod/arvo/hoon...](https://github.com/urbit/urbit/blob/master/urb/zod/arvo/hoon.hoon)

Also don't miss the video:
[https://vimeo.com/75312418](https://vimeo.com/75312418)

~~~
nutate
Oh wow.

After watching the video I'm legitimately interested in more than the
language. You've got some cool ideas going on there. I'll be emailing for a
32-bit destroyer in a second.

------
yebyen
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/](http://www.tlg.uci.edu/~opoudjis/lojbanbrochure/lessons/)

Urbit of course having the advantage that it can be programmed in... the video
is very cool!

~~~
urbit
mi prami la lojban .ui

~~~
nemo1618
ge'edai

~~~
yebyen
I googled, got 1/3 of the way through "Subsequent UI Cmavo", and gave up.

If you explained in lojban, I promise I'd struggle a few minutes longer before
giving up :D

[http://www.lojban.org/tiki/Subsequent+UI+Cmavo](http://www.lojban.org/tiki/Subsequent+UI+Cmavo)

I read Arabic fairly well but I did not understand Lojban, not having any
framework to understand it in, whereas I took Arabic classes for basically
four years of college.

I got "prami" to mean love, and .ui to mean ":)"

Why do you put .i at the beginning of some sentences?

~~~
nemo1618
Disclaimer: I'm no lojban expert myself, so this may be inaccurate.

{mi prami la lojban .ui} is pretty straightforward: I love lojban, plus the
{.ui} attitudinal, which indicates happiness (or as you said, ":)").

The period {.} is an interesting part of lojban. It indicates a glottal stop.
Most words in lojban start with a consonant, so glottal stops are placed
before words that begin with a vowel (mainly just attitudinals and names).
This is to prevent words from flowing into one another when speaking rapidly,
which is important since one of the design goals of lojban is to avoid
ambiguity.

{.i} is actually punctuation: it marks the boundary between sentences. All
punctuation is pronounced in lojban. This may sound exhausting, but again, it
reduces ambiguity.

{ge'edai} is intended to mean "I know that feel" \-- {ge'e} meaning
"unspecified emotion" and {dai} meaning "empathy" \-- but I'm not sure if
combining them is grammatically correct. Perhaps {dai} alone would be more
accurate.

~~~
yebyen
I know about . and it makes sense to me because of hamza in Arabic. It's the
same. It's not a letter, it only serves to reduce ambiguity, but they wouldn't
say it's punctuation either. Thanks for breaking it down for me!

------
FeepingCreature
Well, I've read most the docs, let's say _skimmed_ the code examples, and I
think you're a very smart, competent engineer with a sense of what makes for
good language syntax that is utterly, incomprehensibly alien to me. So I
guess, martian-language mission accomplished?

------
fyolnish
This is art.

"There is never a reason to program in Nock. Except to learn Nock." Classic

------
quanticle
I love the project concept. A toy functional OS would be an admirable
counterpart to e.g. MINIX. That said, I have one minor quibble:

 _A programming language is called a language for a reason - it should
activate the human linguistic lobes._

Another programmer said this, a long time ago, and that's how we ended up with
Perl. Please don't seek to emulate Larry Wall. Perl is great for quick
automation, but anything complicated built with Perl quickly converges to
unintelligible line noise (barring the exercise of zen-like discipline). If
you're making something for beginners, please, please, give them the tools to
build abstractions in a consistent and understandable manner.

~~~
urbit
Well, of course, Larry Wall is a god.

But that said, the main difference between Hoon line noise and Perl line noise
is that most of the ASCII we use has a very regular structure, with a
(relatively) limited set of exceptions. So it looks about equally alien at
first, but the Hoon ideogram (digraph) set should be easier to learn.
Unfortunately at present the set of people who know it is very small - so the
theory really hasn't been tested.

It is what it is. But at least there's no Unicode. (Not that you can't have
Unicode in strings, of course.)

And anyone who doesn't like line noise has to stand up for reserved words.
Some of us welcome that conversation...

~~~
aray
The unicode-in-strings but not in variables/etc bothers me about Java (coming
from Go, where unicode is allowed in variables). It seems inconsistent to have
two separate character sets for different semantic subsections of what is a
single text file.

What about unicode in comments? If I put a string in a comment can it go
there?

~~~
urbit
Restricting symbols to a strict subset, rather than a strict superset, of
global keyboards in practice, is about cultural literacy in practice.

If you put unicode in variables, perhaps because you're using a national
keyboard with special unicode powers, your code will be extremely hard to work
with for programmers using a different national keyboard. Thus, even if you
could do it, you shouldn't.

Now, the symbols on American programmers' keyboards are not all on every
keyboard in the world - but pretty much every programmer in the world knows
how to find them. Thus, sticking with ASCII is basically sensible use of
Postel's Law in the language design context.

In comments - it should be ok but I think it breaks right now. Not a high
priority bug, but definitely a bug.

~~~
FeepingCreature
Spread the word of .Xcompose?

------
urbit
A demo video: [http://vimeo.com/75312418](http://vimeo.com/75312418)

~~~
mietek
The video shows an utterly fascinating mixture of Lisp, Erlang, Plan 9, and
Bitcoin. The only missing ingredient is a proper static type system!

------
noonespecial
With all that jargon I was expecting a set up for a punch line at the end.
Don't nock it so hoon, it's not done jet. Ha!

~~~
urbit
Sigh, HN really is turning into - never mind. :-)

------
state
If ever there was a right attitude about bringing a radical project in to the
world: this is it.

I just spent 15 minutes just _reading_ the documentation. Because it's
_interesting_. That never happens.

------
agentultra
This is really, really neat.

I really like the concepts in Avro and Urbit. Particularly interesting for me
is the checkpoint/replay, distributed version control, and neighbours.

This is a really cool experiment!

~~~
urbit
Thanks, but Avro is someone else's cool project!

(Arvo is named for
[http://en.wikipedia.org/wiki/Arvo_P%C3%A4rt.](http://en.wikipedia.org/wiki/Arvo_P%C3%A4rt.))

~~~
agentultra
I think I've lost all precious free time I have... this is great stuff. :)

------
tlb
You say addition is O(n^2), but I think you can write an O(n) addition with
only increment, recursion, and equality testing.

In Python syntax:

    
    
      def add(a, b):
        return add_r(a, b, 0)
    
      def add_r(a, b, c):
        if b == c: 
          return a
        else:
          return add_r(a, b, c+1) +1

~~~
jcburnham
Yeah... just one of the many many things we haven't gotten around to fixing.
Since it doesn't really matter for a jet-propelled function.

[https://github.com/urbit/urbit/issues/11](https://github.com/urbit/urbit/issues/11)

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

~~~
yebyen
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_

~~~
theonewolf
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.

------
ajanuary
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.

~~~
wgd
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 optimizations are quite
a bit _less_ brittle than the ones you get with a JIT-compiled virtual
machine.

~~~
dragonwriter
> 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".

I don't see the "instead" there. Those seem to be two ways of saying the same
thing.

~~~
wgd
The difference is one of universality.

Let's say that my VM of choice has a tracing JIT, and it will attempt to
optimize traces up to 1,000 instructions long. Let's further say that in the
current version of my code, the body of my hot loop is 980 instructions long.
Then in a new version I add another few operations which push it up to 1,010
instructions. Suddenly the JIT stops trying to optimize that portion of my
code and performance tanks.

Meanwhile some other guy wrote his code using a VM which used this sort of
"Jets" approach. It's probably not as fast or as versatile overall, but when
he adds another few dozen instructions to a hot loop he can do so secure in
the knowledge that all the preexisting code will continue to execute just like
it did before.

------
cldr
> Hoon is a keyword-free language - any alphanumeric text in the program is
> part of the program. Where other languages have reserved words, Hoon has
> squiggles.

But... why?

~~~
urbit
You're saying, why are reserved words a bad idea? I think most defenders of
the humble reserved word would consider it, at best, a hack. Maybe it's a
necessary hack, maybe not.

With reserved words you are overloading two very different namespaces, the
space of language primitives and the space of user functions/variables. Sure,
you can get away with this. But do you want to? A language is a UI, and the
potential for confusing the programmer is immense. If operators and functions
are really different things - as they are in Hoon, anyway - it's very
confusing to mush them together.

~~~
cldr
I'm not asking why reserved words are a bad idea, just opining that I think
having 100 single- and double-character symbols might not be the best UI for a
language. Why not have just names (neither reserved like keywords nor
inscrutable like symbols?)

I don't know, I am similarly annoyed by mathematicians because they usually
use single letters for variables. It's a little more excusable for them
because math functions are usually very short and have few variables, but
still I'd rather use words. But I digress.

~~~
urbit
It's a different approach to learning that I think favors the actual learning
curve, not the perceived learning curve.

Your brain is actually built to memorize symbols like this. (I feel I know the
learning process pretty well because I have toddler-aged kids who are also
learning Chinese.) Of course, kids are not grownups, but even for grownups the
process of binding symbol->meaning is easier than it looks like it should be.

Also, when you have name->meaning, the name inevitably is chosen for
orthographic reasons and supplies its own meaning, which may mislead from the
actual definition of the primitive. If you bind a symbol directly to a
semantics, you lose this source of confusion. It is replaced (ideally) by an
odd sense of "seeing the function," which I think is also present in
experienced Perl ninjas.

------
nutate
I really like this. I hope some younger people with more time on their hands
push this farther.

~~~
tomrod
I'm not sure I follow what this is. Where would I use Nock and Hoon?

~~~
nutate
To build your startup? No.

To have fun? Why not.

~~~
tomrod
I should rephrase my question: on what technology platforms would one use Nock
and Hoon? Embedded systems? Anything (due to "portability")?

~~~
richardlblair
As others have pointed out, this is art.

You don't look at art, and ask "Why did you do this??". You simply enjoy it.
The artist did it, to do it, and nothing further.

If you can not see this that way, then I am truly sorry.

~~~
nightski
If it is truly art then it doesn't make much sense why he is trying so damn
hard to make it practical.

~~~
richardlblair
Think of it as great architecture...

------
arh68
Would you mind doing lots more screencasts? Maybe writing a jet, rigging a
test, profiling, and maybe a bunch of other things. I very much like your demo
style, and I have a hunch these docs are going to be pretty dense. ;)

------
jpt4
From pedestal to pinnacle, all things are quantum, not classical. The metaphor
that better avoids scaling obsolescence for your project is perhaps Bohmian,
rather than Maxwellian.

------
dmytrish
Codex Seraphinianus of programming?

I think it's a true piece of postmodern art.

------
samograd

        So if we had to read the above decrement...we’d say: 
        “luslus dec sigfas cen dec bartis a tis pat sigbar soq
        dec soq ketcab pat wutgal tis pel zero a per tislus b 
        tis pat barhep wutcol tis pel a lus pel b per per b buc 
        pel b lus pel b per per.”
    

Absolute brilliance.

------
eonil
Though I couldn't understand them fully...

The names are awesome! The concepts are awesome! And the music is awesome!!!

~~~
eonil
I see some similarity to Smalltalk or Windows PowerShell. And this made me to
imagine typed Smalltalk/Objective-C style syntax on shell which would be great
for usability...

~~~
offensivehandle
Shell programs are expected to take streams of data and produce other streams
of data. Shell programs are also supposed to, but often don't, have uniform
configuration options. Instead, we have ps ax | grep chromium | grep -v grep |
awk '{print $1}' | xargs kill

* ps accepts ax with no -

* awk is its own programming language lol

* xargs gets pretty complicated if anything bigger than this happens

(incidently, I know about awk '/chromium/ {print $1}' and killall. but i have
seen that command line in the wild. because some people don't read the awk
manual for fun, and i'm not sure if every unix system even has a killall
command)

...and yet the shell is still the preferred tool for what it does because
everything else requires too much typing (of both varieties)

Apparently urbit also has streams of raw data. It's about time someone came up
with a new idea for a shell that keeps what's great about the shell (though
personally, i would standardize on streaming a form of json, because it turns
out that data is very often found as scalars, lists, and mappings).

So anyway. If urbit actually ends up being better to live in than unix, and
having shell programs that are configured in exactly one way would be an
improvement, and having data that's easier to parse than plain text while
remaining as easy to read as plain text would also be an improvement, well,
I've always wanted to live in a submarine. If it gets a nice editor and c++
compiler, that is. I do need the best performance possible out of my computer
for my work.

------
offensivehandle
Okay, since you want comments here, here I'll put mine.

The reason you were so successful in coming up with a new political philosophy
is that your "I'm a Martian" trick got you think thoughts that no respectable
person would be caught dead thinking.

There aren't the same taboos in computer system design, so while you can refer
to the systems people use every day as gigabytes of, what was it, of ass
fucking more ass, there's nothing you say that I haven't already heard.

I'm still waiting for the Python of functional programming. Paul Graham
announced Arc when I was in middle school. Maybe it will be released as the
scripting system in Half-Life 3.

Being an alien from Alpha Centauri, and observing the growing collection of
programming languages, what do you think people keep designing new ones for?
Why do some Urplatians argue for Scheme and other Urplatians for Python?

Rather than asking the question of 'what is a programming language', and
trying to design the axiomatically simplest possible thing, try asking the
question of 'how do people use programming languages'.

Is your system a bit of syntax regularization away from the pseudocode people
scribble on paper to explain algorithms to each other? No, that's Python.

Is your system something that compiles down to use the bare metal to its
fullest potential while maintaining as much creature comforts as possible? No,
that's C++.

Is your system something with an ancient history of having a solid ABI, that
in fact every other language's ABI is described with? No, that's C.

Is your system a heap of cruft upon kludges with the original intention of
providing programming access to a hypertext document? That's Javascript.

I wouldn't want to write a regex as anything but a regex.

In conclusion, you're asking a question that's been asked before and getting
an answer that's been gotten before. But, maybe it is finally time for
functional programming to come back. Maybe you're a popular enough guy to get
people to use your system.

~~~
davidgerard
"Being an alien from Alpha Centauri, and observing the growing collection of
programming languages, what do you think people keep designing new ones for?
Why do some Urplatians argue for Scheme and other Urplatians for Python?"

Typical mind fallacy.
[http://lesswrong.com/lw/dr/generalizing_from_one_example/](http://lesswrong.com/lw/dr/generalizing_from_one_example/)

Most people model other people as _just like themselves_ , plus or minus a
diff. The trouble is that they don't understand just how wide-ranging human
thoughts and feelings can be, and assume they will understand and be able to
model based on the diff, even if the diff is larger than their whole mind.

It's why geeks keep coming up with "intuitively obvious" schemes no-one else
can understand, and why engineers are _routinely_ surprised at what actual end
users do with their products in user testing.

So people write new languages that suit their personal peculiar ways of
thinking. Thankfully, many are quite aware that this is what they are doing
and don't claim universality.

This is why Urbit is art: translating numbers and ASCII characters into
nonsense syllables that you are actually expected to pronounce and think in
suits Yarvin's mind, even as it leaves me thinking "there is such a thing as
being too much of a Borges fan". Which is absolutely fine. But this is why
Urbit is art (an expression of a unique personal vision), not anything people
are actually going to use without similar levels of confusion to the present.

For an example of fully rampant Typical Mind Fallacy in Urbit, see the
security document:
[http://www.urbit.org/2013/08/22/Chapter-6-security.html](http://www.urbit.org/2013/08/22/Chapter-6-security.html)
About two-thirds of the way down, you can actually see Yarvin transform into
Moldbug and start pontificating on how humans communicating on a network
_should_ work, and never mind the observable evidence of how they actually
have behaved whenever each of the conditions he describes have obtained. The
very first thing people will do with the Urbit system is try to mess with its
assumptions, in ways that its creators literally could not foresee (due to
Typical Mind Fallacy), though they might have been reasonably expected to
(given the real world as data).

------
alfredjaynock
So this is what moldbug does in his spare time.

------
melloclello
Hey Moldy I just want to say 'ur-bit' is a pretty cool name B-)

------
cdcarter
I can't tell what I'm more confused/impressed by, Hoon or the social model.
Either way, I've got a destroyer and now I'm trying to understand just how zod
works.

------
mhartl
Congrats on the launch (even if teh Internets did it for you)!

------
dreen
Love the fact you used music by the god of ambient, Bran Eno.

------
wgd
The more I think about it the more I really like the whole "Jets" concept
(although I'm not sold on the name, I'd love to learn that it's a known
concept in the PL field with a nicer name). I'd like to see how such an
approach would work out for optimizing something more "fundamental" like the
Binary Lambda Calculus.

~~~
jamii
Haskell has rewrite rules which is how eg stream fusion is implemented.

[http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/rewri...](http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/rewrite-
rules.html)

------
JulianMorrison
I love this concept of jets and how it allows a "completely isolated" VM to
magically grow connections to the real world.

------
perlgeek
A VM that can be precisely described in 200 words? Does that include the IO
subsystem? I have my doubts that it's possible to describe a full set of IO
operations that any modern VM needs in so few words, just because of the
wealth of features that you usually need (file system access, sockets (TCP and
UDP), pipes, IPC, ...)

------
sr-ix
I dig the Borges references riddled about.

------
0xdeadbeefbabe
Reminds me of the punchline, "consider a spherical cow"

> To a Pascal purist, to anyone who thinks mathematically, this seemed
> hideous. C isn’t really a high-level language at all - it’s a glorified
> macro assembler. Mankind retreats to the cave.

Leaky abstractions are hideous too, don't you think?

------
sz4kerto
Astonished.

Reminds me a bit of A+, however. :)

------
quarterto

      Hoon also excels at handling and validating untyped data, a common task on teh Internets.
    

Not sure if satire?

------
batemanesque
using "teh Internets" on yr front page is a great way to put off anyone who
doesn't subscribe to calcified "geek culture"

------
jyf1987
so its root in forth?

------
dancecodes
without flash of course there

------
dancecodes
video not work in ff linux

~~~
offensivehandle
i just finished watching it in firefox on a freshly-installed linux mint 15

~~~
dancecodes
nothing appropriate, gentoo and Im too lazy for fixing it (=^‥^=)

