I stand corrected, RFC 4038 seems to be what I was looking for. But it seems to be a late addition, and OS support is optional. If developers think moving their apps to IPv6 is too complicated, I can't fault them.
IPv6 could have done three things. First, embed the "legacy" address space. Second, have legacy-to-legacy connections use v4 on the wire. Third, strongly encourage existing user-maintained configuration (config file formats etc.) to remain perfectly valid as long as they don't use v6 addresses (or other v6 features.)
You are right, you'd still need a "legacy" address to connect to "true" v4 servers, but that address would be all you need, while most operating systems, routers, client and server software could be, technically, all-v6 all-the-time by now.
It sucks at being compatible with ipv4. The "billion dollar mistake" :-)
It also sucks at having software/hardware stacks nearly as well debugged as those for ipv4, which means running ipv6 at all is a security risk.
Nobody would switch for sundry technical advantages. The main driver for conversion is that ipv4 addresses are scarce. As soon as "we" seriously "move to ipv6", however, the scarcity driven pressure to convert is relieved. We're bound to reach an equilibrium that will include ipv4 for a long time, possibly forever.
From the article: "It’s not like they’re bumping it by a buck and making a little bit more money. They are really tanking sales and it kind of has a ripple effect to us, being a small company trying to do demand planning"
The relevant Econ 101 buzzword isn't "supply and demand," it's "agency problem".
Amazon is "tanking sales" unilaterally, while the supplier manages stock on assumptions of higher sales at the regular, lower price point.
Have you ever observed typical homeopathy users—middle to upper-middle class mothers of young children—in their natural habitat?
I have. They're all "true believers" in that they really think homeopathic remedies are useful, for themselves and their kids. And yet, despite that, they also exhibit a well developed instinct on when not to rely on homeopathy and send themselves or the child off to a "real" medical practitioner. Strange, isn't it?
It ceases to be inexplicably strange if you think about their shared belief in homeopathy as a socially evolved strategy about how to keep themselves and (more crucially) their children away from doctors in those plentiful cases of minor sniffies where a doctor is overkill and actually more likely to do harm than do any better than "doing nothing".
The sad thing is that society doesn't allow a mother to just "do nothing". Where there's no accepted alternative, she "must" visit a doctor, lest she be accused of neglecting her duty to care for her children.
That's why it seems that some parts of society—and not the stereotypically "stupid" ones at all—have evolved mechanisms that afford them social license to avoid the doctor when the doctor is more likely to do harm than good.
Alas, while Russian (and Chinese) general disinterest in f'ing with you does help, their equally developed general disinterest in your well-being means they might have incentive to sell or trade with entities more... interested.
I have no way of knowing how such changes would affect the wider installed base of FSet. All I can tell you is what I'd prefer myself.
I wouldn't mind, and actually prefer, if the default SEQ would signal a condition on out-of-bounds access (I'd also suspect that not a lot of existing code would break, but there's no way for me to know that.)
On the other hand, I don't think I'd get much besides having to rewrite code out of map lookups signaling a condition. I glossed over my uses of LOOKUP. For most lookups, the case of some element not being present in the map is normal behavior, expected and handled.
For a minority, an element not being present is an error, but for a majority of those, a specific error message is appropriate, so there'd still be explicit checking and no advantage from signaling within LOOKUP.
The smallest group of LOOKUPS expects the lookup to succeed without checking. In all of these cases, the lookup will succeed unless some code is buggy, and in all cases, a bogus NIL would be consumed immediately by a function that would signal a condition on getting a NIL.
So my personal favorite default kind of map would return (VALUES NIL NIL) for lookup failures but would not have a default for purposes of the MAP-UNION etc protocols.
An alternative (or additional) change that would work for me would be an additional optional function parameter to MAP-UNION and friends which, if present, would handle default values.
You are right, the 1960 paper describes a language that is a pure functional language. I think it even was the first published pure functional language (pointers to earlier work welcome, of course).
Does Clojure predate FSet? If you hadn't written "now" here, I'd have guessed otherwise.
My only complaint about FSet would be map default values; not necessarily the fact they exist, but (1) when using defaults, that two maps can compare equal even though they have different defaults, and (2) when not using defaults, the way they nevertheless intrude upon the map-union protocol, necessitating handling of otherwise unused default values (usually NIL).
But I love FSet when using CL. Thank you for writing and publishing it!
Incremental recompilation isn't fast enough to wait for between keystrokes, so in-process servers would run in their own thread. Along with accounting for arbitrarily incompatible language runtimes and memory management schemes, wouldn't we be looking at badly re-implementing half of a process-and-ipc infrastructure here, just without memory protection?
> Some population groups are surviving hybrids but the percentage is very small
The pure genotypes were obviously out-competed, surviving Europeans and (East?) Asians are descendants of hybrids.
Aside 1:
> Asian is much less AFAIK, it's mostly a European thing)
Latest I heard is that it's actually the other way around, East Asians are more N. than Europeans.
Aside 2:
> my own Neanderthal percentage is just 2.4%, so I'm actually almost more Jewish than Neanderthal
So you've been told that you're mumble percent Jewish? Have you verified that you don't just happen to have a bunch of perfectly European genes that—even though characteristic for Ashkenazic Jews—are not at all unique to them because of their >60% European admixture?