That's no moon!
Oh wait, yes it is.

-

He's an ex-KGB guy, I'm sure that kind of thing was part of their training.

Why does US care about Hezbollah?

A masterful troll, sir. Hats off.

Because reference types are not required to have a default constructor, yet on the other hand you need some sort of sentinel value to default-initialize things like array elements and class fields. This is a solvable problem, but it requires significant language redesign in other areas. For example, it would require a change to initialization rules such that it would never be possible to read an uninitialized reference-typed field of a class - so no circular class dependencies - and would require the dynamic type of object to change during construction, a la C++, to avoid calling overrides from base class constructors.

One of the perks of dating a geek is that we are now the only ones who are ever going to take you to the hottest restaurant in town.
Jocks need not apply.

-

There's an accepted protocol to tell those and other well-behaved bots not to do so in a /robots.txt file. I doubt that reservation bots obey /robots.txt.

The article actually named this incorrectly. A "functional interface" in Java 8 is an interface with a single method - basically, J8 equivalent of a delegate type in C#.

The default thingy is called a "default method", and there's no special term for interfaces having them. In effect, these make Java interfaces closer to traits (i.e. allow multiple inheritance of behavior).

The big catch here is that they're still using interfaces with the same old Java generic model based on type-erasure. This, in turn, means that generic functions applied to a stream of primitives do a lot of boxing. To avoid that, they provide special-cased implementations for int, double etc, which have the same exact implementation for a specific primitive types. If you look closely at the samples in the article, you'll see that they call a function named mapToDouble. Note how C# doesn't need anything like that, since its generic Select<TSource, TResult> mapping method can handle primitives just as efficiently as any reference type.

Also have a look at javadocs for the standard functional interfaces in Java 8. Note how many they needed just to cover int, long and double (and this still doesn't cover combinations like int+double).

Primitives are not objects in Java, unlike many other OO languages. So no, there are no objects created here.

Name a single C compiler that does that.

While you're at it, name a single CPU architecture that doesn't support basic unsigned arithmetic with wrap-around, as defined by C99 spec.

No, but Pokemon trainers dream of electric mice.

And even if you are a cop, you can still be little people.

If seeing the non-free film Blade Runner is a requirement of keeping a geek card valid, what method do you recommend to see this film without breaking the law, both inside and outside the United States? Redbox carries only new releases.

That makes no sense. How exactly is unsigned arithmetic not cross platform? It's the most basic arithmetic that any CPU can support!

If you mean that wrap-around isn't cross-platform, then it isn't for signed arithmetic, either. In fact signed is less portable because there are more possible binary representations of it compared to unsigned.

.NET by itself doesn't have any "unsafe directive". The IL has two opcodes for each arithmetic operator, one with overflow checking and one without - e.g. add.ovf and add. Their use is explicit in any particular instance.

Now C# has "checked" and "unchecked" blocks and expressions. The default is actually unchecked (so overflow wraps around), but if you wrap your expression with checked(), or it is (lexically) inside a checked{} block, then there is an exception on overflow. unchecked() works in reverse, disabling overflow checking if outer scope has it enabled. The default setting at global scope is unchecked, but that is a compiler switch that can be changed (which is probably a bad idea, as most C# programs are written assuming unchecked-by-default).

"unsafe" is something else entirely. It is, again, a C#-specific language feature that permits the use of raw pointers and some other language features that circumvent the runtime verification layer and GC.