5 ms·

I actually find a lot of arguments he presents compelling. However the general thrust seems to be that programming language should be accessible. Hoon seems to

I actually find a lot of arguments he presents compelling. However the general thrust seems to be that programming language should be accessible. Hoon seems to fail that test. I've yet to see how this is better than vanilla ML. I don't see that because Hoon doesn't use standard syntax or terminology. I can't just read some code and a language overview to decide if this is worth (a lot of) my time. I think ML has a fairly steep start-up cost but is definitely understandable by regular people and has real productivity benefits. Hoon is sufficiently obfuscated that it has an incredibly high barrier to even evaluate as a language. I don't think you need to have tons of unintelligible typing rules to make things familiar. By avoiding standard syntax and terminology, it puts an enormous burden on the potential user.

urbit 13y ago
Some UI burdens seem high, some are high. An interesting class of UI problem is the set of things that intuitively look difficult, but actually aren't. Human brains are incredibly good at raw memorization of associations. Hoon has about 100 digraphs, and their internal structure isn't random. How hard is to learn 100 characters of Chinese? Perhaps easier than you think. Nor are there no payoffs. For instance, most languages are very bad at defining large, mostly static hierarchical trees, so when it comes time to write code that generates, say, an HTML page, you reach for a special "template language" DSL. That's not a problem we have in Hoon. Also, most functional languages have a very annoying tendency to crawl off the right side of your screen and disappear, because indentation depth matches functional depth. That's also not a problem we have in Hoon. So... you pay, definitely. But you also receive.
samatman 13y ago
I'd like to address this obliquely with a question to urbit: Is it always the case that the vowels may be compressed away without loss of meaning? It seems to work some/most of the time, but there is a least a %wet and %wut... I think? Though this be method, yet there is madness to it.
- urbit 13y ago
  There's %wet but no ++wet. The name of the character is actually just the name of a parser function for it.

urbit 13y ago

Some UI burdens seem high, some are high. An interesting class of UI problem is the set of things that intuitively look difficult, but actually aren't. Human brains are incredibly good at raw memorization of associations. Hoon has about 100 digraphs, and their internal structure isn't random. How hard is to learn 100 characters of Chinese? Perhaps easier than you think. Nor are there no payoffs. For instance, most languages are very bad at defining large, mostly static hierarchical trees, so when it comes time to write code that generates, say, an HTML page, you reach for a special "template language" DSL. That's not a problem we have in Hoon. Also, most functional languages have a very annoying tendency to crawl off the right side of your screen and disappear, because indentation depth matches functional depth. That's also not a problem we have in Hoon. So... you pay, definitely. But you also receive.

samatman 13y ago

I'd like to address this obliquely with a question to urbit: Is it always the case that the vowels may be compressed away without loss of meaning? It seems to work some/most of the time, but there is a least a %wet and %wut... I think? Though this be method, yet there is madness to it.

urbit 13y ago
There's %wet but no ++wet. The name of the character is actually just the name of a parser function for it.