8 ms·

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 com

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

by urbit 11y ago

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.