Hacker News Reader

Comment by csense | Hacker News Reader

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.

View on HN

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.

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.

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.

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

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

[1] http://lambda-the-ultimate.org/node/5243

[2] https://xkcd.com/483/

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.

This definitely counts as a highbrow dismissal!

As I age, I find it harder and harder to remember how easy and natural it is for young people to learn new things: ideas, theories, languages, and yes -- names. Alas, we can't rejuvenate our brains. I know of only one (partial) cure: have your own kids. You'll feel jealous all the time, but it's worth it.

It's painful to admit that I'm probably too old to learn other peoples' new languages. But any new language isn't and can't be designed for 42-year-old silverbacks. It has to be designed for kids -- or at least, people are who are kids now. And believe me, teenagers love this kind of stuff...

[Edit: tptacek, when you edit a comment after posting it, I think it's good etiquette to mark it with an [edit]]?

FWIW: I wrote the first half of that comment, then 5 minutes later, feeling it was too snarky without explaining itself, added the sentence: "There's overreaching first-principles boil-the-ocean dorm room rethinking of concepts, and then there's renaming the ASCII characters."

I'm a parent of two teenagers, neither of whom seems particularly interested in new names for punctuation.

I understand. And it did improve the comment, so I forgive you. But it's just irritating when someone hangs a fat fastball over the plate, you whack it, then find out that the pitch magically turned into a curveball and all you've hit is a ground-ball single.

An XS Nock shirt is a dress for my daughter, but she loves the "code." I guess all kids are different. But you never know what they're ready to learn until you try to teach them.

I wonder if it's hard because we don't try enough, because reality and pragmatism bolt us to dry reuse rather wheel reinvention.

Even more digressing, I'm very curious if young brains have an innate sense of 'new' in the most complex and abstract sense. It's as if they smell it.

As for having kids, I have to say this: it's a wonderful experience, but it definitely doesn't make you smarter! Maybe that's the sleep deprivation talking though...

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

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.

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.

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.

This 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.)

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

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.

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.

Doh! That serves me right for tweaking these right before shipping the whitepaper. Yes, "pel" is ).

but isn't pel a rip ?

Clearly we should be using Victor Borge's phonetic punctuation: https://www.youtube.com/watch?v=6bpIbdZhrzA

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/

This has been done before: 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"."

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

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').

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.

Actually, everyone I know calls it 'plus plus'.

I'm with you with 'arrow', though.

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.

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.

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

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

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.

How about not using numbers for Booleans?

CPUs grok numbers. This would be inefficient.

Oh, you can use numbers behind the scenes. Just make sure your type system hides the ugly truth.

Reply on news.ycombinator.com