Hmm I think the article is somewhat biased though

> the folks that are coalescing around the concept of ALT.NET are the leading minds in your professional peer group

Loudest and most opinionated quite possibly, but there's far too much of a cargo cult around things like ORM, TDD, Agile, etc. in the ALT.NET space to describe them as the leading minds.

Main problem with this article is summed up in the extract below:

"In this type, I kept the integral value storage, but opted to represent the fraction as a completely separate Int32, which is scaled by 10^9 (the largest power of 10 which fits into an Int32). [...] Another alternative was to represent the money value with a System.Decimal. The problem with this approach is that System.Decimal is a binary floating-point type, and binary floating-point types give us all sorts of headaches when computing with them and not treating the round-off or computational error accumulation with extreme care."

Um... except System.Decimal *isn't* a floating-point type, it's a scaled integer; from MSDN:

"The binary representation of a Decimal value consists of a 1-bit sign, a 96-bit integer number, and a scaling factor used to divide the 96-bit integer and specify what portion of it is a decimal fraction. The scaling factor is implicitly the number 10, raised to an exponent ranging from 0 to 28."

Saying "experts in entity-based applications" is like saying "experts in doing things fundamentally wrong". Any ORM framework is inappropriate for complex projects, not just EF. It will be absolutely fine for the audience ORM is aimed at, i.e. former Access developers. Vote of no confidence? Sure, for any complex project. But no more than any other ORM.

It's not actually thread-safe though:

if (dictionary.ContainsKey(someKey))
{
var value = dictionary[someKey]; // could throw as the key has been removed by another thread after the check
}

This is why the SyncRoot property was removed from the collections in the first place, because it was synchronising at too low a level. A thread-safe version would not have either of those APIs, and would instead implement something like

bool dictionary.TryGetValue(out TValue value);

Actually the C# ternary operator isn't equivalent to IIF in VB, because the IIF function always evaluates both the true and false actions, whereas the ?: operator is a lazily evaluated left-associative operator which only associates the appropriate action. e.g. IIf(a IsNot Nothing, a.ToLower(), String.Empty) will throw a NullReferenceException in VB if a is null because it will try to evaluate a.ToLower() anyway, whereas a != null ? a.ToLower() : string.Empty will not throw in C#. The C# ternary operator didn't have an equivalent in VB until VB9, where you can now write the rather confusing If(a IsNot Nothing, a.ToLower(), String.Empty).

You might also want to check out Jeffrey Richter's SpinWaitLock which is a more complete implementation of the same concept (with the required things such as Begin/EndCriticalRegion calls): http://msdn.microsoft.com/en-us/magazine/cc163726.aspx

Well really the best way to do it is with both regex and Luhn validation. Also, the fastest way to add up digits in a number is to use modulus-9, not to convert to a string then walking the chars converting them as you go...