It will do what you want in version 4.0...

time to read 5 min | 872 words

But still start using it now. Another reply to Adi, this time a new post in which he clarifies what he meant before. The main idea is that Microsoft's products get a big mindshare regardless of their relative qualities. I do not doubt that this is true, a lot of people goes for Microsoft because it is Microsoft. Expecting that this will pay off in the future is still the wrong thing to do.

I am one of those that would move to a new technology just because it gives me a tiny bit more, if it preserves everything that I can do in my current technologies. I am now using MsBuild in favor of Nant, because I can get the build script and the VS project to match (and yes, I know I can call msbuild from Nant). I moved to NUnit from MbUnit and back again, for much the same reasons.

But if it doesn't improve, why bother?  Adi brings up a couple of examples:

Team system is relatively new, but I bet in while more people will be doing unit tests using it, and not NUnit, even if NUnit is better.

I will refuse to use MS Test until:

  • It has a performance on par with NUnit/MbUnit - currently aroudn 30% slower, clock time.
  • It support the very basic of test patterns, Abstract Test Class.
  • It can be run as part of the build without jumping through hops.

There are people that would use MS Test instead of using NUnit, I am sure, although you don't here about it almost at all. They make compromises because they are using Microsoft, compromises that I am not willing to make.

Once Linq is out, I think the same would be true regarding NHibernate.

Linq is an extention to the language, not a technology. Assuming that Adi is talking about one of the ORM technologies from Microsoft, I do not think that I can argue that this is the case, only that I do not think that this is something that is done with planning and foresight. Just to point out, no one answered to my Linq challange yet, and I have no idea if this is even possible.

I wrote about the wonder MS did releasing C# and conquering a big chunk of the market, and Oren reply was "Just to point out, another company did, Sun & Java". But Sun introduces something new to the world with Java, while that was not the case with C#.

I started doing C# when I was mostly building Windows applications. The only good story at the time was VB or C++. If you wanted to use Java you could, if you really liked laying stuff out in code, and then running it to see what you wanted. Java was never very strong on the client. C# came to replace a market that was dying for a replacement, which is why it caught such a big audiance in such a short time. If Sun had its act together in 95-00, it could have made Java the prevasive technology everywhere.

That leads me to the strategy part - MS related technology is a good bet because you can be sure most of the market will use it.

I would really love to compete on a technology level with someone that is buying completely into this approach. I can do better than most of the market by using the best tools for the job. Limiting myself to Microsoft tools is limiting myself to the level that Microsoft believes most programmers should be.

I once had to resort to runtime code generation in order to sort a grid view. It is complex, yes, but it meant that I had sorting working for all the grids in the application, for the cost of half a day, while the upstream team wrote custom code per grid per page, because that is how they were told it should work.

Going with MS related technology blindly is not a good thing at all. It is not a strategy, it is herd thinking. It is the old argument about: "No one was fired for choosing Microsoft".