7 ms·

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

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." What do people expect when they read a thing like that? I don't know about you, bit I'd expect that I could ignore the obfuscated strangeness of their higher level languages etc and just implement stuff to that minimal spec. So you expect you can do that. But you can't. That minimal spec might as well not exist; you can't just read it and go on to implement, say, a programming language on top of Urbit. "But you can!" you might object. Try it. Read nothing but that spec and implement, say, a tiny BASIC on top of it. Compile some simple programs. Run them. Now, what happens? Nothing, for now. But look, my processor core is heating up. Something must be happening! Just wait. Wait. Wait. No, still nothing. Wait some more. Just a few years, maybe? No, still nothing (except heat). Etc. So no, that elegant spec doesn't give you anything but a way to heat your computing cabinet. Realizing this, I put Urbit in the "suspicious, may be a con" bin. Hasn't escaped from there, yet.

perlgeek 12y ago
> 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 12y ago
  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.
  - perlgeek 12y ago
    Does that mean the IO events are part of the t-shirt sized spec?
    - yebyen 12y ago
      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 12y ago
        Strictly speaking, this isn't true. All of these components have code in the C/unix layer.
  - clarkm 12y ago
    > 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 12y ago
      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.
- newuser88273 12y ago
  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 12y ago
    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 12y ago
      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.
- tromp 12y ago
  My Binary Lambda Calculus is specified in a few paragraphs in http://www.ioccc.org/2012/tromp/hint.html 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.
wmf 12y ago
Run them. Now, what happens? Nothing, for now. Can you explain what the actual problem is? "Only X lines of code" puffery is endemic in programming so I'm not sure why Urbit should be singled out.
easytiger 12y ago
> "The spec fits on a T-shirt and gzips to 340 bytes. If the spec expands does the guy wearing the t-shirt have to eat lots of pizza?

perlgeek 12y ago

> 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 12y ago
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.
- perlgeek 12y ago
  Does that mean the IO events are part of the t-shirt sized spec?
  - yebyen 12y ago
    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 12y ago
      Strictly speaking, this isn't true. All of these components have code in the C/unix layer.
- clarkm 12y ago
  > 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 12y ago
    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.
newuser88273 12y ago
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 12y ago
  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 12y ago
    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.
tromp 12y ago
My Binary Lambda Calculus is specified in a few paragraphs in http://www.ioccc.org/2012/tromp/hint.html 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.

wmf 12y ago

Run them. Now, what happens? Nothing, for now. Can you explain what the actual problem is? "Only X lines of code" puffery is endemic in programming so I'm not sure why Urbit should be singled out.

easytiger 12y ago

> "The spec fits on a T-shirt and gzips to 340 bytes. If the spec expands does the guy wearing the t-shirt have to eat lots of pizza?