5 ms·

It's not that the author is lying per se about the claims, it's that the claims are somewhere between meaningless and pointless. What is the difference between

• kragen 7y ago
  LLVM IR treats code as data, like Nock, because LLVM IR, like Nock, is systems software, not metamathematics. Combinatory logic, by contrast, is metamathematics, and in combinatory logic, if you want numbers or lists, much less byte strings, you have to build them out of code, using Church numerals and the like. So, in this way, Nock is similar to LLVM IR and different from combinatory logic. There are a variety of practical benefits to representing code as data in this way, which I do not feel the desire to explain in detail at the moment, but suffice it to say that all practical programming languages and virtual machines share this property with Nock. So, you might ask, do there exist purposes for which Nock is preferable to LLVM IR? Well, I don't know, but Moldbug's intent was for the answer to be "yes"; there are problems he wanted to solve which LLVM IR definitely does not solve. Foremost among these is getting people to impugn one another's competence on the orange website. No, wait, foremost among these is determinacy and permanence: it is the intent that the result of any Nock computation be deterministic and unchanging through all time. The meaning of LLVM IR, by contrast, changes every time someone fixes a bug in an LLVM backend, or introduces a new one. You will note that this way that Nock differs from LLVM IR is also a way that SK-combinators differ from LLVM IR. SK-combinators also provide a deterministic computational system that is simple enough that we can imagine not changing it. That is why it was necessary to explain how Nock differs from SK-combinators. So Nock shares some crucial attributes with combinatory logic and others with LLVM IR, but neither system has the combination of characteristics that Nock does. Now, why would anyone want a deterministic, permanent virtual machine definition? I don't know why Moldbug wanted it. There are some reasons that I want it; I think reproducible computational experiments are an important way to communicate human knowledge, a way that could perhaps drastically reduce the loss of knowledge from one generation to the next, accelerating the ratchet of philosophical progress which made the modern world possible. However, I don't want to have anything to do with Urbit! I don't want to use a virtual machine that people credibly say is named after a famous anti-Semite. I also think some of the technical choices in Nock are questionable and may turn out to be fatally flawed. I despair somewhat in writing this comment because I feel that everything I'm saying is painfully obvious, but obviously there is something about the people I am talking to that makes it not obvious to them. But since I do not know what that is, it seems likely that my own words will be just as incomprehensible to them as Moldbug's voluminous, and to me perfectly clear, explanations. And the level of viciousness in the air makes me think that probably those people will respond to their own incomprehension by launching personal attacks on me, as they have been on each other. It's pathetic.
  • deleted 7y ago
    [deleted]
  • 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.