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.
If you want to make a more universal phoneme-generator, the basic contours of a nearly-universal [1] phonotactics is as follows:
* Strict CV syllable scheme.
* Atonal
* Consonants distinguished only by voiced/voiceless (Chinese, e.g., doesn't do a voicing distinction, but switching to an aspiration distinction would suffice for them)
* 5 vowels: a, e, i, o, u (actual vowel quality may vary; every language that has at least 5 vowels has these 5 vowels) (some languages, particularly indigenous languages in North America, have 3 or 4 vowels, but the intersection yields too few vowels).
* Consonants are harder to inventory. /p/, /t/, /k/, /m/, /n/ are nearly universal, and /b/, /g/, /d/, /s/, /z/ are also quite common. The IPA /j/ (that's the 'y' in 'ya' for English speakers), /w/ (pronounced as you'd think in English) are pretty common semi-vowels. Maybe /l/, /ʃ/, /ʒ/ as well, should you need more consonants.
That gives you 25-75 plausible syllables, depending on how many consonants you go with.
[1] If you go by least common denominator, you end up with maybe 1 vowel and no consonants (there's no consonant phoneme present in every language IIRC).
Doesn't Lojban try to have pretty easy phonotactics or something? They do have consonant clusters, but I thought they did some kind of study and chose their phonemes and some rules on the basis of things that most languages wouldn't find too difficult.
Edit: not suggesting that Lojban's solution is somehow preferable to your advice, just trying to remember what they did about this issue.
Lojban uses the consonants I gave (sans /j/ and /w/, although these are counted as dipthongs instead), plus /f/, /v/, /x/, /ʔ/, /h/, and /r/, as well as /ə/ for a sixth vowel. The syllable scheme seems to be largely C(C)VC(C), with largely only mixed voiced/unvoiced and geminate consonant clusters prohibited. That said, they do allow for "buffer" vowels in pronunciation to aid speakers who have trouble with consonants (and yet they have a /ə/?).
From what I can tell, CV(C) (with the second consonant usually having some restrictions) is fairly widespread. However, in my personal (purely anecdotal) experience, pronouncing foreign consonant clusters or unfamiliar final consonants is much harder than pronouncing unfamiliar initial consonants or vowels, so I'd be slightly wary of letting the final consonant go too unrestricted.
"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...
> "Constructor" already got used by C++ for something different.
Constructor was used (long) before C++! For instance, the "cons" function in Lisp stands for "construct", and speaking of which, ANSI Lisp even has "boa constructors" (by order of arguments). We are used to having terms like "constructor", "array" or "variable" have different shades in different languages. If I reach for Awk to munge some text fields, I'm not suddenly confused because its "arrays" are not like C arrays or Fortran arrays.
The same terms being used is actually helpful, because the terms form the pivots in conceptual mappings between languages, and comparisons. Even if two languages have different notions of what is a "variable", they are used in similar ways. It's easier to hang different shades of meaning on the same word than to memorize some made up new word. Even something quite different, like placeholders in pattern matching or predicate logic, can still be called "variable" without causing confusion.
Think about parameters/arguments. They can be by value, by name, by reference, or normal order (lazy). Using a different word instead of "parameter" for all these would be counterproductive, and make it harder to speak comparatively.
Bottom line, people aren't complete idiots.
"The Flunk language has flurbles, which are like C++ variables, but not exactly, so we use a different word. Unlike variables denote locations which do not have a type and can store any value." (Gee, that's just like "variables" in some existing languages that are not C++.)
Maybe that's the point. If you implement, say, arrays very badly, and call them arrays, then everyone can easily criticize you in very direct terms: "Flunk has arrays, but they are broken compared to Python arrays, or even C arrays and Fortran arrays". The left-most "arrays" in that sentence can be a straightforward, blue-underlined link directly to the Flunk documentation which describes arrays. But if you call then batteries, then such a comparison gets confounded with distracting explanations. It's harder to argue that Flunk has broken arrays, when it has something called batteries that hold cells which have polarity and whatnot. First you have to argue that they really are just arrays under a different name, then you have to argue why they are bad compared to arrays, and why that still matters in the context where they are batteries. By the time you're done, you look stupider than Flunk, and more negative than the (-) end of a Flunk battery.
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"...
Take the blockchain out of Etheruem, and you still have a pretty cool deterministic state-transition machine. My understanding of Urbit is very limited, but I believe it has a similar concept of Ethereum without a consensus protocol.
They're probably worth distinguishing somehow for newcomers. They're both transaction logs.
Ethereum is a transaction log with a consensus mechanism. Anyone can append to it. It's a scroll: any group or society can use apps that check the scroll to come to conclusions about the state of their interactions.
Urbit is a transaction log that only the owner can append to. It's a journal: users can safely append to their journal with any app, and their apps can read the whole journal to display data from multiple apps in desirable ways.
Which begs the question, why is Urbit necessary? It would be relatively simple to port Ethereum's consensus protocol to "only a user with key X can sign new blocks" and each block would contain exactly 1 transaction.
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.
I'd actually put Blockstack in the same category as Ethereum. From a transactional log perspective, it uses the Bitcoin blockchain for consensus on the log and from an application development perspective, you can build apps using Blockstack (gives you naming, auth, and storage).
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 mean, it is possible that hundreds, possibly thousands, of people have misinterpreted your writing on colonialism, human biodiversity, etc. However, you seem to be smart and a better than average writer (if florid, at times). It seems like someone of your intelligence and writing ability would be able to make a point effectively, without so many misunderstandings.
But, I hope that I have misunderstood your writing on those subjects.
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.
> 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.
There's a reason why the IETF decided to switch to 2^128 for IP6. Mainly, because there are more computers and devices that need addressing than IP4 can handle.
I have to question the design of Urbit why you chose to go with 2^32 addressing space?
> 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.
Again, the future is "Pay to Play", just like Ethereum? And, is that a population control argument? How would you propose to "stop expanding exponentially"? Chinese method? Ender's Game method, or something else unsavory?
> 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.
Ah, so you are the "governor", hence why it must be governed? This is literally artificial scarcity on something that could easily have been near infinite
> 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.
So switching from one master to another makes better "freedom"? I get being against walled gardens. I'm against them as well. But you make no point why Urbit isn't just another walled garden (using funny language to hide behind it no less) with you at the helm.
> I have to question the design of Urbit why you chose to go with 2^32 addressing space?
They haven't. They went with base 256, for easier recognition of 32-bit (and 16-bit, and 8-bit) numbers. You can get a 2^128 identity or a 2^32 identity (or others.)
The fact that 64-bit numbers (like ~novfes-lodzod-sibfes-talzod) in Urbit's base 256 are twice as long as 32-bit numbers (~sibfes-talzod) which are twice as long as 16-bit numbers (~dalryp) and down to 8-bit numbers, which are the most memorable and highly coveted (disclosure: you're looking at a comment written by ~del, aka Hex number 0x25) is something between a feature of Urbit's networking stack, and an unavoidable consequence of doing math and dividing things up between persons that are remote from each other, therefore each needing addresses to be identifiable.
Identities that are made of 128-bit numbers are free, and essentially unlimited. They are basically public key hashes and the risk of a collision is sufficiently low that there is no need for them to be generated by a single authority and centrally assigned. (Note that this does not necessarily scale to the population of the earth and beyond as a solution to addressing graph nodes and efficiently routing traffic between them.) Identities that are made of shorter numbers are limited in number and assigned hierarchically; even if there are a boat-load of 64-bit numbers, it's not half as many, it's ½^64 times as many. Certainly there are more 64-bit numbers than humans on Earth today, or for the foreseeable future.
Whether you consider this to be more problem or solution will probably depend a lot on which side of the spam-wars you find yourself on. Currently there is no Urbit software or infrastructure that I am aware of that algorithmically discriminates against one kind of numbers or another.
You won't expect one authority to differentiate each of 8-billion humans and make sure that each one is granted a separate identity (but not more than one), will you? How about 256 such leaders? Still seems far-fetched, doesn't it... especially given the difficulty of coordinating 256 separate leaders. 65536 very smart individuals probably also cannot be expected to coordinate the identities of the rest of the humans in the world. It would be gargantuan undertaking just handling it when some of these leader-folks have forgotten or lost their passwords (and potentially disastrous for the 0.0015% of the world's population under their charge.)
64 bits of hierarchical ID space is enough for every 32-bit identity (planet) to individually dole out as many 64-bit numbers (moons) as there were 32-bit numbers to begin with. Urbit takes advantage of this roughly to make scaling the network's identity framework to rather immense proportions, happen at least a bit more naturally.
If your 32-bit leader gives a lot of 64-bit IDs to people that turn out to be spammers, you run the risk of being lumped in with those spammers by algorithmic processes. Imagine such a process that tries to discriminate against spammers and keep them from spamming everyone who is known on the whole network, at any scale. It's not a simple proposition, at all!
Do these things also get released if the person holding them dies?
(the reasonable assumption being that only a tiny fraction people will bother or care to actually make arrangements for this)
Or even without death, the idea being urbit "property" is all cryptographically locked tight, correct? So can a planet get lost? If someone loses all their keys or a server park gets droned and the dog ate their backups or something?
