![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
To me, Nock is interesting just because it's somewhat minimalistic and yet interestingly different from other minimalistic languages.
However, you may be wondering why it's interesting not from my point of view, but from C.g. Yarvin's (Nock's creator) point of view. His reasons are quite different than mine. You can read them here if you want:
To summarize that link (although i am probably misunderstanding everything), the end goal is a greenfield redesign of the network stack, at least at the transport layer and above (and possibly below, and possibly also a redesign of the OS, at least as far as its interface to applications are concerned; i'm a little foggy on this); this is the 'Urbit' project. One part of Urbit is that the Urbit specification will include a standard specification of how an Urbit system can accept code to upgrade itself over the network. But standardizing that requires standardizing a programming language in which the code sent over the network is encoded (e.g. to define a VM). Existing VMs were deemed by Urbit's author as too complex to be suitable for basing the standard upon, because the author believes that good standards are minimalistic. Furthermore, Urbit is very functional and so there was a desire for its VM to be more functional, e.g. more like lambda calculus and less like a Turing machine, which makes e.g. the JVM and CLR undesirable.
So, faced with a dearth of languages suitable for VMs which had a really short specification and which had a functional style, he created one.
Nock by itself seems too inefficient to be a good VM; there are no dedicated instructions for integer subtraction or for floating point arithmetic, for example. The Nock author seems to think that this can be solved by having optimizing compilers that recognize things like subroutines that are doing integer substraction and replace them with optimized appropriate primitives on the underlying platform (e.g. integer subtraction instructions), a mechanism he calls 'jets'.
"Nock is a stateless virtual machine defined in 200 words. The Nock machine is sealed - all execution is “pure.” Nock’s goal is extreme commoditization of computing semantics." -- http://web.archive.org/web/20131005165939/http://www.urbit.org/2013/08/22/Chapter-0-intro.html
" Nock is a virtual machine, like the Java VM or Microsoft CLR. Just as you execute Java by compiling it to the JVM, you execute Hoon by compiling it to Nock.
Do you need to learn Nock to learn Hoon? In theory, no, just as you don’t need to know anything about the JVM to learn Java. Indeed, in theory we could compile Hoon to the JVM (or Java to Nock). What’s the difference between Nock and the JVM, anyway? Why do we need a new virtual machine? And since we’ll only be programming in Hoon, why do we care how Hoon is executed?
There is no formal difference between Nock and the JVM. In theory, both are Turing-complete computers. In practice, they have just about nothing in common.
The main practical difference is that Nock is two orders of magnitude simpler. The JVM spec is a book. The Nock spec is 200 words; it fits on a T-shirt; it gzips to 372 bytes. There are lots of other differences, but all follow from this.
Why does size matter? The goal of any programming language is to become a standard. Universal standardization equals world domination. The simpler a specification is, the easier to standardize. Nock is a practical interpreter as simple as the most frozen and fundamental of protocols or formats: IPv4, XML, JSON. A 200-word spec needs a standards process like a fish needs swim lessons. When a T-shirt goes to war with a book, it’s like tanks against cavalry - or should be, anyway.
Since every program in Hoon (including the Hoon compiler) reduces to Nock, every program in Hoon inherits Nock’s precision. If two Nock interpreters produce different results, one is wrong, and it is always easy to tell which - without a “standards lawyer.” Can we imagine the end of incompatiblity?
Essential to actually realizing this promise is a second difference between Nock and the JVM, which is that the JVM can call Unix system calls and libraries, and Nock can’t. Nock has no “native methods” or foreign-function interface. Nor is it ever extended, embellished, forked, improved or advanced.
Java began as a portable language; so did C. Most Java today is server-side Java, dependent no less than C on library and OS configuration. It is possible to write portable Java; it is possible to write portable C. It is not possible to write unportable Nock or Hoon. It is also not possible to write insecure Nock or Hoon, unless your interpreter is so broken there’s an actual hole in its skull. " -- http://web.archive.org/web/20131005165939/http://www.urbit.org/2013/08/22/Chapter-0-intro.html
" So let’s learn Nock! But wait - why learn Nock? After all, we’re going to be programming in Hoon, not Nock.
Like JVM bytecode, Nock is as inscrutable as assembly language. In fact, you can think of it as a sort of “functional assembly language.” There are sometimes reasons to program in real assembly language. There is never a reason to program in Nock. Except to learn Nock.
Indeed, it is not necessary for the Hoon programmer to learn Nock. We recommend it strongly, however, because Hoon has a very special relationship with Nock - not unlike the relationship between C and assembly language.
Just as C is a very shallow layer over the raw CPU, Hoon is a very shallow layer over raw Nock - often little more than a macro. If you try to learn C without understanding the CPU under it, you will be forever bemused by why it works the way it does. " -- http://web.archive.org/web/20131005221950/http://www.urbit.org/2013/08/22/Chapter-2-nock.html
" Nock, a minimal virtual machine
Nock is a homoiconic combinator algebra, not much fancier than SKI combinators. The spec fits on a T-shirt and gzips to 340 bytes. Nock's data model is simple: a noun is an atom or a cell. An atom is any natural number. A cell is an ordered pair of any two nouns.
Nock cannot create cycles and needs no GC. Its only arithmetic operator is increment, so it is not inherently efficient; an efficient Nock interpreter works by recognizing standard Nock formulas and matching them to pre-written manual optimizations. We never extend Nock or call out to Unix from it. " -- http://urbit.org/
