6 ms·

We're not trying to be intentionally obtuse. In general, we try to only create new names when the old names are for a sufficiently different concept. Perhaps

by pcmonk 11y ago

We're not trying to be intentionally obtuse. In general, we try to only create new names when the old names are for a sufficiently different concept. Perhaps we go slightly too far in doing this, but much of the "the terms are alien" feeling comes from the concepts beings actually different than you're used to. This is the start of a bottom-up style tutorial, but if you're interested in a top-down tutorial, may I suggest this one from one of our open-source contributors: http://hidduc-posmeg.urbit.org/home/pub/hoon-intro/ http://hidduc-posmeg.urbit.org/home/pub/hoon-intro/

Avshalom 11y ago
Well I mean of course you have to say that, kinda ruins the joke if you keep elbowing people and going "pretty clever of us eh?"
cwyers 11y ago
> In general, we try to only create new names when the old names are for a sufficiently different concept. You renamed the godforsaken PUNCTUATION, man. What exactly is the different concept behind an equals sign in Urbit that you have to call it tis? Or the colon, what conceptually did you change about the colon that it's got to be a col or the comma that it's a com?
- pcmonk 11y ago
  This is true and is an exception. Even though punctuation is punctutation, we speak it so much more than most other people, so we've found it convenient to give it convenient, one-syllable names. Using the new names is, of course, completely optional. End-users will never even see them.
- urbit 11y ago
  How many times a day do you want to say "percent equals" or "tilde ampersand," rather than "centis" or "sigpam"? Worse, you may not spend a lot of time reading code out loud, but when you read your brain still thinks the sounds. Of course, you're free to prefer keywords to digraphs. But sometimes I worry that there's a reason the 787 looks just like the 707 [1], and it's not at all about airplanes... [1] http://idlewords.com/talks/web_design_first_100_years.htm http://idlewords.com/talks/web_design_first_100_years.htm
  - JoshTriplett 11y ago
    > How many times a day do you want to say "percent equals" or "tilde ampersand," Zero if I can help it. Even if I'm talking about code aloud, I normally do so semantically, saying what the code is doing, because people are more than capable of reading the code itself. (Same premise as commenting code.) If I'm actually reading the exact symbols aloud, a rare occurrence, then I'll say things like "mod equal" or "mod eq", "tilde and", etc. If I'm reading "#include <stdio.h>", I'll say "include standard I O", not "pound include space angle s t d i o dot h angle newline". > Worse, you may not spend a lot of time reading code out loud, but when you read your brain still thinks the sounds. No, it absolutely doesn't. Learning to avoid reading-aloud internally is one of the first things taught in speed-reading of prose, and the same concept applies to programming. > Of course, you're free to prefer keywords to digraphs. But sometimes I worry that there's a reason the 787 looks just like the 707 [1], and it's not at all about airplanes... That may be, but what you've done here is on par with APL saying "you need a completely non-standard keyboard and character set to program this language", but worse. If you want to introduce new names for symbols, that's a separate exercise from trying to make a new programming language; the latter is quite hard enough.
    - urbit 11y ago
      But worse? I assure you that we're not shipping Urbit with non-standard keyboards printed with "com" rather than ",". If these syllables rub you the wrong way, you're perfectly free to pronounce them any way you like. Most people aren't speed-readers. I am, but only because I learned at an early age. I don't know anyone who speed-reads code in the sense you mean.
      - eru 11y ago
        The grandparents post's first argument about semantic reading was much more important than the speed reading bit.
        urbit 11y ago
        This works fine for C, which is a keyword language. What you'll find if you look at Hoon is about 100 combinator runes, which are digraphs like "%=" ("centis") or "|-" ("barhep"). (There is of course a power-law usage distribution -- a few common runes dominate.) If we had to invent and remember semantic names for each of these runes, that binding would really be a lot of work to remember. We could say "mutate" instead of "centis" and "loop" instead of "barhep". Remembering these bindings would be quite a lot of work. Of course, we could use reserved words directly; you can experiment with translating Hoon into reserved words. (The earliest experiments used keywords with a sigil, like ":loop".) To my eye the keywords look hideously verbose and are easily confused with symbols. You also lose the ability to classify, say, "|=" and "|-", as closely related runes. This is especially useful with unusual, rarely used runes; what is "|/"? You might not know, but you know that it starts with "|", so it makes a core.
melloclello 11y ago
I found this tutorial somewhat more cogent than most of the previous literature... I don't mean to be a dick but did Curtis write this one or someone else?
mst 11y ago
Having watched the mental carnage caused by git's re-use of names that older VCSen used for different things afflict multiple people (myself included) I do rather see your point. On the other hand, I really, really think that a set of englishified versions would be helpful as a newbie tool - in the same way that I often encourage early stage perl hackers to 'use English;' until the shorter names wedge themselves into their brain. Would doing that be as simple as something like += if ?: and etc. and etc. ? I think I can appreciate that once you're used to the runic versions everything is fine but, well, when I talked about urbit having a vi-like cliff-ish learning curve curtis replied talking about putting up ropes, and this seems like a pretty reasonable rope.
- juped 11y ago
  We definitely don't have Linus's streak of user-interface malice. (Git-related mental carnage has taken its toll on many urbit developers as well, alas.) What you suggest reminds me of Lisp's infamous "M-expressions", but worse, because the lack of reserved words in Hoon is the most immediate tangible benefit of our syntax. We're homoiconic, and syntax looks unambiguously like syntax (and is actually extremely regular). It's difficult to make the assertion that there really isn't much of a learning curve stick in a HN comment, unfortunately - it's based on experience learning the system myself, and helping others learn it on talk. It hasn't been anything syntax-related that trips up people actually learning the language, certainly - it's just something superficial that's easy to comment on on websites, as we've all seen around Lisp or Perl or even Python (whitespace-indented blocks). To answer you directly, runes are the tag in the tagged union that is the type of our AST, not any kind of identifier. (Perl would probably let you assign pieces of syntax to identifiers, of course...) For example, if you have the following Hoon: |= a=@ ?~ a ~| %decrement-underflow !! =| b=@ |- ^- @ ?: =(+(b) a) b $(b +(b)) the associated AST (a noun of type ++twig) is [ %brts p=[%bark p=%a q=[%axil p=[%atom p=~.]]] q [ %wtsz p=[%.y p=~ q=~[%a]] q [ %sgbr p [ %dtzz p=%tas q=2.663.495.029.034.430.894.880.199.458.246.708.989.383.632.228 ] q=[%zpzp ~] ] r [ %tsbr p=[%bark p=%b q=[%axil p=[%atom p=~.]]] q [ %brhp p [ %kthp p=[%axil p=[%atom p=~.]] q [ %wtcl p=[%dtts p=[%dtls p=[%cnzz p=~[%b]]] q=[%cnzz p=~[%a]]] q=[%cnzz p=~[%b]] r=[%cnts p=~[%$] q=~[[p=~[%b] q=[%dtls p=[%cnzz p=~[%b]]]]]] ] ] ] ] ] ] (To get this, I just ran ++ream, our compiler's frontend, on that code sample.) It would be as simple as dropping in an alternate parser there that looked for, e.g., 'if' rather than '?:', which isn't actually hard because our parser combinators are really easy to use. (The actual Hoon parser is very old and due for a cleanup, unfortunately, but conceptually is not very complicated.) I wouldn't endorse it myself, but perhaps in the future of the project someone will find it a useful thing to do and do it. It would definitely clash with the language's design sensibilities in a way that "use English" doesn't clash with Perl's - Hoon is somewhat more picky (though, what language isn't?). Edit: I completely forgot that I was going to include a hypothetical version of the above with keywords. Here: defgate a=@ nil? a error %decrement-underflow dim b=@ runtrap cast-to @ if inc(b) == a b replace b with inc(b) in this (The keywords are silly, but please imagine better ones.)

by pcmonk 11y ago

Avshalom 11y ago

Well I mean of course you have to say that, kinda ruins the joke if you keep elbowing people and going "pretty clever of us eh?"

cwyers 11y ago

> In general, we try to only create new names when the old names are for a sufficiently different concept. You renamed the godforsaken PUNCTUATION, man. What exactly is the different concept behind an equals sign in Urbit that you have to call it tis? Or the colon, what conceptually did you change about the colon that it's got to be a col or the comma that it's a com?

pcmonk 11y ago
This is true and is an exception. Even though punctuation is punctutation, we speak it so much more than most other people, so we've found it convenient to give it convenient, one-syllable names. Using the new names is, of course, completely optional. End-users will never even see them.
urbit 11y ago
How many times a day do you want to say "percent equals" or "tilde ampersand," rather than "centis" or "sigpam"? Worse, you may not spend a lot of time reading code out loud, but when you read your brain still thinks the sounds. Of course, you're free to prefer keywords to digraphs. But sometimes I worry that there's a reason the 787 looks just like the 707 [1], and it's not at all about airplanes... [1] http://idlewords.com/talks/web_design_first_100_years.htm http://idlewords.com/talks/web_design_first_100_years.htm
- JoshTriplett 11y ago
  > How many times a day do you want to say "percent equals" or "tilde ampersand," Zero if I can help it. Even if I'm talking about code aloud, I normally do so semantically, saying what the code is doing, because people are more than capable of reading the code itself. (Same premise as commenting code.) If I'm actually reading the exact symbols aloud, a rare occurrence, then I'll say things like "mod equal" or "mod eq", "tilde and", etc. If I'm reading "#include <stdio.h>", I'll say "include standard I O", not "pound include space angle s t d i o dot h angle newline". > Worse, you may not spend a lot of time reading code out loud, but when you read your brain still thinks the sounds. No, it absolutely doesn't. Learning to avoid reading-aloud internally is one of the first things taught in speed-reading of prose, and the same concept applies to programming. > Of course, you're free to prefer keywords to digraphs. But sometimes I worry that there's a reason the 787 looks just like the 707 [1], and it's not at all about airplanes... That may be, but what you've done here is on par with APL saying "you need a completely non-standard keyboard and character set to program this language", but worse. If you want to introduce new names for symbols, that's a separate exercise from trying to make a new programming language; the latter is quite hard enough.
  - urbit 11y ago
    But worse? I assure you that we're not shipping Urbit with non-standard keyboards printed with "com" rather than ",". If these syllables rub you the wrong way, you're perfectly free to pronounce them any way you like. Most people aren't speed-readers. I am, but only because I learned at an early age. I don't know anyone who speed-reads code in the sense you mean.
    - eru 11y ago
      The grandparents post's first argument about semantic reading was much more important than the speed reading bit.
      - urbit 11y ago
        This works fine for C, which is a keyword language. What you'll find if you look at Hoon is about 100 combinator runes, which are digraphs like "%=" ("centis") or "|-" ("barhep"). (There is of course a power-law usage distribution -- a few common runes dominate.) If we had to invent and remember semantic names for each of these runes, that binding would really be a lot of work to remember. We could say "mutate" instead of "centis" and "loop" instead of "barhep". Remembering these bindings would be quite a lot of work. Of course, we could use reserved words directly; you can experiment with translating Hoon into reserved words. (The earliest experiments used keywords with a sigil, like ":loop".) To my eye the keywords look hideously verbose and are easily confused with symbols. You also lose the ability to classify, say, "|=" and "|-", as closely related runes. This is especially useful with unusual, rarely used runes; what is "|/"? You might not know, but you know that it starts with "|", so it makes a core.

melloclello 11y ago

I found this tutorial somewhat more cogent than most of the previous literature... I don't mean to be a dick but did Curtis write this one or someone else?

mst 11y ago

Having watched the mental carnage caused by git's re-use of names that older VCSen used for different things afflict multiple people (myself included) I do rather see your point. On the other hand, I really, really think that a set of englishified versions would be helpful as a newbie tool - in the same way that I often encourage early stage perl hackers to 'use English;' until the shorter names wedge themselves into their brain. Would doing that be as simple as something like += if ?: and etc. and etc. ? I think I can appreciate that once you're used to the runic versions everything is fine but, well, when I talked about urbit having a vi-like cliff-ish learning curve curtis replied talking about putting up ropes, and this seems like a pretty reasonable rope.

juped 11y ago
We definitely don't have Linus's streak of user-interface malice. (Git-related mental carnage has taken its toll on many urbit developers as well, alas.) What you suggest reminds me of Lisp's infamous "M-expressions", but worse, because the lack of reserved words in Hoon is the most immediate tangible benefit of our syntax. We're homoiconic, and syntax looks unambiguously like syntax (and is actually extremely regular). It's difficult to make the assertion that there really isn't much of a learning curve stick in a HN comment, unfortunately - it's based on experience learning the system myself, and helping others learn it on talk. It hasn't been anything syntax-related that trips up people actually learning the language, certainly - it's just something superficial that's easy to comment on on websites, as we've all seen around Lisp or Perl or even Python (whitespace-indented blocks). To answer you directly, runes are the tag in the tagged union that is the type of our AST, not any kind of identifier. (Perl would probably let you assign pieces of syntax to identifiers, of course...) For example, if you have the following Hoon: |= a=@ ?~ a ~| %decrement-underflow !! =| b=@ |- ^- @ ?: =(+(b) a) b $(b +(b)) the associated AST (a noun of type ++twig) is [ %brts p=[%bark p=%a q=[%axil p=[%atom p=~.]]] q [ %wtsz p=[%.y p=~ q=~[%a]] q [ %sgbr p [ %dtzz p=%tas q=2.663.495.029.034.430.894.880.199.458.246.708.989.383.632.228 ] q=[%zpzp ~] ] r [ %tsbr p=[%bark p=%b q=[%axil p=[%atom p=~.]]] q [ %brhp p [ %kthp p=[%axil p=[%atom p=~.]] q [ %wtcl p=[%dtts p=[%dtls p=[%cnzz p=~[%b]]] q=[%cnzz p=~[%a]]] q=[%cnzz p=~[%b]] r=[%cnts p=~[%$] q=~[[p=~[%b] q=[%dtls p=[%cnzz p=~[%b]]]]]] ] ] ] ] ] ] (To get this, I just ran ++ream, our compiler's frontend, on that code sample.) It would be as simple as dropping in an alternate parser there that looked for, e.g., 'if' rather than '?:', which isn't actually hard because our parser combinators are really easy to use. (The actual Hoon parser is very old and due for a cleanup, unfortunately, but conceptually is not very complicated.) I wouldn't endorse it myself, but perhaps in the future of the project someone will find it a useful thing to do and do it. It would definitely clash with the language's design sensibilities in a way that "use English" doesn't clash with Perl's - Hoon is somewhat more picky (though, what language isn't?). Edit: I completely forgot that I was going to include a hypothetical version of the above with keywords. Here: defgate a=@ nil? a error %decrement-underflow dim b=@ runtrap cast-to @ if inc(b) == a b replace b with inc(b) in this (The keywords are silly, but please imagine better ones.)