Perhaps there as well. But folks around the .NET community need to come to this understanding, which is why I posted here.

Moreover, Spec#-like contracts would open the door for more concurrency, as concurrency's main blocker is side-effects. If the compiler could tell you about side effects thanks to contracts within the framework, it would remove a huge number of concurrency defects as well.

Duck typing? Safe null dereferencing?

Come on guys. Those are nice things, but not critical by any means. I'd much, much rather see something that would help us write less-buggy code, such as design-by-contract attributes with compiler enforcement, ala Spec#.

[Pure]
string GetFoo(string baz, int bar)
requires baz != null && baz.Length > 0
requires bar > 0
ensures return != null;
{
...
}

This would eliminate a wide range of programming defects. How much greater importance is that than niceties like duck typing and null dereferencing!

This is crap. We're talking about a difference of 30 some milliseconds over a million+ iterations! In realistic terms, this is nothing.

Developers: raise a red flag when you see someone say "over x times faster/slower!" You've got to look at the actual numbers before doing anything with this information. If you execute your Sum method just once, you're not even going to be able to measure the distance.

The article focuses on performance aspects. This is bad because performance of casting is a micro-optimization on the greatest scale.

The two primary concerns should be behavior and readability:

Behavior: casting will throw if the type is not convertible, the 'as' operator will simply return null if the type isn't convertible.

Readability: the 'as' operator reads cleaner than a cast in parens.

MS also sent some "gifts" to the Netscape team before they overthrew the browser.

As expected, it is merely a wrapper over MSHTML, the IE rendering engine. Because of this, it's not a true WPF control; it's got an HWND like normal WinForm/Win32 controls.

Anyone brave enough to write a WPF-based web browser?

Don't kick this! I need to win the MSDN subscription. Seriously, get back ;)

@spoulson "perfect for shrinking [my] tiny little bits" lol

@offwhite, actually, since you're introducing a new Function delegate here, you're actually allocating a new object. This will result in more IL instructions, more memory usage. (Unless of course the JITer or compiler can optimize it away.)

@Tr3v, I think the comment was kind of tongue-in-cheek. FWIW, I found the code still quite readable.

Heh, that's very cool in a geeky way.

FWIW, the recently released Microsoft StyleCop tool reports violations if you fail to use the 'this' keyword in front of member accesses.

Cool.

But I can hear MS management saying, "Great, you've made our competitor's spreadsheet application 50% faster. Thanks."

Tagged appropriately -- too many folks throw business logic, data access, etc. into their views. This encourages what is generally an all-too-common bad idea.

Unfortunately, his technique only works from the MSBuild command line. This doesn't work in Visual Studio 2005 or 2008. Scott hints in the comments that this will be built into the next Visual Studio.

Heheh, I think people are confused by the dual identities of the this guy.

He's blogging so much and getting so much work done with Rhino mocks and Boo and SvnBridge and book writing, I sometimes wonder if there are 2 of them. :)