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