3 ms·
I think you won't be surprised that a) I don't disagree with any of what you wrote, b) I don't think it's super on topic, and c) I think claim b isn't obvious.
by geofft 7y ago
I think you won't be surprised that a) I don't disagree with any of what you wrote, b) I don't think it's super on topic, and c) I think claim b isn't obvious.
For the sake of argument, let's say "a deterministic, permanent virtual machine definition" is a desirable quality. LLVM IR at the latest version is a poor tool for this, yes. But LLVM IR at some fixed version of LLVM works fine. It's weird because now you can't use up-to-date versions of LLVM with it, but it's doable: pNaCl did exactly this, and dealt with forking the LLVM codebase in order to freeze the IR definition. If you don't like that, Java bytecode at some fixed version of the JVM probably works, .NET CIL probably works, WASM works (although it didn't exist when Nock was designed), etc. In fact, Urbit's web page compares itself to the JVM and WASM. Perhaps you could use Infocom's Z-machine, or BPF, or something. Alternatively, maybe you just want i386 assembly or ARM2 assembly or MIPS II or whatever. With a validator to make sure you're not using undefined/newer operations, and with some restrictions on threading and input (including input randomness), they're deterministic and permanent, and you've got a wide array of software tools for generating it.
But I think "why would anyone want a deterministic, permanent virtual machine definition" needs to be answered, if we're going to have any idea of what the topic of this comment chain is. We're talking about whether Nock and Hoon are intentionally obscure, which means talking about whether there exist less-obscure things that solve the same problem.
Moldbug's claim - which, even if he doesn't say it in as many words, seems obvious from the history of this conversation and how participants have read his work - is that a) there exists a set of constraints that describe a thing worth wanting for a real-world application, and one of those constraints is that it be a deterministic, permanent virtual machine, and b) his invention, Nock, is a novel solution that satisfies those constraints. If you don't have that, then Nock is, as 'xkapastel puts it, "somewhere in between an art project and a pyramid scheme."
So, for your use case, I might ask you whether the JVM or i386 assembly or whatever answers it, but for the use case of Urbit, we need to figure out what exactly those constraints are. And then we can evaluate whether Nock and Hoon are novel because they solve problems that haven't been solved, or whether indeed there exists a less-obscurantist solution that satisfies the constraints, and thus Nock and Hoon are simply exercises in "look how smart I am" / "you'd never have gotten this from mainstream software engineering, aren't you glad you listened to me" / whatever.
In other words, I think we are off-topic by discussing the merits of Nock in the abstract, and then constructing scenarios in which we find Nock valuable. (And, to the extent that Nock and Urbit as a whole are potentially exercises in crypto-fascist-advocacy, this would be playing into Moldbug's plan - Moldbug's philosophical work takes much the same approach, of making an interesting-sounding claim and then trying to convince you it has real-world relevance because it's just so interesting-sounding and just so different from mainstream opinions that it must have value, and it too can be defeated by keeping "Okay, what problem are you trying to solve" front and center, and therefore Moldbug wants you to forget about that. If we say "Nock is cool, but I wish it weren't named after an anti-Semite," we make people wonder about the anti-Semite; if we say "Nock is, actually, an unnecessarily-complicated rehash of things that already existed, named after an anti-Semite and dressed up to sound cool," then people understand what's going on.) We should first figure out what the problem Urbit needs Nock for, and then we can have a fair discussion about whether Nock is a meaningful invention.
Incidentally, https://ngnghm.github.io/blog/2016/06/11/chapter-10-houyhnhnms-vs-martians/ https://ngnghm.github.io/blog/2016/06/11/chapter-10-houyhnhn... is an argument that Urbit, as a project, doesn't need a deterministic, permanent virtual machine definition at all - that there isn't a need for future-proof reproducible behavior in the system, that the constraint on using the Nock VM makes Urbit perform poorly, that the escape hatches to help Urbit's performance undermine the whole project (apparently the Urbit runtime statically recognizes a particular Markdown implementation in Nock and replaces it with a call to a different Markdown implementation in C), that the "simplicity" of Nock makes it harder to understand the high-level purpose of programs and defeats Urbit's claim that programs are understandable, that the Nock VM prevents an Urbit user from doing effective runtime resource control which would be a useful feature in practice, etc.
- kragen 7y ago"LLVM IR at some fixed version" seems on the face of it like a reasonable attack on the problem, yes, and you can get close to solving the reproducibility problem that way. But you can't actually solve it, because LLVM IR is two to four orders of magnitude more complicated than Nock, so it's full of definitional ambiguities, which mean that in practice it is defined by the behavior of its implementation, which is full of bugs, some of which must be fixed because they are security holes. Even without fixing the bugs, its behavior will vary depending on what compiler it's built with and what CPU and OS it runs on. Operations as commonplace as sequences of two floating-point additions can give different results, sometimes radically different, for example in the presence or absence of guard digits, to say nothing of non-IEEE-754-compliant hardware like Intel Gen. In this particular case GCC has a flag, -fstore-float, to get deterministic behavior on some hardware, so you can read about the issue. The same flaw (for this purpose) is present in JVM bytecode, i386 machine code, ARM2 machine code, CIL, and wasm. (e)BPF and the Z-machine might be plausible bases for a solution on those grounds, but you'd still need a lot of work to be sure you'd rooted out the sources of irreproducibility. Now, as I said, I'm not convinced that Nock in practice solves the problem it sets out to, and Faré's criticisms that you have helpfully linked to are a major reason for that. But nothing that existed does in fact set out to solve that problem, much less succeed. It's true that some other computational basis would also have worked, given enough effort; but I think you are seriously underestimating the amount of effort required. I do think my previous comment already explained why I think rigorous computational reproducibility is valuable.
- geofft 7y agoI mean, I'm happy to say that neither Nock nor anything else solves the problem, and I think that gets to the same conclusion: Nock is not a useful/worthwhile invention, it is an obscurantist rehashing of old ideas with more emphasis on looking elegant than being elegant. That's what I'm pushing back on. There's an idea that because Nock exists and looks cool, it must mean something. And just like the idea that because the rest of the blog where Nock was introduced exists and looks cool, it must be a meaningful philosophical contribution, it's not true. For instance - Nock, as both its advocates and detractors readily point out, is too low-level to be a language to actually write in. So that means you're writing in some other language which has an implementation in Nock (or perhaps in Nock-and-hopefully-equivalent-C, how's that for security risk surface). And that other language is rich enough to have security issues just like LLVM, and it's either frozen and you accept the potential insecurity, or it's patchable and you accept the potential nonreproducibility. You haven't solved the problem, you've just shoved it up one level so you can get a cool blog post about your elegant lower level. I agree, I'd love to have a language that solves the problem you describe. I don't think Nock is tangibly closer to solving it than other things are, nor do I think it is tangibly closer to solving the Urbit system's needs than other things are, nor do I think it has some other unspecified merit. And I certainly feel no obligation to figure out some use case which would make Nock look meritorious. (And, again, Google shipped pNaCl as a way to run untrusted native code. They had to do something to deal with the very concerns you raise. And unlike Urbit, the stakes for getting it wrong were very real.)