I'm glad to see that you make this important moral decision about right and wrong come to dollars and cents. Sounds right to me.... NOT!

The posted a clear no-fly warning on the corkboard of their interplanetary local office.

Map reduce ain't pure functional programming. Map-reduce as implemented in practice today uses storage which breaks the purely functional paradigm. It is a good example of mostly functional though.

It does scale. I've got news for you but there are no 100% completely secure systems out there. They are all mostly secure but if I really want in I can send the Army, NSA, FBI and CIA and compel you to break the system open for me. I don't know if you follow the news, but we have several recent examples where this took place.

From TFA:

Spoken like a true academic. Mostly secure does work in practice. My house is mostly secure, my car is mostly secure, my bank is mostly secure. None of them are perfectly secure, as all of them would fail to a sufficiently strong attack, but generally they do fine.

So does mostly functional programming. It works great in practice even though it is not 100% safe but neither is functional programming once you allow monads which are needed to make FP Turing complete.

So Erik Meijer is arguing that mostly functional programming which is widely used in industry "does not work" and suggest instead purely functional programs which have been around for decades and gone nowhere?

Through the looking glass indeed.

Actually this is a recent affectation. Historically mathematicians very much enjoyed the interaction of mathematics with the real world, e.g. Archimedes, Isaac Newton, Fibonacci, Euler, Gauss, Hilbert, Poincare, Pascal, Bernoulli, Cartan, von Neumann, Turing, Dirichlet.

More recently we have Stephen Smale, Terry Tao and Tim Gowers all three mathematicians of the first order who have dabbled in various applications.

The IPv6 head start is so minimal that Linksys shipping a new shimming protocol with its NAT routers would exceed IPv6 usage within six months.

IMHO that is still the way to go, because IPv6 just isn't happening.

There in lies your key error. You can have those packets be routed to an extended-field capable router using existing BGP/IGP routing protocols. The switches do not need to know anything about the extended field behavior to do that.

IPv6 was particularly badly designed in terms of ease of implementation. It has many other virtues but easiness of implementation ain't one of them. A Jackson-Pollock-design-style protocol is likely easier to implement than flag day IPv6.

This is exactly why we are running out of IPv4 addresses and we still do not implement IPv6. If you want to carry on arguing that IPv6 is the superior choice you are welcome to it, but you have a mountain of facts and 16 years of trying against you.

Oh wow. You win then. An IPv6 fanboi,erh,sorry,strong proponent routes ~40% of his traffic using IPv6. Color me impressed.

Seriously dude, reread your statement. You are damning IPv6 with faint praise when even a proponent cannot get the count over ~40% the day before we run out of IPv4 addresses.

Globally IPv6 makes for ~2% of traffic sixteen years after it was first proposed.

As does IPv6, but my mod is light years easier than those of IPv6 which is what you propose.

Not at all. That is the only solution you could think of, but there are smarter, simpler solutions. E.g. route all 255:255:255:8 packets to an extended field aware router down-stream (not unlike 255:255:255:255 are "routed" to the DHCP local server).

You couldn't come up with a solution in five seconds and declare the whole thing impossible, which goes back to my point, you are raising minor technical objections and treating them as major showstoppers.

He he, kiddo the software developed by my team routed more traffic in a second than all the torrents you've ever downloaded in your lifetime put together, which explains why what looks as an insurmountable problem to you is just another day at the office for me.

That you do not see how to do something doesn't mean other people with more experience can do it either.

Correct, which is why I did not propose an extension field, but rather a reserved value.

Sure, all you do is you define the behavior but do not require the devices to actually do anything about it. Only later do you require the behavior to take place.

Let me FTFY:

Seriously think about it. Every issue you have with extensible fields you would have with a new protocol, while by virtue of being fully backward compatible you would avoid some of the worst issues of "flag day" IPv6, which we haven't yet managed to roll out 16 years after first proposed.

I don't see any merit in your technical objections. Why would "everyone decide how best to change to protocol to use extended addresses"? What I'm suggesting is that the extension behavior should have been there from the get go,

Similarly rolliing at an extension is in now ay "about as hard as switching to IPv6". IPv6 was designed to be a flag day protocol. How is this about as hard as "extending in a minor way the current protocol without need for interruption?"

I can carry on, but all you are doing is pointing out minor technical issues which would have needed to be taken care of. Yup, so they would have. Still it would have been easier to use an existing protocol.

There is lesson to be learned here:

Every fix length field should have a reserved value for an extension. .

Back in the early days of the internet each header bit was precious, so it was important to have packet headers as small as possible. However even then we could easily have reserved say 255:255:255:8 as the extensible value of the IP address.

By the time they are needed, namely in present day, it is a rather trivial mod to make network gear which reads another 32 bits past the end of the standard TCP/IP headers to collect the extended IP address, and presto IPv4 address shortage is gone.

I actually hire people all the time and given the choice between someone slightly more talented but less hard working, and a hard worker but slightly less talented I'll take the hard worker every time.

For one, a lot of what we call "talent" is just repetition and experience which means that after a while the hard worker will seem more talented than the original wizz kid.

Without adjusting for inflation gas prices under Bush second term average $2.7165 and so far under Obama they averaged $3.1728.

First this is a minor difference, second you fail to explain where exactly the president gets to set gasoline prices, which are controlled by worldwide demand.

I see a pattern here. You reach a conclusion and facts be damned.