[perlgeek]

> The project is based on a fundamental insincerity, which makes me suspicious. All material about Urbit makes a big point of their minimal spec, again so in the linked piece: "The spec fits on a T-shirt and gzips to 340 bytes."

Last I read something like this (I don't know if it was about Urbit or something else), it turned out that there was no IO included in that spec. So, useless for any real-world purpose, and as you said, insincere.

[yebyen]

The IO are events, and the events come from unix (for example: signals, files and sockets).

Urbit is not meant to replace Unix. "They call us, we don't call them" is the fundamental precept in play here. I assure you there is I/O in Urbit, the vanes include an HTTP server, a Hoon-interpreting shell which accepts keyboard input from a terminal, and a UDP layer for facilitating ship-to-ship communications. All of that is written in Hoon, which compiles into Nock.

[clarkm]

> Urbit is not meant to replace Unix.

But I thought that was the long-term master plan. Isn't the whole point to extricate ourselves from eternal dependence on C and Unix ecosystem?

[yebyen]

Some long term plans are crazier than others. I would like to have a machine that runs nock directly on the bare metal, but that doesn't mean it fits into the current architecture.

So far to my knowledge everyone running Urbit is doing so on a Unix system of one flavor or another. The point of "they call us, we don't call them" is not that Urbit never calls into Unix, it's that the set of reasons to reach out to Unix for one of the existing OS facilities is limited, restricted from the list growing any longer than absolutely necessary.

If your persisting disk filesystem evaporates from under you in the middle of operation, maybe Urbit can be prepared to deal with this, but as long as you have it there, might as well use it to allow the user to muck around with your internal representations in a way that is already familiar.

One of the problems Urbit doesn't currently seek to tackle is "a new text editor." Surely this is for the best, not because "a new text editor" is not an interesting problem, but for reasons that I think are already obvious to you.

[perlgeek]

Does that mean the IO events are part of the t-shirt sized spec?

[yebyen]

The keyboard HID drivers are not.

The terminal (dill), HTTP server (eyre), socket UDP layer (ames), and shell (batz) are really expressed using the language in the spec. The filesystem (clay) has a reflection in your unix filesystem, but it's also really clay. In a very real way, even if they are not fully expressed by the Nock spec, they are built using the primitives that are entirely laid out there in Nock 5K. Hoon compiles to nock.

I feel like I'm trying to argue against "no true scotsman" but I don't know how else I'm going to convince you that the code "is really from mars," which seems to be what I want to tell you whether or not it's what you're really asking here.

[javaexpert101]

Strictly speaking, this isn't true. All of these components have code in the C/unix layer.

[newuser88273]

This goes even deeper. Let's just go on and assume that Urbit's spec-bearing T-shirt includes everything you need for IO. Now consider this promise from Mr Yarvin, found in the older Urbit thread someone linked to: "And actually, if you don't like Hoon [Urbit's strange, obfuscated high level programming language] you can build your own language on this platform. So long as it compiles to Nock [purportedly documented on that T-shirt]"

So you hook up your new Nock back end to your favorite compiler, painstakingly hand-crafted to generate Nock code perfectly conforming to the T-shirt spec. You compile a few programs. You run them. Heat radiates from the CPU... and nothing else happens. You wait, patiently at first, then way beyond patience, yet nothing (except heat). Don't you feel cheated, just a little?

[urbit]

Why would you write a new Nock back-end at the same time as a compiler for a new language? Even if you did, you'd want to test the new interpreter with the old language, and the new language with the old interpreter, before going any further.

There is certainly no free lunch in this system. If your CPU is radiating heat, it is spending a bunch of time in Nock formulas which could be better optimized. For instance, maybe you rolled your own decrement, so the interpreter can't match it with the jet it uses for stock Hoon decrement.

That's okay, because the jet matching mechanism is not in any way specialized to the code. All you have to do is (a) get your compiler for the new language to emit a proper jet hint for your things-you-want-to-be-fast, (b) write correctly matched C implementations, and (c) add them to a static array.

Or to put it more briefly: a well-designed Nock implementation is not in any way coupled to the Hoon or Arvo layers.

One of the not-quite-finished things about our interpreter right now (other than that it interprets the tree directly and so gets about 1.5 Nock mips, which is pathetic) is that jets have to be compiled into the kernel and aren't opened by dlopen. Ideally we'd even load something like a PNACL/LLVM object, and we'd get it the same way we get the Hoon source, ie, via Urbit itself.

[newuser88273]

A given Nock implementation is intimately coupled to a matched Hoon compiler.

Attempts to write anything just to T-shirt spec and run on a given Nock-based platform are almost certain to fail. The real spec you'd be required to write to is implied by the platform implementation. Marketing problem: That real spec is not very elegant and it doesn't zip down to a handful of bytes. It doesn't fit on a T-shirt. It's not a stable specification. It doesn't describe an open platform. Yet Urbit marketing copy wants me to believe all those things.

[urbit]

If you s/is/could be/, I would agree. I would say s/is/should not be/. That is, it is possible to screw this up and create "intimacy" (high coupling), but obviously I recommend against it.

Put it this way: when it's properly done, the jets (specific optimizations) are coupled to your compiler and libraries about the way your display server is coupled to your graphics driver. As a programmer you can't, don't and shouldn't know what if any GPU is executing your GL. Or at least, if you do - mistakes have been made.

Added to this is the fact that it's possible to obtain at least decent performance just by using standard basic math, eg, decrement. Yes, you can roll your own decrement - but at this point you are just being perverse.

[newuser88273]

So T-shirt spec is like the written law of Urbit; strangers can read it, we can't help that. But of course there are the unwritten laws and rules of polite speech, here in Urbit just as everywhere else. There are special occasions (you just know!) where you must use exactly the right phrases (you just know!)

Ahh, but she slips, uses the wrong phrase. Now everybody knows: she's a pervert! Rolling her own decrement, the little... Quick, freeze her out of the conversation. She shall speak no more.

But look, isn't she hot? Really, it could be nice... but alas, there's just no way around Urbit gov's cryptographic chastity belt locks...

[tromp]

My Binary Lambda Calculus is specified in a few paragraphs in http://www.ioccc.org/2012/tromp/hint.html and includes basic IO. It blc-zips to only 29 bytes (size of self-interpreter).

The 25-lines-of-obfuscated-C interpreter is on the very shirt that I wear on my (clickable) homepage picture.