3 ms·

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")

by 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.

JoshTriplett 11y ago
> 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. So is remembering what all the runes do; if the names and the functions relate, they're both easier to remember.
- urbit 11y ago
  The runes (a) help you remember the combinators, and (b) are two characters long. To get to reasonably precise, meaningful keyword bindings for this set of combinators in particular, perhaps you'd be replacing ":-", ":_", ":+", ":^", ":*", and ":~" with ":pair", ":reverse-pair", ":triple", ":quadruple", ":tuple", and ":list" respectively. This is a pretty benign and easy case, and you may have to trust me on what kind of hash this search-replace alone would turn a Hoon file into. Then again, I suppose it all looks like hash to you. Language design is hard; you can't please everyone. Probably the best-case scenario is that you please some people, and the rest are dragged kicking and screaming. And that's a best case.
  - JoshTriplett 11y ago
    No, I actually think that having combinators like that makes sense; it's a perfectly reasonable (and very APLish) design choice to Huffman-code those kinds of operations as combinators. I've worked with Haskell code that makes extensive use of symbolic combinators, and once you get used to a given set, code using them can become much more readable. And using symbol pairs where related operations have related symbols makes even more sense. I just don't think it makes sense to invent fanciful names for them based entirely on their symbology, rather than their function. It's your language; you can call things whatever you want. But I've seen many languages that I would like to succeed fail or grow very slowly because they failed to engage well with prospective users. And when you already have a nearly-asymptotic learning curve, why add more to it?
    - urbit 11y ago
      We're at a pretty shallow level of disagreement here, because you'd just add descriptive names to the combinator definitions. I'm not sure this would improve the learning curve much if at all, but it couldn't hurt much either. As I always say, there's a difference between real and apparent learning curves. I don't think your perception of the apparent learning curve is wrong. But some things are easier than they look; one of those things is remembering associations. I've seen a good number of people walk the real learning curve for this language, and it's not that steep. Hopefully reality also gets a vote.
e12e 11y ago
I appreciate this clarifying comment. This certainly feels a lot like the same kind of things APL and friends did/do. I'm almost convinced it's a bad idea, but not entirely. It gives me the feeling of conflating conciseness and simplicity - taking something that is (overly) complex and attempting to make it simple by making the representation more compact. On the other hand, different (from the norm) can be a good thing in itself. Still haven't gotten around to play much with it. I strongly suspect that, if we consider this the first incarnation of what will be the future of this system, the third or fourth re-iteration might be getting to the core. (If you can't explain something simply, you don't yet understand it etc).
eru 11y ago
We make up new line-noise (=combinator runes) all the time in Haskell. The lens library alone has over 100, see https://www.fpcomplete.com/school/to-infinity-and-beyond/pick-of-the-week/a-little-lens-starter-tutorial#actually-there-are-a-whole-lot-of-operators-in-lens---over-100 https://www.fpcomplete.com/school/to-infinity-and-beyond/pic... Haskell people invent and a lot of new and strange things. Renaming punctuation is not one of them. I guess it doesn't matter as long as you never use your new names in writing. (And why would you, you can use use the symbols themselves.) But then, of course, why bother with these names at all apart from creating an oral tradition.
- urbit 11y ago
  Speaking from experience, I guarantee you that anyone who starts saying "centis" instead of "percent equals," whether in the context of Hoon or Haskell lenses or anything, will never go back. I have to force myself to "code-switch" when speaking to the uninitiated, even in a technical context that has nothing to do with Urbit. And I'm not the only one. I can't fault Haskellers for their daring in pushing the limits of programming languages as a UI. For instance, the idea of custom, library-specific "line noise" terrifies me. Hoon has no macros, no custom syntax, no operator overloading, etc. Once you've learned the line noise you've learned it. The lens library in particular is a DSL by anyone's definition. Arguably (well, I'd argue it anyway), the ease of constructing DSLs is a trap that's impeded adoption of both major families of FP, Lisp and Haskell/ML. Plenty of people have made the "DSL == write-only" argument, so hopefully it's sufficient to just reference it. Lens is in a sense the quintessential expression of Haskell; I don't know how anyone grounded in reality could expect the average Java programmer to learn and master it. And yet, everything it's doing is beautiful and true and right. Basically, resolving this contradiction strikes me as the essential problem of functional programming, if not just programming, in the next decade. I personally am very far from being the most qualified person to solve this problem. But I feel not enough people are working on it.
  - eru 11y ago
    Interesting enough, `lens' is a bit of an outlier in Haskell land---exactly because it is too Java-like in its intricate hierarchies for some people's taste. I like the Haskell approach to operators as just a funky syntax for functions. No need to bake any operators as keywords into your language. +, =, etc are all just part of the standard library. (I also like the Lisp stance of mostly just not caring about line-noise symbols vs letters.)

by urbit 11y ago

JoshTriplett 11y ago

> 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. So is remembering what all the runes do; if the names and the functions relate, they're both easier to remember.

urbit 11y ago
The runes (a) help you remember the combinators, and (b) are two characters long. To get to reasonably precise, meaningful keyword bindings for this set of combinators in particular, perhaps you'd be replacing ":-", ":_", ":+", ":^", ":*", and ":~" with ":pair", ":reverse-pair", ":triple", ":quadruple", ":tuple", and ":list" respectively. This is a pretty benign and easy case, and you may have to trust me on what kind of hash this search-replace alone would turn a Hoon file into. Then again, I suppose it all looks like hash to you. Language design is hard; you can't please everyone. Probably the best-case scenario is that you please some people, and the rest are dragged kicking and screaming. And that's a best case.
- JoshTriplett 11y ago
  No, I actually think that having combinators like that makes sense; it's a perfectly reasonable (and very APLish) design choice to Huffman-code those kinds of operations as combinators. I've worked with Haskell code that makes extensive use of symbolic combinators, and once you get used to a given set, code using them can become much more readable. And using symbol pairs where related operations have related symbols makes even more sense. I just don't think it makes sense to invent fanciful names for them based entirely on their symbology, rather than their function. It's your language; you can call things whatever you want. But I've seen many languages that I would like to succeed fail or grow very slowly because they failed to engage well with prospective users. And when you already have a nearly-asymptotic learning curve, why add more to it?
  - urbit 11y ago
    We're at a pretty shallow level of disagreement here, because you'd just add descriptive names to the combinator definitions. I'm not sure this would improve the learning curve much if at all, but it couldn't hurt much either. As I always say, there's a difference between real and apparent learning curves. I don't think your perception of the apparent learning curve is wrong. But some things are easier than they look; one of those things is remembering associations. I've seen a good number of people walk the real learning curve for this language, and it's not that steep. Hopefully reality also gets a vote.

e12e 11y ago

I appreciate this clarifying comment. This certainly feels a lot like the same kind of things APL and friends did/do. I'm almost convinced it's a bad idea, but not entirely. It gives me the feeling of conflating conciseness and simplicity - taking something that is (overly) complex and attempting to make it simple by making the representation more compact. On the other hand, different (from the norm) can be a good thing in itself. Still haven't gotten around to play much with it. I strongly suspect that, if we consider this the first incarnation of what will be the future of this system, the third or fourth re-iteration might be getting to the core. (If you can't explain something simply, you don't yet understand it etc).

eru 11y ago

We make up new line-noise (=combinator runes) all the time in Haskell. The lens library alone has over 100, see https://www.fpcomplete.com/school/to-infinity-and-beyond/pick-of-the-week/a-little-lens-starter-tutorial#actually-there-are-a-whole-lot-of-operators-in-lens---over-100 https://www.fpcomplete.com/school/to-infinity-and-beyond/pic... Haskell people invent and a lot of new and strange things. Renaming punctuation is not one of them. I guess it doesn't matter as long as you never use your new names in writing. (And why would you, you can use use the symbols themselves.) But then, of course, why bother with these names at all apart from creating an oral tradition.

urbit 11y ago
Speaking from experience, I guarantee you that anyone who starts saying "centis" instead of "percent equals," whether in the context of Hoon or Haskell lenses or anything, will never go back. I have to force myself to "code-switch" when speaking to the uninitiated, even in a technical context that has nothing to do with Urbit. And I'm not the only one. I can't fault Haskellers for their daring in pushing the limits of programming languages as a UI. For instance, the idea of custom, library-specific "line noise" terrifies me. Hoon has no macros, no custom syntax, no operator overloading, etc. Once you've learned the line noise you've learned it. The lens library in particular is a DSL by anyone's definition. Arguably (well, I'd argue it anyway), the ease of constructing DSLs is a trap that's impeded adoption of both major families of FP, Lisp and Haskell/ML. Plenty of people have made the "DSL == write-only" argument, so hopefully it's sufficient to just reference it. Lens is in a sense the quintessential expression of Haskell; I don't know how anyone grounded in reality could expect the average Java programmer to learn and master it. And yet, everything it's doing is beautiful and true and right. Basically, resolving this contradiction strikes me as the essential problem of functional programming, if not just programming, in the next decade. I personally am very far from being the most qualified person to solve this problem. But I feel not enough people are working on it.
- eru 11y ago
  Interesting enough, `lens' is a bit of an outlier in Haskell land---exactly because it is too Java-like in its intricate hierarchies for some people's taste. I like the Haskell approach to operators as just a funky syntax for functions. No need to bake any operators as keywords into your language. +, =, etc are all just part of the standard library. (I also like the Lisp stance of mostly just not caring about line-noise symbols vs letters.)