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?

A similar design is Proquint, which IPFS uses:

https://www.npmjs.com/package/proquint

Proquint (5 letters per 16 bits) is tighter than Urbit's `@p` (6 letters per 16 bits). The Urbit form was designed for synthetic names and restricts itself to phonemes that sound comfortable and natural to English speakers. (Not to say that English should be the universal language, it's actually a terrible language to make everyone learn, just that it is.)

Word lists work reasonably well, but they're quite bulky and they don't take advantage of the human hardware accelerator for learning new words. When you have a GPU, use it. These kinds of synthetic strings also make great passwords, BTW.

(Disclaimer: Urbit guy here.)

This is a pretty good thread:

https://news.ycombinator.com/item?id=11851849

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.

I remember that commercial!

Exactly right. Just think of Urbit as the Information Super-Duperhighway, and you can't go wrong.

It's an axiomatic interpreter not based on the lambda calculus.

It matters because gensyms suck. More generally, if you are building a two-layered system in which a compiler targets the interpreter, symbols, functions, and scopes are concepts that belong in the high-level language, not the low-level interpreter. (I think Shen is one example of a typed Lisp that targets an untyped Lisp, but obviously I know nothing about Lisp.)

So the lambda calculus is a classic layer violation.

Where I went to school in operating systems, which was Brown and Berkeley, we were taught to avoid layer violations and always separate mechanism from policy. Not sure what Lisp people are or were taught -- honestly, there were not a lot of them left, even in the '90s -- but it never seemed to include this.

I always look at a stateful Lisp machine, or Emacs, or whatever, and see a giant structureless blob of symbols. That said, this is probably a totally unjustified prejudice on my part, and at this point I really have no excuse except lack of time for refusing to learn more.

Hoon is mainly built on a fixed set of hardwired, built-in macros. This is how I can be so confident about not needing anything like gensyms (what eliminates gensyms is having a subject which is navigated geometrically, not symbolically).

The advantage of fixing the set of hardwired macros is that, when reading code, everyone knows exactly what every line is doing, without having to indirect through the local macro environment. Macros are the first step toward a DSL.

DSLs are always and everywhere a bad idea. They may make code slightly cleaner or better-looking. In exchange, they add a level of indirection to the task of trying to understand it. This is the source of the nickname "write-only code," a common failure mode in FP. Write-only code can also be created by extravagant and pointless use of higher-order or non-strict programming, both of which complicate the task of reading code.

For instance, Hoon has a rune (keyword or digraph) for a 2-tuple, a 3-tuple, a 4-tuple, but not for a 5-tuple or up. Why? The 4-tuple cons pulled its weight, the 5-tuple didn't. For every special form you add to Hoon's fixed, limited set, you're imposing a cost on anyone who has to learn Hoon.

I hope you can see the UI advantage to functional programming in an environment of controlled evaluation complexity. IMHO, too much of FP is a world in which every program is its own language.

Which one is right? Actually, I feel it's possible that the only real language is K, and the rest of us are just phonies.

Actually, if you watch the video of the LambdaConf talk, I believe you'll see me deride Lisp as having (and needing) dynamically typed atoms.

I had no idea the concept of an atom had indeed degenerated all the way into complex numbers, which to me and to all decent Americans will always be a "cons" cell. Obviously I had not reckoned with the full and complete degeneracy of Clozure Common Lisp Version 1.10. Or something. If I knew Lisp, I could perhaps condemn it correctly.

In any case, sir: you are misinformed. A "dynamic" type system isn't actually a type system. At best, it's a sort of crutch for retired Jedis who can barely swing their obsolete, one-ended lightsabers.

Or do you wish to become enlightened? Come visit our library, old Jedi. At urbit.org, we have all the enlightenment you need. The age of Lisp was glorious, true. But much time has passed and much we have learned. The times change, uncle, and we must change with them.

Learning Lisp is easy. Learning Haskell is hard. But unlearning either is next to impossible. So anyone writing a new functional language would be best advised to not have that problem.

Now, one might feel differently if Lisp, or Haskell, or any other functional language, was such a conspicuous market success. Under the circumstances, however, I don't think one can be faulted for the suspicion that perhaps functional programming is too important to be left to the functional programmers.

I think we'll have to disagree about whether or not Lisp is a typed language. I realize that people with IQs of 175 have an uncanny knack for taking indefensible positions and then defending them, but I'll just have to take this one on trust.

While we're measuring our respective equipment, however, we can agree that Lisp has macros. Hoon does not have macros, because it's a pure typed language and a pure typed language doesn't need macros.

If Hoon did have macros, however, they would be inherently hygienic, without anything like a gensym. If this is a good time for you to favor us with a lecture on the virtues of Lisp, perhaps you could start with gensyms and their place in "Maxwell's equations of software."

#1 is a pretty serious charge. You posted this four hours ago and haven't posted any evidence to substantiate it. Maybe you confused Urbit with another project, and would like to retract? It's certainly an understandable mistake.

#2 is not worth bringing up again, but you might want to look carefully at the dictionary meaning of the word "avowed." If a person denies being a communist, it is still possible for him to be a communist, but perhaps it doth protest too much if you go all the way to "avowed communist."

#3 seems improbable, as (a) I don't know Lisp, and (b) Hoon is a typed language. "Only dedicated people would learn it" sounds like an interesting marketing tactic which must involve some kind of strong reverse psychology. Frankly, I have enough trouble with basic forward psychology.

#4 would be perfectly true, except that the company owns less than half of the Urbit namespace. The rest has been distributed across about 50 more or less random individuals.

(I think I know the hackerspace you mean -- Bloomington? A bunch of them drove to LambdaConf and interned. Incredibly smart, nice and wonderful young people, needless to say. I'd hang out with them all the time if I lived there.)

Sorry: http://www.urbandictionary.com/define.php?term=TFA

As a practical matter? You censor yourself. And/or practice the great art of Ketman [1].

Criminalizing points of view is harder to implement, as a practical matter, than criminalizing behavior that most people today see as actual, victimful crimes. There's no equivalent of "grass mud horse" [2] for terrorism, childporn, etc. As the Chinese government is very aware, even a well-censored network is way more dangerous to them than no network at all.

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

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

It's certainly a tradeoff which admits no perfect success. Yes, any network that isn't hosted on the FBI's own servers can be used for some sort of crime. Fortunately, in our real republic as it stands, there's a relatively wide margin of safety between government-pwned networking on the top, and a darknet on the bottom. Let's hope it persists.

As I hope TFA makes clear, "republic" is not a synonym for "democracy." [1] If it's possible to build something useful and effective with "lots of online voting," I don't know of any examples.

Successful multipolar/federated systems (which are republican enough for me, anyway) have existed. Like Usenet.

As a Usenet veteran, I have a tough time with the idea that Google killed Usenet. Google bought DejaNews in 2001, and Usenet was already pretty dead in 2001. Yes, some Usenet groups survived and have become effectively Google groups, but without Google I suspect they'd just be dead.

The conventional wisdom, which seems right to me, is that Eternal September killed Usenet (with the assistance of alt.binaries). It would be interesting to see an argument against this theory.

You also seem to be suggesting that Usenet died because it wasn't profitable enough. I suppose it wasn't profitable enough to carry alt.binaries. But its costs, for regular text posts, didn't seem extreme even in the 90s.

In fact, not to get all commie on you, but one of the neat things about Usenet as a digital republic was that no one owned it, and no one profited from it. The positive social value of this principle is seen in a variety of institutions. Compare to Burning Man, for instance. Who would show up for burningman.com, a subsidiary of Ticketmaster?

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

(edit: formatting)

Yes. And the same is probably true of the browser you used to post this. Also, the OS it's running on. It's the price of being "evergreen."

It's worth thinking about why we've accepted this tradeoff. The cost of evergreen software is that we put all our eggs in one basket, and watch the heck out of that basket. The benefit is that we solve a huge set of system administration problems that would otherwise be ridiculously impractical.

One metaphor I like to use is the difference between the Soviet and American design styles in aerospace. The Soviet way was to build systems with loose tolerances that worked okay even when parts were a little out of spec. The American way is to build systems with precise tolerances that work perfectly when everything is right, and fail catastrophically when it isn't.

There's much to be said for the Soviet style, and indeed it might be summed up well in Postel's law. But as the problems you're trying to solve get harder (like keeping all the world's browsers updated), it doesn't scale very well. If we compare the problems we can solve with manual upgrades and Postel's law, to the problems we can solve with automatic upgrades and rigorous protocol validation, there's no contest.

Thanks! The appropriate authorities have been contacted :-)

I don't know that anyone has tried to build a practical system on top of SKI combinators, which are certainly simpler than Nock. It's probably quite hard.

You can build a practical system around the lambda calculus, which is arguably as simple as Nock. But you don't build a practical system by building layers on top of a simple lambda interpreter; you do it by extending the simple lambda interpreter, until it's no longer simple.

The critical feature of Nock is that it's very simple and you don't extend it, you layer on top of it. So, for instance, it's very easy to upgrade Hoon's syntax or semantics over the network in a live system, because the interpreter is a Nock interpreter and doesn't know anything about Hoon.

How could anyone not be familiar with Ted Nelson's work? In the broad sense, anyway.

I think the crucial layer that we need to implement... a lot of things... is a global immutable (aka referentially transparent) namespace. Urbit is one project building such a thing; another one is IPFS. (Urbit names are addressed by identity; IPFS names are content-addressed; so they're complementary and not competitive.)

One of the reasons the Web seems like such a poor imitation of Xanadu is that it rests on this rickety foundation of a mutable binding from name to resource. Once global immutable namespaces -- Urbit, IPFS, anything -- are more widely deployed, I think Xanadu would be wise to use such a thing as a layer.

But to paraphrase a famous saying: grant me the serenity to accept the code I cannot rewrite, the courage to rewrite the code I can, and the wisdom to know the difference :-)

You can certainly blame our (old) doc for that. Sorry for the bad experience -- we're definitely still at the stage where I wouldn't expect people to be playing with Urbit and not asking for handholding. Even more so this spring.

Sorry, this is a ridiculous parochialism on our part. In America, which is where English was invented and is also of course the biggest bestest country in the world with giant atomic bombs and stuff, we don't say the "h."

But apparently there's some little islands or somewhere where they do. Will fix.