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