As far as I know, the ECMA spec really is for .Net 2.0 and wasn't updated since.

And I think you can rely on features from C# 4.0 and .Net 4.0 in mono now, there aren't many missing pieces anymore.

I must admit that I don't use Java, so I wasn't aware that you can refer to final local variables from anonymous classes.

But yeah, verbosity is a big deal. If LINQ used anonymous classes instead of lambdas, it would be almost unusable (and unreadable). A lambda that can be written in about a dozen characters in C# requires five lines when written as a Java anonymous class.

C# 2.0 had anonymous methods, which were already less verbose than anonymous classes. Then C# 3.0 introduced lambdas, with the main difference being that they are even less verbose (big part of that is thanks to type inference, which means you don't have to specify the types of the parameters of the lambda).

And I think the fact that you can use only final variables is quite limiting too.

I don't know about you, but at this point, I consider a general-purpose language without closures to be a joke. In my experience, they are very useful and I would find it hard to work on a large project without them.

Even C++ has closures now.

You could do that on a Unix system, but that doesn't cover everything. On the other hand, you can be sure that wherever you have C#, you also have the .Net library.

Technically, the .Net libraries are not part of the C# specification, but practically, all implementations that I know of include them.

Unfortunately, the latest ECMA specification corresponds to C# 2.0 (which is from 2005). Mono already implements the upcoming C# 5.0. And the same applies to the CLI spec.

Actually, no, they can't. At least not as well as human mathematicians can. Have you ever seen a proof by a computer? It doesn't actually manipulate symbols, it just enumerates all the possibilities.

Computers are good at computing. You could say that that's a subset of "manipulating symbols", but it's a very small subset.

No. No and no. Nope; well, yeah, but that was for fun, not out of some superstition.

Are you really implying that Microsoft makes "a product that people want and can use"? Are you sure you're at the right place?

Are you really suggesting a switch to remove Joker? How dare you!?

If you personally consider it a good journalism, maybe it's time to reward it by buying the subscription?

For simple, local things like this, you can avoid pointers. But most of the time, you need to pass things around, which means using pointers (possibly behind a thin veil of shared_ptr or similar). And you need to think about the pointers, which doesn't happen in languages with garbage collector.

Yes, deleted articles are really deleted and even links to a certain revision of that article won't work anymore.

I think that merged articles usually don't have their histories merged, so that should be fine.

And renaming doesn't affect this, the history link uses a revision id, which won't change even after a rename.

The assumption is that the method that would run with bad arguments could corrupt the data. But if you always check the arguments, you never corrupt any data. Of course, nothing is perfect and data corruption bugs may still occur.

And when I said “crashes”, I actually meant that it throws an exception. You should not catch that exception (that would be just hiding the problem), but finally blocks will execute, so it kind of is graceful failure, or at least it can be.

Okay, so what if I pass length of that array to some function? Wouldn't that break the range checking?

It seems to me you're describing is Design by contract. Specifically, Code Contracts in .Net allow you to do this. The compiler there tries to check as much as it can, but checking every situation is simply not possible. It also produces runtime checks, so that your application crashes immediately when the contract is broken, instead of corrupting data.