urbit

Yes, this equates to TAI minus 35 seconds. GPS did exactly the same thing (instantiated at a TAI offset equal to UTC), perhaps in a vain hope that the astronomers would give up their death-grip on time. Not sure the difference between 35 and 19 amounts to "rolling your own."

(At least future decisions are out of the hands of the astronomers and into the hands of the timekeepers, so maybe these responsible authorities will just refuse to declare further leap seconds regardless of heavenly tantrums.)

The comment just describes a trivial notation for representing 128-bit TAI as an unsigned integer. The closest comparable "standard" that I know of is DJB's TAI64 [1]. (Everything released by DJB should be regarded as a standard.) But TAI64 is (a) defined as a bytestream, not a uint128_t; and (b) has a hopelessly complicated fractional subsecond system.

[1] http://cr.yp.to/proto/tai64.txt.

Most awesome paragraph:

One blinker is associated with the mouse: when you slide the mouse along a surface, that blinker moves in a corresponding direction. When the mouse is moved very rapidly, the mouse blinker gets big like Godzilla in order to maintain visibility. Small children should be taken out of the room before demonstrating this frightening feature.

More broadly, reading this manual made me realize (a) how many of the ideas of the modern GUI probably were influenced by the Symbolics, and (b) how many more ideas 1981 had than today. The sense of freedom to do anything, try anything, is all over the document.

Speaking from experience, I guarantee you that anyone who starts saying "centis" instead of "percent equals," whether in the context of Hoon or Haskell lenses or anything, will never go back. I have to force myself to "code-switch" when speaking to the uninitiated, even in a technical context that has nothing to do with Urbit. And I'm not the only one.

I can't fault Haskellers for their daring in pushing the limits of programming languages as a UI. For instance, the idea of custom, library-specific "line noise" terrifies me. Hoon has no macros, no custom syntax, no operator overloading, etc. Once you've learned the line noise you've learned it.

The lens library in particular is a DSL by anyone's definition. Arguably (well, I'd argue it anyway), the ease of constructing DSLs is a trap that's impeded adoption of both major families of FP, Lisp and Haskell/ML. Plenty of people have made the "DSL == write-only" argument, so hopefully it's sufficient to just reference it.

Lens is in a sense the quintessential expression of Haskell; I don't know how anyone grounded in reality could expect the average Java programmer to learn and master it. And yet, everything it's doing is beautiful and true and right. Basically, resolving this contradiction strikes me as the essential problem of functional programming, if not just programming, in the next decade. I personally am very far from being the most qualified person to solve this problem. But I feel not enough people are working on it.

That's pretty much what a mold is. The syntax is written to look as much as possible like the description of a set, but the semantics are that you're actually defining a function.

I want to stick to ordinary American high-school math as I remember it. I learned "domain" and "range" in high school. I don't know anyone who defines these terms as something different. When I hear "projection" I actually don't think of set theory, I think of linear algebra, affine transformations, etc. If it would confuse me, I can hardly confuse others.

The distinction between a tree and a DAG is always a matter of interpretation. From the programmer's perspective, a noun is a tree. From the machine's perspective it's a DAG, because we share pointers and use reference counts. Either perspective can be misleading if you're expecting to think in terms of the other. If I saw the three-sentence definition of a noun, I'd assume it was acyclic, but others as we've seen above would assume it was cyclic. This stuff is hard.

The probable future of this text is that we release all the chapters pretty much as they're written, then edit it and turn it into a book.

The next tutorial is a lot less wordy, and should hopefully shed a good amount of light backward on this one.

Cells make you think of a+bi a little bit, but no.

(Actually I was very pleased when I realized that signed integers have no place in a fundamental interpreter.)

We're at a pretty shallow level of disagreement here, because you'd just add descriptive names to the combinator definitions. I'm not sure this would improve the learning curve much if at all, but it couldn't hurt much either.

As I always say, there's a difference between real and apparent learning curves. I don't think your perception of the apparent learning curve is wrong. But some things are easier than they look; one of those things is remembering associations. I've seen a good number of people walk the real learning curve for this language, and it's not that steep. Hopefully reality also gets a vote.

It is right! You do have clue!

This is excellent feedback. Normally I'd agree with it. Ideally, this will be the last cliffhanger in the tutorial...

Yeah, that's pretty accurate.

My own math background is limited enough that this magic word doesn't naturally occur to me, though I do know what it means.

That's usually a red flag for me; I want to keep the level of modern math required really, really low. In fact, when I use math-ese in the doc, the goal is to avoid confusing people who do actually know math. As this discussion illustrates, that's quite a bit harder than one might expect.

Nock: http://urbit.org/docs/dev/nock

From OP, in the section "Our first mold":

After seeing a few span examples, are we ready to describe the set of all spans with a Hoon mold? Well, no, but let's try it anyway. Ignore the syntax (which we'll explain later; this is a tutorial, not a reference manual), and you'll get the idea:

  ++  span
    $%  [%atom p=@tas]
        [%cell p=span q=span]
        [%cube p=* q=span]
    ==

This mold is not the entire definition of a Hoon span, just the cases we've seen so far. In English, a valid span is either:

- a cell with head `%atom`, and tail some symbol.

- a cell with head `%cell`, and tail some pair of spans.

- a cell with head `%cube`, and tail a noun-span pair.

I do think this is clear enough. I'm not sure it's intuitive enough. The following chapters should help with that; sorry.

The runes (a) help you remember the combinators, and (b) are two characters long.

To get to reasonably precise, meaningful keyword bindings for this set of combinators in particular, perhaps you'd be replacing ":-", ":_", ":+", ":^", ":*", and ":~" with ":pair", ":reverse-pair", ":triple", ":quadruple", ":tuple", and ":list" respectively. This is a pretty benign and easy case, and you may have to trust me on what kind of hash this search-replace alone would turn a Hoon file into. Then again, I suppose it all looks like hash to you.

Language design is hard; you can't please everyone. Probably the best-case scenario is that you please some people, and the rest are dragged kicking and screaming. And that's a best case.

"Nouns don't have cycles" in two senses.

Abstractly, a noun as defined is a tree and trees don't have cycles. So there! :-)

Concretely, the Nock interpreter, which Hoon compiles itself to, has no way to construct a "noun with cycles," like your A == [A A]. I sense that this is what's really bugging you. :-)

Of course, Nock is written in C and uses a C data structure. When we manipulate this data structure from C, we can certainly construct all the degenerate "nouns" we like. This generally results in a quick trip to the noun hospital.

I'm genuinely surprised at how few acyclic programming languages exist. True, there are plenty of algorithms with faster asymptotic runtime given cyclic/mutable data structures. There are lots of ways to manage this problem, though.

And both for persistence and network transmission, acyclic structures are just much easier to handle. You'll notice that all major network data models (XML, JSON) are acyclic, as are SQL and NoSQL databases alike. Cyclic databases exist [1] [2], but they're very much the exception.

And of course, acyclic data models mean you don't need a tracing garbage collector. Are doubly linked lists, etc, really worth a tracing garbage collector? Anyway, in a language/OS where transmitting and persisting state are core features, acyclic data seems like a pretty easy choice.

[1] https://en.wikipedia.org/wiki/Network_model

[2] https://en.wikipedia.org/wiki/Object_database

As soon as the nginx cache times out, the offending text will read:

A noun is an atom or a cell. An atom is any unsigned integer. A cell is an ordered pair of nouns.

Nouns are trees; they have no cycles. Noun comparison is always by value (the programmer can't test pointer equality). Nouns are strict; there is no such thing as an infinite noun. And nouns are immutable. There's just no way to have any real fun with nouns.

I hope this is a little less confusing. Thanks again for your feedback!

Yes! Although there are some things Lisp did 50 years ago, that aren't here. But this is less an improvement on Lisp, than a tribute to Lisp.

Chapter 1 should remind you less of Lisp. Although I do expect to hear "that's just caddadr"...

Back up.

This works fine for C, which is a keyword language.

What you'll find if you look at Hoon is about 100 combinator runes, which are digraphs like "%=" ("centis") or "|-" ("barhep"). (There is of course a power-law usage distribution -- a few common runes dominate.)

If we had to invent and remember semantic names for each of these runes, that binding would really be a lot of work to remember. We could say "mutate" instead of "centis" and "loop" instead of "barhep". Remembering these bindings would be quite a lot of work.

Of course, we could use reserved words directly; you can experiment with translating Hoon into reserved words. (The earliest experiments used keywords with a sigil, like ":loop".) To my eye the keywords look hideously verbose and are easily confused with symbols.

You also lose the ability to classify, say, "|=" and "|-", as closely related runes. This is especially useful with unusual, rarely used runes; what is "|/"? You might not know, but you know that it starts with "|", so it makes a core.

Thanks for the detailed feedback!

As of sentence #3, it looks like a noun can contain cycles. I mean, it can be a cell, and a cell can contain nouns, so that seems like a cycle. Then, in sentence #5, I'm told they don't have cycles. What?

If we used the word "tree" and "leaf" here instead of "noun," would that help? "A tree is a leaf or a cell. A leaf is any unsigned integer. A cell is an ordered pair of trees."

It doesn't strike me that anyone reading this definition, even not knowing what a "tree" and a "leaf" are, would assume that a tree can have cycles. And then, two sentences later, if we say that a tree doesn't have cycles, I'd hope that that would settle the matter.

It's probably a mistake to bring implementation issues (like the fact that you can share a pointer rather than copying a subtree, thus creating a DAG [1]) into a discussion of this level, though. All kinds of people have different kinds of CS backgrounds...

[1] https://en.wikipedia.org/wiki/Directed_acyclic_graph

But worse?

I assure you that we're not shipping Urbit with non-standard keyboards printed with "com" rather than ",". If these syllables rub you the wrong way, you're perfectly free to pronounce them any way you like.

Most people aren't speed-readers. I am, but only because I learned at an early age. I don't know anyone who speed-reads code in the sense you mean.

Happy to take PRs if you feel you can write it better. One of these paragraphs has to come before the other.

"Mathy" probably should have a link to https://en.wikipedia.org/wiki/Type_theory. My experience is that if you say "type" in the context of functional programming, people expect Bertrand Russell and have a right to expect Bertrand Russell. We're not delivering Bertrand Russell, so it would seem like false advertising.

A mold is a function whose range is some useful span. A mold is always idempotent (for any noun x, f(x) equals f(f(x))), and its domain is any noun.

I stared at this for a moment but was unable to make it any clearer. Suppose your span is the set of all cells. A mold for this span is a function that maps any cell to itself, and any atom to a trivial cell like [0 0]. Does that help?

See the comment above; it's nice not to need a separate framework. At least, for Urbit to Urbit networking.

Of course there's nothing stopping you from encoding or decoding anyone else's protocols in Urbit. Or vice versa. Actually, using bit functions on bigints is a fairly pleasant way of handling binary protocols.

There's also no particular problem in generating or decoding jammed nouns on non-Urbit systems. It's a binary encoding, but the decoder is a page of code. Perhaps jam:ASN.1 as JSON:SGML. :-)

CP is one of many IDLs [1]. IDLs are great, but there is always an impedance mismatch in translating a language's native data structures to a language-independent IDL. Someone has to do this work, though there are sometimes various scary ways to do it automatically.

In any case, the idea that validating or describing external or untrusted data is the job of an additional system outside the programming language, rather than the job of the language's type system, seems mainly historical. Sending data over the network was a new and unusual use case when most of today's languages were being designed. It isn't now.

[1] https://en.wikipedia.org/wiki/Interface_description_language

How many times a day do you want to say "percent equals" or "tilde ampersand," rather than "centis" or "sigpam"? Worse, you may not spend a lot of time reading code out loud, but when you read your brain still thinks the sounds.

Of course, you're free to prefer keywords to digraphs. But sometimes I worry that there's a reason the 787 looks just like the 707 [1], and it's not at all about airplanes...

[1] http://idlewords.com/talks/web_design_first_100_years.htm

From OP:

One obstacle to learning Hoon is that it has two quite distinct concepts that might equally be called a "type." Worse, most other typed functional languages are mathy and share a basically mathematical concept of "type." Hoon does not have this concept at all.

It'd be useful to hear what's unclear about this.

Ironically, the St. Louis hacker who first suggested urbit would be a great fit for Strange Loop (hi Justin!) is an African-American.

An obsession with collective identity and collective characteristics - all proletarians are noble, all Germans are masters, all rednecks are racists, etc, etc - is common, perhaps for obvious reasons, in the democratic era. And in particular, all parties responsible for the atrocities of the 20th century - Nazi and Communist alike - were thinking very much this way.

This insistence on generalization would seem very strange to most of our ancestors, who would find the leap from collective differences to collective uniformity quite irrational. For instance, Cardinal Wolsey, who governed England for Henry VIII, was a butcher's son. Englishmen of his time did not find this at all strange, though hardly any of them agreed that nobles and butchers were statistically identical.

Also, for some reason which is perhaps less obvious, not all of us have to "represent groups." It does not seem likely that either Alex Payne or Alex Miller sees himself as representing white males, for instance. Perhaps this freedom to see oneself as just an individual is the most subtle form of privilege - but I think everyone should have it.

"He has literally written that several of his co-speakers are genetically more fit to be slaves while he, a white male, is genetically designed to be a master."

Certainly a powerful use of the word literally.

Frankly, I'm actually considering recanting. Who wouldn't rather be Galileo than Giordano Bruno? But recanting is a serious matter - it's the sort of thing you need to get right the first time.

To appear at future conferences without my fellow speakers worrying that I'll enslave them or kick off Holocaust 2.0, it'd be ideal if someone can tell me what I have to believe. I'm guessing it's either:

(a) all human beings are born with identical talents and inclinations.

(b) human beings may be born with different talents and inclinations, but these talents and inclinations are distributed identically across all living populations.

Let's face it, Strange Loop is an awesome conference - there's a reason I applied. And I think Alex's decision is totally understandable for practical reasons, as someone downthread explains. If there's a chance of being invited back next year, I could totally go for (b). But if it has to be (a), I might still be all "e pur si muove" and stuff.

Hard-coded into the network layer? Not only is this not true, I can't even imagine how it could be true...

Exactly.

An easy way to think about solving the exactly-once problem, on top of an at-least-once message layer, is to use the at-least-once layer to write idempotently (eg, HTTP PUT) into a sequence of numbered messages.

There is no possibility that the receiver will execute message 18 before message 17. Each PUT retries until an acknowledgment is received, and the sender maintains a sliding window of sequence numbers it's trying to write.

All the Two Generals problem tells you, in this situation, is that the sender does not know whether the receiver got the last message. It's an important issue and I agree with the general sentiment of the OP, but perhaps it can be overstated.