See [1], [2], [3], [4].
---
ha ha, he should read 'fever in urbicand'! (not because of any deep connection, just b/c of the pun)
---
i guess one way to think about odors vs. types is that odors are telling you how a thing (in this case, an atom) is to be interpreted, whereas types are telling you about the shape of a tree structure. So i guess any language might contemplate having two 'type systems' of this sort.
hoon types are exactly structural types, but hoon type vs. odor is not quite like structural types vs. nominal types. althouth odors can be said to be nominal types, but there is more/less to odors than that; odors are not so much types as hints about how to use things, although they are weak types too.
---
My Opinions and complaints
i've been looking at Hoon because it is by the same guy who made Nock, and i loved Nock (Nock is a "combinatorial assembly language"). I am working thru the tutorials at http://urbit.org/doc/hoon/tut/1/ . So far i am finding a lot that i don't like. Some complaints:
- Hoon claims to be a C analog, but i think it is not. The tutorial claims: "Hoon is actually not much more than a fancy wrapper around Nock. People who know C can think of Hoon as the C to Urbit's Nock - just a sprinkling of syntax, wrapped around machine code and memory." I agree that Hoon may be a thin layer over Nock. But this may not be an accurate characterization of C (see also https://news.ycombinator.com/item?id=6415240 ). Hoon seems lower-level than C. Hoon is more like C if C had specific constructs for every step of manipulating stack frames during function calls, and then actual function definition and calling constructs were defined as macros.
- The Hoon author's philosophy is that since many things are a little different between programming languages, Hoon should make up its own vocabulary to describe its constructs, even when they are similar to standard vocabulary terms; that way people won't assume more similarity than is warrented, and will be open to thinking in a new paradigm. In some cases, another reason to do this is because if Hoon's definition of something is slightly different from the traditional one, then technically speaking it wouldn't be correct to call the Hoon thing by the old word, and the creator of Hoon is at pains not to use formal words in a formally incorrect manner. E.g. in Hoon, functions are called "gates", strings are called 'cords', booleans are called 'loobeans' (note that at least there is often some pun to aid your memory), pattern matching is called 'fishing', and fetching the default value for a type is called 'bunting' (well at least in that last one, Haskell isn't much better; Haskell calls types with defaults "pointed"). Which would be fine if you had decided that you want to become a serious Hoon programmer, but for people who are just reading the tutorial to learn about Hoon or to decide if they like Hoon enough to learn more about it, it's a bit much.
- Similarly, some other things are made different 'just because'. For instance, in Hoon, True corresponds to integer 0, and False to integer 1.
- glyphs. Hoon has a predilection for using punctuation for its basic constructs, including many fundamental functions and operators. For example, increment is '.+'. However, in many places in code, instead of just writing the name of the operator, you instead use a concise alphanumeric syntax, e.g. .+ is '%dtls' (dt is . and ls is +). The reason for this is that although Hoon loves punctuation characters, it also wants to be easy to pronounce and speak quickly, and many of the English named for punctuation characters have too many syllables or are just hard to say. So Hoon makes up alternate, short pronouncable names for each punctuation character. This is very common and you can't understand many of the examples without translating stuff like %dtls to .+. So in order to really read Hoon code, including the example code in the tutorial, you must memorize the 'glyphs', that is, the lookup table for the two-character names for each punctuation symbol. So in reading the tutorial you find yourself constantly going back and forth between what you are trying to read, and the page with the glyph table. Again, the glyph codes are often puns to aid memory, but these are often too clever to be useful; e.g. 'tr' codes '*', the rationale being that 'tr' is short for 'tar' (a pun off 'star', get it?). As with the non-standard vocabulary, it's hard to justify spending the time doing this if you have not yet decided to become a serious Hoon programmer.
- glyphs part II. In addition to objecting to having to memorize the alphabetic names and shorthand for the glyphs, i object to Hoon using punctuation (pairs of punctuation characters, called "runes") for so many basic constructs. The idea is that, because each punctuation symbol has a short, pronouncable name, and in addition because there is a meaning assigned to the first punctuation character in a basic construct's name (which is in the table at the end of the section "Runes" in Chapter 3 of the Hoon tutorial), we should be able to train our brains to be able to easily recall and associate meanings with pairs of punctuation characters. Again, maybe that will work after many hours of using Hoon, but it's a serious impediment to learning the language.
- glyphs part III. However, i do admit that the glyph names have their charm, and after having memorized most of them it does seem to be easier to e.g. browse the documentation, because i can url-hack to the proper URL for the thing i'm trying to find.
- names in general: although it's annoying that Hoon made up its own names for everything, and eschewed the idea of finding a name close to what people already use for the same or a similar concept, other than that big drawback, the names are okay. They are usually short (often four letter), concrete terms, which makes them easier to read and remember than the abstract-sounding, big words that you often find in programming languages.
- documentation: the tutorial is non-linear in that it often gives examples that use constructs that have not been defined yet (and not just in a "just consider that word a black box that prints a string" kinda way, but instead in a "i don't expect you to understand all of this yet but just try to get the gist of it even though i haven't defined almost any of it" kinda way) (it's possible everything was defined but i missed it; in which case i change this compliant to "it's too hard to follow"). So i'm hoping it'll make more sense the second time through; but i would prefer if i could just read it once.
- documentation: the author (of both the language and the tutorial) is quite witty, which makes the tutorial more fun to read but also a little more confusing. Especially since Hoon has so many non-standard technical terms with ordinary-sounding names (like bunting, fishing, clamming, gates, tiles, arms, etc), when the author makes a witty aside that you don't immediately understand, your have to determine if he is actually saying something technical with a word you forgot, or if he is just making a joke.
- documentation: there is only one example given for most things as they are introduced, and they are often from the compiler source code, or a simplification of the compiler source code. It would be easier if each thing came with at least one concrete, toy, overly simple, motivating example.
- "Type inference in Hoon is... a relatively simple algorithm, which you nonetheless need to understand if you're going to make it as a Hoon programmer." -- http://urbit.org/doc/hoon/tut/6/ . This is ironic because one of the motivations for this algorithm over Hindley-Milner unification was to avoid having to make new programmers learn the Hindley-Milner algorithm. Also, if you're going to say that all Hoon programmers need to understand this algorithm, it really should be expressed in a pseudocode summary in the text, instead of just in tutorial form and in code.
- Hoon has too much overlapping syntax. E.g. when you see a '~', it can mean a nil literal, or a prefix for a date or time literal, a prefix for a phonemic literal, or the first part of the prefix for text literals, or the first part of the prefix for jam/cue marshalled literals, or the first part of the irregular prefix for the rune %~, or the first part of the irregular prefix for the rune :~. Many of these overlaps are okay (e.g. as a prefix for various literals), but imo using the same thing for (a) nil, (b) a prefix for various literals, (c) something that when combined with a succeeding '(' turns into an operator, (d) something that when combined with a succeeding '[' turns into another operator, is too much. '$' can refer to the 'empty name' or to the leaf tile constructor. () is used for grouping, but if there is a list inside the parens, then anything(list) is short for (%= anything list)
- Also, another complaint about '~()' (the irregular form of %~): As a rule of thumb, if grouping punctuation characters can ever appear without spaces separating them from neighboring constructs, then one should never have grouping punctuation, such as '(', double as part of an operator (e.g. '~()').
- The lack of linearity in the tutorial problem is made much worse by the overlapping syntax. For example, the "~()" shortcut for %~ is seen in examples as early as http://urbit.org/doc/hoon/tut/3/ , but has not yet been introduced. Some readers (for example, me) may spend a lot of time trying to figure out how that makes sense since at that point they think that ~ is either nil or a literal prefix.
You may notice a common pattern in many of the above complaints; like a fantasy book author who labors over every detail of their imaginary world, including imaginary plants and imaginary languages, the Hoon language author delights in creating a new world in every detail. I would prefer if the language had stuck to new semantics and left out the new vocabulary.
However, keep in mind that my complaints here are sort of like complaining that salmon should waste less much energy by not swimming upstream to spawn. Small projects, including programming languages, reflect their creator's personality to some extent, and the creator of Hoon is (at least online) an inveterate witty, wisecracking leprechaun. Expecting Hoon to be Hoon without lengthly esoteric witty diversions is just not in the cards. Nock was not like this, but Nock was an expression of a different side of the creator's personality. If this annoys my plodding, humorless personality, this is my problem, not Hoon's; Urbit has nevertheless managed to attract a community of intelligent programmers and even to seed a company with over $1 million in funding.
In addition, making programming languages is difficult, and making programming languages and tutorials is a lot of work, and if i tried to make a language, my attempt might end up just as confusing than Hoon. In addition, regarding the tutorial, HackerNews? discovered Urbit before the creators planned to release it, and i think much of the Hoon tutorial was frantically thrown together shortly afterwards in an act of kindness to save the time of a group of people who were reverse engineering Hoon anyways.
I'll probably still finish reading thru the tutorial, and then read it again, because (a) Nock was great and i want to check out Hoon because it's by the same guy, and (b) i'm interested to see what a high-level language built in the Nock (combinatorial) paradigm looks like, and (c) because the Hoon paradigm for handling 'subjects' (state) might be inspiration for ways to manage state even in other noncombinatorial, languages.
In summary, Hoon is a neat language which is handicapped by the use of esoteric names for everything, and by the tutorial.
-- bayle
a related list of my complaints about the style of the tutorial:
issues with the style of the tutorial (see above):
- non-linear: the tutorial often gives examples that use constructs that have not been defined yet
- examples from the compiler: i would prefer examples like "hello world" and "interactive hello world with the user's name" and "let's use binary search to guess the user's age"
- witty: this makes it fun to read but more confusing
- ordering/focus: the tutorial seems to take the point of view, "progressively introduce each cool programming theory concept that Hoon invented on top of what Nock has". Which is okay, but it omits two other common tutorial organizing principals: "progress from simple toy programs to complex toy programs" and "show, one by one, the competitive advantages/features of the language". Also, because it is progressive, it is not oriented towards quickly explaining the new programming theory ideas to someone who is not sure yet if they want to spend the time to learn Hoon. Also, it is written (possibly accidentially) as if the reader is a programming language geek, so it's somewhat like a conversation from one guy who has invented his own language to another such fellow, talking about the cool ideas he had, the design choices he made and why, and the challenges he overcame and how. For example, the tutorial mentions as asides things like how the type system isn't as expressive as SAT because although it has union types it doesn't have intersection types [5], and that Hoon has an LL parser and that it can typecheck its own parser and confirm that the result conforms to its AST type [6]. This is almost ironic because one of the goals of Hoon is to be simple to ordinary programmers who don't know about stuff like that (and maybe it is; but this tutorial is not). As a programming language geek myself, i find the asides, design choices, and challenges overcome interesting and useful, so i'm not suggesting that they simply be deleted, but rather, i suggest that another simpler tutorial be written that takes a different approach, and that this one live on as a 'may be of interest to programming language geeks' document.
---
more links: