3 ms·
> For a language like hoon where we use a lot of symbols Languages with lots of symbols tend to be incredibly difficult to read at first. If you have a progra
by csense 11y ago
> For a language like hoon where we use a lot of symbols
Languages with lots of symbols tend to be incredibly difficult to read at first. If you have a programming language where a typical program looks like line noise, it means the programming language is going to likely have a very steep learning curve (because a lot of those operators are probably not going to have their standardized meaning).
Think about Python. A well-written Python program is similar to the pseudocode you would write on a napkin. For a concrete example, look at the whitepaper's definition of I1 in pseudo-code. The "pseudo-Hoon" implementation of I1 looks totally different from the pseudocode, and to even begin to read the Hoon code, I would have to look up the meanings of approximately 10 different operators.
I guess there are two different camps of language design -- the Perl / Ruby / shell camp where having lots of non-standard operators in your syntax is desirable, and the C / Python / Lua camp which prefers a small set of operators with meanings close to their "standard" mathematical ones.
- AnimalMuppet 11y agoWell, C has ++, which is different from +, and it has &&, which is different from &. It also has ?:, and >> and <<, and * for pointers as well as multiplication, and // to mean something incredibly different from /, and... To me, C syntax is obvious, because I've been using it for 30 years. It may be a small set of operators, but "meanings close to their standard mathematical ones" may be a bit of a stretch.
- tormeh 11y agoYeah, I balked at C's inclusion as well. And that's just the signs. The way those signs are combined and the rest of the syntax are also often pretty gross. Try allocating an array of function pointers on the heap and you'll see what I mean.
- akavel 11y agoAnd then there's Haskell, with it seems to be customary to define new operators extremely often; so much so than I can't cope with the speed trying to invent and memorize how to read them subvocally, unfortunately.
- yarvin9 11y agoThis is one thing we don't do in Hoon -- there are no user-defined macros, operator overloading, etc. If you're going to put a lot of energy into binding syntax to sound to semantics, you only want to do it once (per language, at least.)