66 ms·

Well, normally, if you want to decrement a, you write (dec a). But yes, if you want to write your own implementation of decrement, you could do it this way. It

by yarvin9 11y ago

Well, normally, if you want to decrement a, you write (dec a). But yes, if you want to write your own implementation of decrement, you could do it this way. It's just as bad an idea in Urbit as in any other language. Nock is a functional assembly language, so it's not meant as a human interface. I think you mean "increment" instead of "decrement." Yes, [4 0 1] is an increment formula in Nock; 4 is the increment operator, 0 dereferences a tree address in the subject, 1 is the root of the tree; so [4 0 1] means "increment the subject," where your subject is 42. If you know Lisp, you can think of Nock as Lisp without symbols or an environment; instead of having this hardcoded key-value store, the environment, you have a subject which is referenced with tree addresses (1 is the root, n2 is the left child, n2 + 1 is the right child). Is this horribly arcane? It doesn't seem that way to me, but de gustibus non disputandum.

openasocket 11y ago
Nock just seems deliberately obtuse. The website boasts that "Nock is also the easiest thing in the world to learn" and that the spec "gzips to 340 bytes", but I can't seem to make heads or tails of it. Sure, you can defend Nock by saying it's not meant to be used directly, but can you give any advantages Nock offers over anything else? Because lambda calculus is even easier to implement and is more intuitive.
- zaphar 11y ago
  So I get that Nock is hard to wrap your head around. But that's like complaining that your cpu's machine code is deliberately obtuse. You aren't going to be writing nock unless it's for fun. Hoon may be a little deliberately different which can be construed as obtuse but it actually takes less time than you might think to get up to speed in it.
  - openasocket 11y ago
    I still don't understand why this thing was chosen to be the basis for all of Urbit. What advantages do you get from building on top of Nock vs. lambda calculus or SKI combinators or anything else?
    - zaphar 11y ago
      I have no idea. I'm not Curtis. However, have you ever just wanted to burn it all down and start over? I mean all of it. lambda calculus, the von neuman architecture, all of it? Urbit is a little bit like that. When he says clean slate he really does mean clean slate. Which in a way is what makes it fun. It's so far out of your normal experience that it's delightful to play with. At least if you are someone like me anyway.
      - Dylan16807 11y ago
        Starting over is fine, but if you make choices that are deliberately awkward because the only reasonable ideas you have were done before, that's not a clean slate. That's a twisted mirror of existing designs.
    - yarvin9 11y ago
      I don't know that anyone has tried to build a practical system on top of SKI combinators, which are certainly simpler than Nock. It's probably quite hard. You can build a practical system around the lambda calculus, which is arguably as simple as Nock. But you don't build a practical system by building layers on top of a simple lambda interpreter; you do it by extending the simple lambda interpreter, until it's no longer simple. The critical feature of Nock is that it's very simple and you don't extend it, you layer on top of it. So, for instance, it's very easy to upgrade Hoon's syntax or semantics over the network in a live system, because the interpreter is a Nock interpreter and doesn't know anything about Hoon.
  - Niksko 11y ago
    Seems like (as I've said in every thread on Urbit) it just needs more developers and users so that we get the Urbit flavoured higher level languages.
- oldmanjay 11y ago
  I can give you one advantage from the generic perspective of a creator, in that I experience unbridled joy from using my own creations. From my point of view, no other justification need be made, since no one is in any way forced to use, understand, or even acknowledge my creations.
- 4ad 11y ago
  I don't know anything about urbit. I stared at the nock specification for about 3 minutes, just the symbolic specifications, not any explanation in english language, and I easily understood it. After just 3 minutes of staring at some symbols, I know everything there is to know about nock. There is no other assembly language with this property. It seems to me it not deliberately obtuse, but in fact it's very clear, simple, and understandable. I haven't looked at hoon and other things yet.
lisper 11y ago
> Lisp without symbols or an environment Why is that an advantage? The ability to give things names seems like a big win to me.
- derefr 11y ago
  Naming things is pushed up to a higher layer. The lower layers of the Internet don't care about names; why should the lower layers of a computation system? To be practical, though, I think the point here has to do with the idea that languages come and go, and their package namespaces along with them, but VMs stick around as long as useful libraries run on them... unless the VM is tied in some way or another to a language that has gone out of fashion. Think of the JVM: even if you're writing Clojure, you call Java functions by their Java names. Effectively, you have to know a (tiny) bit of Java to call those functions. Why? Because Java syntax assumptions are baked into JVM's module/function naming rules. Clojure functions end up with Java-like names too, after compilation. Clojure hides it from you, but to call a Clojure function from Scala, you can't write a tiny bit of Clojure; you have to write a tiny bit of Java. Naming rules have made Java the only first-class JVM citizen. Nock, on the other hand, defers the concept of naming up to the language/platform level. Effectively, each language running on Nock needs to make up a naming rule, and decide the canonical name (canonical to the language, not to the VM) for every available function itself. This means that there would be no de-facto "Urbit library ecosystem"; there couldn't be, as a particular arrangement of Urbit functions—a taxonomy—wouldn't be guaranteed to survive in any sensible manner between languages. Not all languages would have the concept of a "module", or a "package", etc. This could be seen as bad: every Urbit-derived language would need to effectively create its own ecosystem of "library taxonomies", manifests mapping from its module system out to function-space, making each language maintainer roughly like a Linux distro maintainer, consuming functions from "upstream" and packing them. But this lack of forced naming also has the potential to be very good: it creates the opportunity for taxonomies to be created separately from any particular language, and then consumed voluntarily by multiple languages. A taxonomy becomes its own first-class object, above "runtime" but below "language", where languages can pick a runtime+taxonomy to support. This, further, moves the creation of a "standard library" from the language authors to the taxonomy authors; languages "on" the same taxonomy become thinner bundles of syntax and compile-time features, while sharing all their stdlib algorithms, "primitive" data structures, and language "features" like GC (because that's mostly up to whether the data structure "primitives" provided by the particular taxonomy are implemented that way.)

by yarvin9 11y ago

openasocket 11y ago

Nock just seems deliberately obtuse. The website boasts that "Nock is also the easiest thing in the world to learn" and that the spec "gzips to 340 bytes", but I can't seem to make heads or tails of it. Sure, you can defend Nock by saying it's not meant to be used directly, but can you give any advantages Nock offers over anything else? Because lambda calculus is even easier to implement and is more intuitive.

zaphar 11y ago
So I get that Nock is hard to wrap your head around. But that's like complaining that your cpu's machine code is deliberately obtuse. You aren't going to be writing nock unless it's for fun. Hoon may be a little deliberately different which can be construed as obtuse but it actually takes less time than you might think to get up to speed in it.
- openasocket 11y ago
  I still don't understand why this thing was chosen to be the basis for all of Urbit. What advantages do you get from building on top of Nock vs. lambda calculus or SKI combinators or anything else?
  - zaphar 11y ago
    I have no idea. I'm not Curtis. However, have you ever just wanted to burn it all down and start over? I mean all of it. lambda calculus, the von neuman architecture, all of it? Urbit is a little bit like that. When he says clean slate he really does mean clean slate. Which in a way is what makes it fun. It's so far out of your normal experience that it's delightful to play with. At least if you are someone like me anyway.
    - Dylan16807 11y ago
      Starting over is fine, but if you make choices that are deliberately awkward because the only reasonable ideas you have were done before, that's not a clean slate. That's a twisted mirror of existing designs.
  - yarvin9 11y ago
    I don't know that anyone has tried to build a practical system on top of SKI combinators, which are certainly simpler than Nock. It's probably quite hard. You can build a practical system around the lambda calculus, which is arguably as simple as Nock. But you don't build a practical system by building layers on top of a simple lambda interpreter; you do it by extending the simple lambda interpreter, until it's no longer simple. The critical feature of Nock is that it's very simple and you don't extend it, you layer on top of it. So, for instance, it's very easy to upgrade Hoon's syntax or semantics over the network in a live system, because the interpreter is a Nock interpreter and doesn't know anything about Hoon.
- Niksko 11y ago
  Seems like (as I've said in every thread on Urbit) it just needs more developers and users so that we get the Urbit flavoured higher level languages.
oldmanjay 11y ago
I can give you one advantage from the generic perspective of a creator, in that I experience unbridled joy from using my own creations. From my point of view, no other justification need be made, since no one is in any way forced to use, understand, or even acknowledge my creations.
4ad 11y ago
I don't know anything about urbit. I stared at the nock specification for about 3 minutes, just the symbolic specifications, not any explanation in english language, and I easily understood it. After just 3 minutes of staring at some symbols, I know everything there is to know about nock. There is no other assembly language with this property. It seems to me it not deliberately obtuse, but in fact it's very clear, simple, and understandable. I haven't looked at hoon and other things yet.

lisper 11y ago

> Lisp without symbols or an environment Why is that an advantage? The ability to give things names seems like a big win to me.

derefr 11y ago
Naming things is pushed up to a higher layer. The lower layers of the Internet don't care about names; why should the lower layers of a computation system? To be practical, though, I think the point here has to do with the idea that languages come and go, and their package namespaces along with them, but VMs stick around as long as useful libraries run on them... unless the VM is tied in some way or another to a language that has gone out of fashion. Think of the JVM: even if you're writing Clojure, you call Java functions by their Java names. Effectively, you have to know a (tiny) bit of Java to call those functions. Why? Because Java syntax assumptions are baked into JVM's module/function naming rules. Clojure functions end up with Java-like names too, after compilation. Clojure hides it from you, but to call a Clojure function from Scala, you can't write a tiny bit of Clojure; you have to write a tiny bit of Java. Naming rules have made Java the only first-class JVM citizen. Nock, on the other hand, defers the concept of naming up to the language/platform level. Effectively, each language running on Nock needs to make up a naming rule, and decide the canonical name (canonical to the language, not to the VM) for every available function itself. This means that there would be no de-facto "Urbit library ecosystem"; there couldn't be, as a particular arrangement of Urbit functions—a taxonomy—wouldn't be guaranteed to survive in any sensible manner between languages. Not all languages would have the concept of a "module", or a "package", etc. This could be seen as bad: every Urbit-derived language would need to effectively create its own ecosystem of "library taxonomies", manifests mapping from its module system out to function-space, making each language maintainer roughly like a Linux distro maintainer, consuming functions from "upstream" and packing them. But this lack of forced naming also has the potential to be very good: it creates the opportunity for taxonomies to be created separately from any particular language, and then consumed voluntarily by multiple languages. A taxonomy becomes its own first-class object, above "runtime" but below "language", where languages can pick a runtime+taxonomy to support. This, further, moves the creation of a "standard library" from the language authors to the taxonomy authors; languages "on" the same taxonomy become thinner bundles of syntax and compile-time features, while sharing all their stdlib algorithms, "primitive" data structures, and language "features" like GC (because that's mostly up to whether the data structure "primitives" provided by the particular taxonomy are implemented that way.)