6 ms·

The architecture is exciting. The problem is that the aesthetics of the tooling seems deliberately designed to alienate new users. For example the whitepaper

by csense 11y ago

The architecture is exciting. The problem is that the aesthetics of the tooling seems deliberately designed to alienate new users. For example the whitepaper gives new names to every punctuation symbol! And poking around the repo, there are gems like this: "A...variable name is a random pronounceable three-letter string, sometimes with some vague relationship to its meaning, but usually not..." "Nock, for mysterious reasons, uses 0 as true...and 1 as false..." The architecture is really cool, but the syntax is terrible.

pcmonk 11y ago
Traditional punctuation names suck. "Ampersand", "at sign", "caret"? For a language like hoon where we use a lot of symbols, that gets really tiring. Having one-syllable names for glyphs is really convenient, and they tend to roll of the tongue. Everyone's free to use whatever names they want, of course, we just find these useful. Most people love these once they get used to them. I don't think you can judge syntax by looking at it -- you have to use it for a little while. Hoon's syntax looks hard, but it's actually rather pleasant to use.
- yarvin9 11y ago
  Also, the three-letter variable names aren't part of Hoon -- they're just a convention that works well if (and only if) you have short, simple functions. I've actually taken to using TLVs with a Hungarian suffix in C -- it works well if (and only if) you have short, simple functions. One way to think about variable names: declaring a variable is a way of saying "I couldn't quite get this into point-free form." Names should be the exception, not the rule. Again, this is much more true in a functional language.
- tptacek 11y ago
  This right here is what I mean when I suggest Urbit is unserious. "Green is just yellow and blue. Why do we call it 'green'? That name sucks. From now on, we're going to call it 'yellue'." There's overreaching first-principles boil-the-ocean dorm room rethinking of concepts, and then there's renaming the ASCII characters.
  - DanBC 11y ago
    You know someone's going to pop up and talk about the Russian names for blue, and how changing the word allows us to change the way we see things, right? http://www.pnas.org/content/104/19/7780.full http://www.pnas.org/content/104/19/7780.full
  - deleted 11y ago
    [deleted]
  - jpt4 11y ago
    A better analogy would be a modern day SSB [0] proposing a constitutional amendment to officially rename federal offices by their standardized acronyms, e.g. "President of the United States" to "POTUS", "Supreme Court of the United States" to "SCOTUS", etc., especially as this would be an equally superficial distraction from this hypothetical neo-SSB's real goal of replacing all Congressmen with AIs and relocating the capitol to Kansas City. As it happens, "green" exists linguistically, so one is not compelled to wax artfully about the "yellow-blue blades [of grass] laced in dew". However, it used to be that the only way to talk of "orange" was as "yellow-red" or similar, until the simplifying convention of a new word for a distinct entity took hold. Edit: Further, Urbit's equivalent of the Sunflower State Congress plan gloms enough together that an atomistically novel domain specific vocabulary is at least as useful. Edit: As one effectively lay to the many disciplines of the professional field of computation, I use this forum to advertise my continued interest in a critical audit of Urbit. If Keean Schupke and Thomas Lord can probe the depths of Carl Hewitt's ActorScript [1] (the true standard for any so accused "obscurantist" software), then a fortiori Urbit's Anathem barrier [2] can be only semi-impermeable. [0] https://en.wikipedia.org/wiki/Simplified_Spelling_Board https://en.wikipedia.org/wiki/Simplified_Spelling_Board [1] http://lambda-the-ultimate.org/node/5243 http://lambda-the-ultimate.org/node/5243 [2] https://xkcd.com/483/ https://xkcd.com/483/
    - anon4 11y ago
      Well you should drop the OTUS, since it's redundant and implied. So you have the P, the SC (pronounced scee - with a long s), etc.
  - 11y ago
- 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 ago
    Well, 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 ago
      Yeah, 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 ago
    And 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.
- JoshTriplett 11y ago
  > Traditional punctuation names suck. "Ampersand", "at sign", "caret"? Hence why geeks and programmers rarely call them by name. See http://www.catb.org/jargon/html/A/ASCII.html http://www.catb.org/jargon/html/A/ASCII.html .
  - yarvin9 11y ago
    There's a lot of folk workarounds for this problem. They're mostly fine for languages that use ASCII lightly. But it'd be a pretty confusing mess if we applied the "pick something in the jargon file" approach to something like the Hoon syntax. Everyone who's learned our ASCII dictionary, which admittedly is not a whole lot of people, applies it compulsively.
    - mundo 11y ago
      Is the list in the whitepaper correct? It shows in part: nap [ pan ] lep ( pel } If that's not a typo, using mirrored words for ( and } is downright malicious.
      - yarvin9 11y ago
        Doh! That serves me right for tweaking these right before shipping the whitepaper. Yes, "pel" is ).
        agumonkey 11y ago
        but isn't pel a rip ?
- pjc50 11y ago
  Clearly we should be using Victor Borge's phonetic punctuation: https://www.youtube.com/watch?v=6bpIbdZhrzA https://www.youtube.com/watch?v=6bpIbdZhrzA
zaphar 11y ago
I admit that I have a fondness for learning esoteric languages. That said I've actually gone far enough down the urbit rabbit hole to write a set of tutorials[0]. urbit has a high startup cost and is hampered by a lack of documentation as well as a desire to reinvent terminology as well as a fast changing API to write too. All of which means that it's more suitable for the curious and hobbyists right now. I'm withholding judgement on whether it will manage to succeed despite these. [0]: http://hidduc-posmeg.urbit.org/home/pub/hoon-intro/ http://hidduc-posmeg.urbit.org/home/pub/hoon-intro/
xixi77 11y ago
This has been done before: https://en.wikipedia.org/wiki/INTERCAL https://en.wikipedia.org/wiki/INTERCAL "The INTERCAL manual gives unusual names to all non-alphanumeric ASCII characters: single and double quotes are "sparks" and "rabbit ears" respectively. (The exception is the ampersand: as the Jargon File states, "what could be sillier?") The assignment operator ... is in INTERCAL a left-arrow, <-, referred to as "gets" and made up of an "angle" and a "worm"."
- david-given 11y ago
  Slightly less insanely, Forth did this too. The ANS Forth spec defines official pronounceable names for all words: http://lars.nocrew.org/dpans/dpans6.htm#6.1 http://lars.nocrew.org/dpans/dpans6.htm#6.1 The names are a mix between the visual (* is 'star', and ; is 'semicolon') and the semantic (<> is 'not-equals', and ! is 'store'). Some are a mix (+! is 'plus-store').
  - anon4 11y ago
    Well, ++ is "increment" in C/C++. The glyphs themselves can be described "plus plus", but everybody calls it increment, because of what it does. Also "->" the arrow operator. Everyone calls it arrow, rather than "minus greater than". It makes sense to call the glyph or collection of glyphs by what they do, rather than spelling them out.
    - david-given 11y ago
      Actually, everyone I know calls it 'plus plus'. I'm with you with 'arrow', though.
      - akavel 11y ago
        Arrow's still rather on the 'plus plus' side of things anyway - maybe not 'minus greater than', but generally describes the look of it. If one would call ++ 'increment', one should call -> 'field' or something similar, I suppose.
JulianMorrison 11y ago
Don't blame Nock, Bash does that too. Return code 0 = true.
- emmelaich 11y ago
  I call it the Tolstoy model: "All happy families are alike; each unhappy family is unhappy in its own way" You only need one value for success/true. But you need many to indicate the modes of failure.
  - eru 11y ago
    How about not using numbers for Booleans?
    - api 11y ago
      CPUs grok numbers. This would be inefficient.
      - eru 11y ago
        Oh, you can use numbers behind the scenes. Just make sure your type system hides the ugly truth.
api 11y ago
The inversion of 0/1 for true/false is common in good C APIs. 0 as true and 1 as false makes a lot of sense from a perspective of error handling. 0 means everything's okay, while nonzero means it isn't. Various forms of nonzero can then represent different kinds of fail. Variations on this theme are common enough in programming that the inversion is reasonable, and it does no harm in the simple boolean case. The architecture is no more esoteric than Unix, C, C++, or a submicron-scale polished turd like HTML5+CSS+JavaScript+React+JSX+NodeJS or most other "stacks." It's just unfamiliar because it's new, and that's okay, because it is not making any pretensions about not being new or about being a baby-step hack on top of our existing heap of hacks. If you're going to try to reinvent the OS and the platform, then go full Yoda and do or do not.
- jpt4 11y ago
  > it is not making any pretensions about not being new or about being a baby-step hack And, with its Kelvin (count down to zero, then freeze forever) revisioning scheme, Urbit admits its own mortality (or so it seems to me). Any change that can not be managed as an intrasystemic, in place upgrade must necessarily - and righteously - detonate the Urbit ecosystem as thoroughly as mature Urbit obviates Unix. Future competitors are thereby encouraged to be equally generalist, thus hardening Urbit against dissolution via tepid, partial reforms.

by csense 11y ago

pcmonk 11y ago

Traditional punctuation names suck. "Ampersand", "at sign", "caret"? For a language like hoon where we use a lot of symbols, that gets really tiring. Having one-syllable names for glyphs is really convenient, and they tend to roll of the tongue. Everyone's free to use whatever names they want, of course, we just find these useful. Most people love these once they get used to them. I don't think you can judge syntax by looking at it -- you have to use it for a little while. Hoon's syntax looks hard, but it's actually rather pleasant to use.

yarvin9 11y ago
Also, the three-letter variable names aren't part of Hoon -- they're just a convention that works well if (and only if) you have short, simple functions. I've actually taken to using TLVs with a Hungarian suffix in C -- it works well if (and only if) you have short, simple functions. One way to think about variable names: declaring a variable is a way of saying "I couldn't quite get this into point-free form." Names should be the exception, not the rule. Again, this is much more true in a functional language.
tptacek 11y ago
This right here is what I mean when I suggest Urbit is unserious. "Green is just yellow and blue. Why do we call it 'green'? That name sucks. From now on, we're going to call it 'yellue'." There's overreaching first-principles boil-the-ocean dorm room rethinking of concepts, and then there's renaming the ASCII characters.
- DanBC 11y ago
  You know someone's going to pop up and talk about the Russian names for blue, and how changing the word allows us to change the way we see things, right? http://www.pnas.org/content/104/19/7780.full http://www.pnas.org/content/104/19/7780.full
- deleted 11y ago
  [deleted]
- jpt4 11y ago
  A better analogy would be a modern day SSB [0] proposing a constitutional amendment to officially rename federal offices by their standardized acronyms, e.g. "President of the United States" to "POTUS", "Supreme Court of the United States" to "SCOTUS", etc., especially as this would be an equally superficial distraction from this hypothetical neo-SSB's real goal of replacing all Congressmen with AIs and relocating the capitol to Kansas City. As it happens, "green" exists linguistically, so one is not compelled to wax artfully about the "yellow-blue blades [of grass] laced in dew". However, it used to be that the only way to talk of "orange" was as "yellow-red" or similar, until the simplifying convention of a new word for a distinct entity took hold. Edit: Further, Urbit's equivalent of the Sunflower State Congress plan gloms enough together that an atomistically novel domain specific vocabulary is at least as useful. Edit: As one effectively lay to the many disciplines of the professional field of computation, I use this forum to advertise my continued interest in a critical audit of Urbit. If Keean Schupke and Thomas Lord can probe the depths of Carl Hewitt's ActorScript [1] (the true standard for any so accused "obscurantist" software), then a fortiori Urbit's Anathem barrier [2] can be only semi-impermeable. [0] https://en.wikipedia.org/wiki/Simplified_Spelling_Board https://en.wikipedia.org/wiki/Simplified_Spelling_Board [1] http://lambda-the-ultimate.org/node/5243 http://lambda-the-ultimate.org/node/5243 [2] https://xkcd.com/483/ https://xkcd.com/483/
  - anon4 11y ago
    Well you should drop the OTUS, since it's redundant and implied. So you have the P, the SC (pronounced scee - with a long s), etc.
- 11y ago
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 ago
  Well, 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 ago
    Yeah, 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 ago
  And 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.
JoshTriplett 11y ago
> Traditional punctuation names suck. "Ampersand", "at sign", "caret"? Hence why geeks and programmers rarely call them by name. See http://www.catb.org/jargon/html/A/ASCII.html http://www.catb.org/jargon/html/A/ASCII.html .
- yarvin9 11y ago
  There's a lot of folk workarounds for this problem. They're mostly fine for languages that use ASCII lightly. But it'd be a pretty confusing mess if we applied the "pick something in the jargon file" approach to something like the Hoon syntax. Everyone who's learned our ASCII dictionary, which admittedly is not a whole lot of people, applies it compulsively.
  - mundo 11y ago
    Is the list in the whitepaper correct? It shows in part: nap [ pan ] lep ( pel } If that's not a typo, using mirrored words for ( and } is downright malicious.
    - yarvin9 11y ago
      Doh! That serves me right for tweaking these right before shipping the whitepaper. Yes, "pel" is ).
      - agumonkey 11y ago
        but isn't pel a rip ?
pjc50 11y ago
Clearly we should be using Victor Borge's phonetic punctuation: https://www.youtube.com/watch?v=6bpIbdZhrzA https://www.youtube.com/watch?v=6bpIbdZhrzA

zaphar 11y ago

I admit that I have a fondness for learning esoteric languages. That said I've actually gone far enough down the urbit rabbit hole to write a set of tutorials[0]. urbit has a high startup cost and is hampered by a lack of documentation as well as a desire to reinvent terminology as well as a fast changing API to write too. All of which means that it's more suitable for the curious and hobbyists right now. I'm withholding judgement on whether it will manage to succeed despite these. [0]: http://hidduc-posmeg.urbit.org/home/pub/hoon-intro/ http://hidduc-posmeg.urbit.org/home/pub/hoon-intro/

xixi77 11y ago

This has been done before: https://en.wikipedia.org/wiki/INTERCAL https://en.wikipedia.org/wiki/INTERCAL "The INTERCAL manual gives unusual names to all non-alphanumeric ASCII characters: single and double quotes are "sparks" and "rabbit ears" respectively. (The exception is the ampersand: as the Jargon File states, "what could be sillier?") The assignment operator ... is in INTERCAL a left-arrow, <-, referred to as "gets" and made up of an "angle" and a "worm"."

david-given 11y ago
Slightly less insanely, Forth did this too. The ANS Forth spec defines official pronounceable names for all words: http://lars.nocrew.org/dpans/dpans6.htm#6.1 http://lars.nocrew.org/dpans/dpans6.htm#6.1 The names are a mix between the visual (* is 'star', and ; is 'semicolon') and the semantic (<> is 'not-equals', and ! is 'store'). Some are a mix (+! is 'plus-store').
- anon4 11y ago
  Well, ++ is "increment" in C/C++. The glyphs themselves can be described "plus plus", but everybody calls it increment, because of what it does. Also "->" the arrow operator. Everyone calls it arrow, rather than "minus greater than". It makes sense to call the glyph or collection of glyphs by what they do, rather than spelling them out.
  - david-given 11y ago
    Actually, everyone I know calls it 'plus plus'. I'm with you with 'arrow', though.
    - akavel 11y ago
      Arrow's still rather on the 'plus plus' side of things anyway - maybe not 'minus greater than', but generally describes the look of it. If one would call ++ 'increment', one should call -> 'field' or something similar, I suppose.

JulianMorrison 11y ago

Don't blame Nock, Bash does that too. Return code 0 = true.

emmelaich 11y ago
I call it the Tolstoy model: "All happy families are alike; each unhappy family is unhappy in its own way" You only need one value for success/true. But you need many to indicate the modes of failure.
- eru 11y ago
  How about not using numbers for Booleans?
  - api 11y ago
    CPUs grok numbers. This would be inefficient.
    - eru 11y ago
      Oh, you can use numbers behind the scenes. Just make sure your type system hides the ugly truth.

api 11y ago

The inversion of 0/1 for true/false is common in good C APIs. 0 as true and 1 as false makes a lot of sense from a perspective of error handling. 0 means everything's okay, while nonzero means it isn't. Various forms of nonzero can then represent different kinds of fail. Variations on this theme are common enough in programming that the inversion is reasonable, and it does no harm in the simple boolean case. The architecture is no more esoteric than Unix, C, C++, or a submicron-scale polished turd like HTML5+CSS+JavaScript+React+JSX+NodeJS or most other "stacks." It's just unfamiliar because it's new, and that's okay, because it is not making any pretensions about not being new or about being a baby-step hack on top of our existing heap of hacks. If you're going to try to reinvent the OS and the platform, then go full Yoda and do or do not.

jpt4 11y ago
> it is not making any pretensions about not being new or about being a baby-step hack And, with its Kelvin (count down to zero, then freeze forever) revisioning scheme, Urbit admits its own mortality (or so it seems to me). Any change that can not be managed as an intrasystemic, in place upgrade must necessarily - and righteously - detonate the Urbit ecosystem as thoroughly as mature Urbit obviates Unix. Future competitors are thereby encouraged to be equally generalist, thus hardening Urbit against dissolution via tepid, partial reforms.