9 ms·

I'm not involved with the project, but here's what I got: - Programming/computing is very new. - Many mistakes were made. - Due to human stuff, mistakes stic

I'm not involved with the project, but here's what I got: - Programming/computing is very new. - Many mistakes were made. - Due to human stuff, mistakes stick around. - It's pretty clear that computing as it is today is very far from optimal. - What can computing/programming look like if we start from a clean slate?

mjfl 11y ago
No. I did a project on Urbit for an OS course. It is deliberately obfuscated. For example, take the specification of Nock, the lisp-like "assembly code": https://github.com/cgyarvin/urbit/blob/master/doc/book/1-nock.markdown https://github.com/cgyarvin/urbit/blob/master/doc/book/1-noc... The symbol evaluation is designed to take whoever is trying to program in Nock in circles around the specification. It makes even the most basic operations unnecessarily verbose and hard to memorize. To increment a number, you must put it adjacent to the expression [4 0 1]. So 42 [4 0 1] evaluates to 43, after several steps. There is no reason that an "assembly code" should have a decrement operator that must be evaluated more than once in order to get to the final expression. Hoon, the "high-level" langauge is worse. A function to decrement an input by one is specified by the expression: (a=. =+(b=0 |-(?:(=(a +(b)) b $(b +(b)))))) Like a postmodernist artists asks "what makes art?" and answers that there can be no objective answer, Urbit asks the question "What makes good software engineering?" Unfortunately there are many objectively bad design decisions you can make in software engineering. Forcing even the most basic operations to be incredibly verbose and unintelligible is one of them.
- state 11y ago
  Is your project online anywhere?
  - mjfl 11y ago
    It is not. It might still be on the school's network, but I did it back in the spring and our department's network admin might have wiped my account since I graduated. Didn't accomplish too much to be honest, as might be hinted at by the frustration underlying my post.
    - yarvin9 11y ago
      You can certainly blame our (old) doc for that. Sorry for the bad experience -- we're definitely still at the stage where I wouldn't expect people to be playing with Urbit and not asking for handholding. Even more so this spring.
- 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?
- derefr 11y ago
  > There is no reason that an "assembly code" should have a decrement operator that must be evaluated more than once in order to get to the final expression. Doesn't this ignore the concept of Urbit's "jets"? You write code that does things in a stupid-but-canonical way; it's then the runtime's responsibility to take canonical patterns and provide optimized implementations. The cool thing is that you get to write a naive interpreter for all existing code in a couple-hundred lines, while also being able to write a good interpreter that makes the same code run quickly. Like regular Lua vs. LuaJIT, but much moreso.
  - Rusky 11y ago
    Jets are pretty ignorable. Pattern-matching an incredibly obtuse language against a distributed database of machine language is not in any way comparable to LuaJIT, nor do I see any good way for it to do any meaningful optimization beyond e.g. replacing peano numbers with machine integers.
    - derefr 11y ago
      I would note that Nock is a representation of an ISA for an abstract machine, not a language. Aren't loop-unrolled x64 code, LLVM bitcode, BEAM bytecode, etc., also "obtuse"? In fact, the best thing to compare it to, in my mind, would be RarVM bytecode: another ISA designed to be "forward-compatible" in the sense of ensuring that even the first interpreter will be able to run code from years in the future. Nobody ever sees RarVM bytecode; nobody even realized it existed for decades. It was just there, an implementation detail of the RAR encoding/decoding process, doing its job of enabling the RAR format to change its algorithm over time.
      - Rusky 11y ago
        Abstract ISAs are still languages. And at least loop-unrolled x64 code describes what it's doing straightforwardly, instead of throwing around redundant mathematical abstractions and hoping the interpreter will magically pattern-match them away.

mjfl 11y ago

No. I did a project on Urbit for an OS course. It is deliberately obfuscated. For example, take the specification of Nock, the lisp-like "assembly code": https://github.com/cgyarvin/urbit/blob/master/doc/book/1-nock.markdown https://github.com/cgyarvin/urbit/blob/master/doc/book/1-noc... The symbol evaluation is designed to take whoever is trying to program in Nock in circles around the specification. It makes even the most basic operations unnecessarily verbose and hard to memorize. To increment a number, you must put it adjacent to the expression [4 0 1]. So 42 [4 0 1] evaluates to 43, after several steps. There is no reason that an "assembly code" should have a decrement operator that must be evaluated more than once in order to get to the final expression. Hoon, the "high-level" langauge is worse. A function to decrement an input by one is specified by the expression: (a=. =+(b=0 |-(?:(=(a +(b)) b $(b +(b)))))) Like a postmodernist artists asks "what makes art?" and answers that there can be no objective answer, Urbit asks the question "What makes good software engineering?" Unfortunately there are many objectively bad design decisions you can make in software engineering. Forcing even the most basic operations to be incredibly verbose and unintelligible is one of them.

state 11y ago
Is your project online anywhere?
- mjfl 11y ago
  It is not. It might still be on the school's network, but I did it back in the spring and our department's network admin might have wiped my account since I graduated. Didn't accomplish too much to be honest, as might be hinted at by the frustration underlying my post.
  - yarvin9 11y ago
    You can certainly blame our (old) doc for that. Sorry for the bad experience -- we're definitely still at the stage where I wouldn't expect people to be playing with Urbit and not asking for handholding. Even more so this spring.
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?
derefr 11y ago
> There is no reason that an "assembly code" should have a decrement operator that must be evaluated more than once in order to get to the final expression. Doesn't this ignore the concept of Urbit's "jets"? You write code that does things in a stupid-but-canonical way; it's then the runtime's responsibility to take canonical patterns and provide optimized implementations. The cool thing is that you get to write a naive interpreter for all existing code in a couple-hundred lines, while also being able to write a good interpreter that makes the same code run quickly. Like regular Lua vs. LuaJIT, but much moreso.
- Rusky 11y ago
  Jets are pretty ignorable. Pattern-matching an incredibly obtuse language against a distributed database of machine language is not in any way comparable to LuaJIT, nor do I see any good way for it to do any meaningful optimization beyond e.g. replacing peano numbers with machine integers.
  - derefr 11y ago
    I would note that Nock is a representation of an ISA for an abstract machine, not a language. Aren't loop-unrolled x64 code, LLVM bitcode, BEAM bytecode, etc., also "obtuse"? In fact, the best thing to compare it to, in my mind, would be RarVM bytecode: another ISA designed to be "forward-compatible" in the sense of ensuring that even the first interpreter will be able to run code from years in the future. Nobody ever sees RarVM bytecode; nobody even realized it existed for decades. It was just there, an implementation detail of the RAR encoding/decoding process, doing its job of enabling the RAR format to change its algorithm over time.
    - Rusky 11y ago
      Abstract ISAs are still languages. And at least loop-unrolled x64 code describes what it's doing straightforwardly, instead of throwing around redundant mathematical abstractions and hoping the interpreter will magically pattern-match them away.