yarvin9

I was in the top cohort and I'm an Internet supervillain. Or something. You get what you select for, I guess!

By "in his post announcing his talk," I assume you mean "in his post defending himself and explaining his perspective, after being attacked by HUAC, Red Channels and the entire John Birch Society."

I shouldn't post. But at long last, sir, have you no decency?

You're very eloquent and also learned. But for every programmer who knows what an ANSI Lisp "boa constructor" is, there are 100 who know what a C++ constructor is. And it's an 11-letter word that means something completely different in a completely different language.

But maybe it's worth it to stop the middlebrow dismissals! Our grandparents went to the moon. We complain when we have to learn a slightly new idea, and faint like Victorians contemplating legs if it has a new name.

"Argument" is another good one. Hoon is a single-argument language that favors tuples, not currying. So an add function, (add a b), is actually (add [a b]), or in Lisp (add (cons a b)).

In Hoon, you can call a and b "arguments" all day long. It's an informal word. But [a b] is "the sample." You can see the chaos that would result if we called it "the argument" or "the parameter"...

"Constructor" already got used by C++ for something different. A Hoon mold is more like a C++ struct than a C++ constructor.

And if you saw a file of Hoon molds, in normal programmer English, you'd say, "these are type declarations." I might even say it myself.

As for the external representation -- it's a name for a file containing a Hoon mold. Actually orthogonal to serialization format, as all nouns are serialized the same way. It really is more like a MIME type, if a MIME type was a function you could run. There's no word for this.

There is a common programming term for a set of values. The word is "type." "Domain" is a little bit odd, because we usually compute the "type" (span) as the range of an expression...

Bottom line is, this stuff is hard!

Mainly because (as Vitalik says) "the whole Ethereum network has the power of a 1999 cell phone."

Although Urbit (like Ethereum) is precisely defined without dependencies, Urbit is not a consensus computation platform. It's for processing your own data on your own (virtual or physical) machine.

Consensus computing is incredibly inefficient and should be used only where absolutely required. Where consensus is not absolutely required, computing should be localized under the user's control. People often forget to include this component in their designs of the decentralized future. But in fact, Ethereum needs something like Urbit and vice versa.

One way to think about the difference between Ethereum and Urbit: it's like the difference between a superconductor and a regular conductor. On the one hand, superconductors are qualitatively different and fundamentally more powerful. On the other hand, there are no superconductors in your iPhone.

Urbit too. Thanks!

Ha! I can assure you that by the time Urbit is ready to compete with Facebook, it'll be as easy to sign up for as Facebook. That's a necessary condition, not a sufficient one. It ain't happening any time soon, neither.

Metcalfe's law is an impossible problem in theory, but not necessarily in practice.

For instance, one way for a new system to get around Metcalfe's law is to steal the network effect of the existing network. This is the same principle as in Tantek Celik's POSSE (publish on self, syndicate elsewhere) design, but a little more general.

Concretely, it's very hard to compete with Facebook, but relatively easy to let a user control their own Facebook account from their own general-purpose computer. Especially if you can get them to bring their own API key ("BYOK").

From controlling your own data in Facebook, you may move to mirroring it; from one-way mirroring, to two-way sync; from two-way sync, to discarding the silo. So it's not even necessary to replace Facebook in one impossible step; you can build a stepladder for users to migrate off gradually.

Of course, that this is possible doesn't make it easy!

When I say "the browser for the server side," what I mainly mean is the isolation layer between the browser and the OS.

For example, suppose someone designing the first JS environment at Netscape had suggested that since JS is so great, you should be able to make POSIX system calls from it. Or link to locally stored libraries. Or use a language someone had heard of before. I think you'll agree that if this decision had been made, most people would never have heard of JS.

The browser is a second-level OS which provides a service no first-level OS offers; it loads applications almost instantly and sandboxes them securely.

Now, in theory, you could modify a Unix to solve this problem. Arguably, it's a problem any OS ought to be able to solve. We are certainly much closer with containers. But still, imagine what it would take to replace webpages with Dockerfiles. (sandstorm.io is the closest to something like this; definitely check them out as well.)

Urbit's semantics are isolated from the platform in just the same way. The job of a general-purpose personal server is very different from the job of a general-purpose client -- they have almost nothing in common. But the isolation layer over the current systems platform is the crucial element.

"I'm not a communist, but..."

The difference between a language with symbolic names, and a language with names and macros, is a difference between one level of indirection, and two levels of indirection. My view is that one is hard enough.

Macros aren't functions. A function call is one thing. A macro can expand to arbitrary code. This code may contain function calls or other symbols.

Before you can even interpret these symbols, you have to expand the macros in your head. This is two steps, rather than one. Expanding is not tracing. This extra step is why whoever is reading your code is so easily tempted to give up and writes it again herself, with her own macro language.

I was not comparing FP to C. If you look at actual Hoon code, it's pretty comparable in size to other functional languages, and also in clarity once you learn to read it. Obviously C is much fatter and harder to understand (and has macros, of course).

~bitret, I remember you from a while back!

A planet is like a car -- it's not a toy, it's a tool for a responsible grownup. There are about 4 billion adults in the world. And not all of them are even Internet users.

Of course, the population keeps growing. Eventually either people have to learn to share, or the price will go up, or humanity will learn how to stop expanding exponentially.

Think of a planet as a unit of autonomy and reputation, not of personality. The global supply of autonomy is 2^32 units. That's not perfect in any sense, but if the supply is infinite the network is ungovernable, and the value of each unit is zero.

It's also an improvement on a world in which there's one unit of autonomy, and its name is Mark Zuckerberg. Urbit does a lot for digital freedom, but we're not in the miracle business here. No one can do infinity for digital freedom.

Urbit ships are synthetic names that sound like human names in a foreign language. Eg, ~sondel-forsut. This is just a 32-bit number in a phonemic base-256.

Our experience is that people rapidly bond with their ship names. Apparently no one is too old to want a secret codename. And human beings of a more grownup character can interact pseudonymously through dignified, impersonal synthetic names -- instead of retarded juvenile handles as on Wikipedia etc, or real names as on Facebook.