Bring It On

Even though we've been in the era of many-core processors for quite some time, not many developers bother to change their habits and try to use all that power. In fact many work for years without a single multi-threaded/asynchronous line of code written. A colleague of my wife was startled recently when she realized that she was supposed to write some asynchronous code yet she's been a developer for 3+ years now.

Fortunately Silverlight 2 is going to change all that. Due to the fact that Silverlight's UI runs on a single thread (just like all of the UI code on Microsoft platforms) and that most if not all network code does take time it would be unacceptable if the Silverlight plug-in would just block thus blocking the UI of the host (Web browser like Firefox, IE or Safari). Therefore the API designers decided to only use asynchronous model for each and every network related call.

Have a look at the WebClient or WebHttpRequest class and note there is no way to synchronously download a web page or any other content. While this is for sure going to confuse all those who ignored the asynchronous pattern in the .NET it is also going to force them to finally face it and use it.

I think this is a good thing. The asynchronous pattern in the .NET is very well done and deserves to be used more not just in Silverlight but with desktop applications too. There's no excuse today for a developer to create any application with a periodically unresponsive UI.

IL code is platform agnostic. So as long as there’s a JIT compiler for your processor everything should work just fine. That’s why by default the compilation mode for a regular .NET project states “Any CPU”.

The image you get when compiling the application or a class library will always contain IL*, but you can force the platform compatibility with a special flag (that can even be turned on and off post-compile). Why would you ever do this?

Because if you’re using a mixed assembly which is partly IL and partly unmanaged native code (usually C++) then you are already tied to a platform.

This problem shows up mostly when you try to use native (or mixed) 32–bit class library from a pure .NET application.

Fortunately, the solution is easy – you don’t need to mark all of your assemblies as 32–bit (x86), just the main executable. Once that starts in x86 mode, all the other DLLs will load as x86 too.

Why worry about this? Because more and more people will be using 64–bit OS-es now that memory is dirt cheap (you can never have too much memory). Out of three computers I use on a daily basis, two are 64–bit (XP and Vista) and only one is 32–bit (XP). There is a good chance I’ll soon be replacing the remaining 32–bit laptop with a new one with a 64–bit Vista.

*Unless you ngen the image, that is.

In the last couple of years we witnessed a sharp rise of the popularity of both Ruby and its most famous project Ruby on Rails (RoR from now on). Developers flocked to “the other side” from many different languages and platforms: PHP, Java, C#… The most famous public switch in the .NET world was Mike Gunderloy’s – he had a great consulting job as a .NET consultant and a large following reading his “Daily Grind” (no link since the grind is now discontinued), but has now moved on to RoR exclusively.

Most of the other platforms have since adopted some of the features of the RoR. On the frameworks side we have Python with Django, Java with Grails (yes I know it’s actually based on Groovy), PHP with CakePHP and .NET with MonoRail. On the fundamentals side we have JRuby that allows Ruby and thus RoR to run on the JVM and the .NET will soon have IronRuby that should do the same for the CLR (or DLR to be more precise).

It would be naive to think that Microsoft’s developer division did not plan to launch a .NET based framework similar to RoR. Despite the success of the ASP.NET, as it is now ASP.NET is a lot more friendly to beginners and those demoing the technology. Experienced developers require more structure to the code (MVC pattern is one way to introduce structure), unit testing, less hand-holding and more control over the generated HTML.

Why didn’t Microsoft announce ASP.NET MVC (I hope the name will change) sooner?

My guess is that both the underlying platform (CLR) and the languages on top of it (most notably C# which is a “primary” language for the platform) could not compete with RoR/Ruby in coolness, brevity and elegance. But with the C# 3.0 and LINQ, we’re finally there.

Let’s look at the list of some of the things Ruby/RoR had that C#/ASP.NET didn’t have prior to the .NET Framework 3.5 and then dissect them all one by one:

1. ActiveRecord
2. blocks/lambdas
3. easy way to extend any class with a new method
4. hashtables everywhere, including simulated named arguments
5. easy getters/setters and anonymous types

1. ActiveRecord is the trickiest to get right. As much as I hate to delve again into the religious debate about the need for ORM tools, I have to mention that lightweight ORMs can be useful. ActiveRecord and LINQ are both such ORMs. They don’t try to be everything to everyone nor to resolve every Object Oriented/Relational mismatch there is. LINQ is a very good substitute for ActiveRecord. One feature of RoR is missing though and that is declarative database modeling and migrations. No database schema rests the same from the initial design and the decision to include the process of schema upgrades directly in the development process is a great decision for RoR.

2. Blocks in Ruby are undoubtedly cool and used all over the place. .NET has very similar concepts, even keywords overlap, but the meaning is not the same. Keyword yield in Ruby is different than yield return in C#, yet both are used in extremely similar contexts. Let’s look at Ruby example:

def useless
  puts 'Starting useless method.'
  yield
  puts 'Ending useless method'
end

useless { puts 'Outside useless' }
# prints "Outside useless" in-between "Starting..." and "Ending..."
a = [1, 2, 3]
a.collect { |elem| 2 * a}
# gives [2, 3, 6]

collect is method that will apply user-supplied block (read: anonymous method) to each element of an array and return a new array with the results. It does so by yielding every element of the array to your block, then appends the result into an array that it returns. So it looks like yield is great for iteration like scenarios – it is. But look at the first example (contrived, yes). Method prints some text, yields control (not giving any value and ignoring the return value) to your block, then prints more text.

The thing is, blocks are just anonymous methods. The nice thing with blocks in Ruby is that you don’t have to pass them to methods, yet any method is capable of receiving them. It’s as if any method in the C# would accept one extra invisible parameter, an anonymous method, with any number of parameters and any return value. Let’s rewrite the useless method in C# 3.0:

public class MustHaveClass {
  public static void Useless(Action block) {
    Console.WriteLine("Starting useless method");
    block();
    Console.WriteLine("Ending useless method");
  }
}

// call it with 
MustHaveClass.Useless( ()=> { Console.WriteLine("Outside useless"); });

It's more wordy, but the point is the same. Action is just a delegate with no parameters and no return value. We have to spell this out – both the number and type of parameters as well as type of the return value. If you expect a different kind of “block”, you’ll have to change the signature to the more appropriate delegate (look up Func in the Reflector). So the keyword yield in Ruby is actually equivalent to the delegate invocation in C#. Also note that I’m using lambda syntax for anonymous method here (new with the C# 3.0). I could have also used “old” style anonymous delegate from C# 2.0, but lambdas are more readable for larger number of parameters so I always use them by reflex.

Unlike Ruby, C# does not use blocks/anonymous methods for iteration. To make things more confusing for comparison, simplified iteration is achieved via yield return keyword. In any case, sending blocks to methods and using them is now really easy with the lambdas in C# and is not very ugly nor there is too much to type.

3. Easy way to extend classes has always been one of the primary features of Ruby. C# 3.0 gives you extension methods and though they are not as powerful as in Ruby, the essence is there. I already wrote about how to implement Rails-like extension methods and I wrote about surprising behavior you can achieve with the extension methods. Thus I won’t go into detail any more.

4. Hashtables are everywhere in Ruby and in RoR. They are particularly useful for dynamic parameter passing. Up until C# 3.0, there was no easy way to create a hashtable (or dictionary for strongly typed situations), but no more. Here’s how to create dictionary on the fly:

 new Dictionary<string, int>() { { "one", 1}, { "two", 2 } };

A bit wordy at the beginning, but simple enough for the body of the initializer. There is a syntactically simpler alternative (at the cost of using reflection) demonstrated in the next point.

5. Anonymous types and trivial getters/setters enable many scenarios that used to be either too “wordy” or just impossible. The reason LINQ’s syntax is so simple has in part to do with anonymous types. Example:

from c in Customers
where c.Name == "SomeName"
select new { FullName = c.FirstName + c.LastName };

Instead of returning back a type of Customer I am returning unnamed type because I'm only interested in its property called FullName. The scenario is partially enabled by a trivial way to get a property with no code for getters/setters.

Ruby has attr_accessor decorator method that generates getter and setter methods. C# 3.0 allows you to just say get; set; in the declaration of a class and you’re done.

Instead of dictionary as a primary means for dynamic parameter passing, you could also use anonymous types. Keep in mind that on the receiving side, you’ll have to use reflection to figure out what you received (but it’s not hard). Example from above would look like this:

new { One = 1, Two = 2} 

A lot simpler, no?

 

Let’s not get carried away here: language features are cool, but ultimately it matters more if the framework is well written or not. Based on what I’ve seen, ASP.NET MVC is well designed – we’ll talk about how well written it is once at least beta code becomes available. It looks like most of the good things from RoR have been faithfully duplicated so I have high hopes

In a blog post I wrote a few months ago I thanked Microsoft for giving us free Express versions of the Visual Studio. A reader rightfully complained that I should probably thank the Open Source community first – without the pressure from Eclipse and other IDEs, it’s questionable whether Microsoft would ever consider giving away Visual Studio Express.

Along same lines then – thanks to the Ruby community and thanks to David who started the Ruby on Rails. Thanks to you the .NET developers will get a cool MVC Web framework.

It’s been more than a year since Powershell 1.0 is out. The way Powershell is marketed you’d guess that the only people using it are hard-core administrators who need to automate a lot of work across many machines.

Far from it, Powershell is useful to any serious developer and maybe even enthusiast user. Yes, it does administrative tasks well, but it’s also useful for automation of many other tasks too.

I’ve seen two scenarios lately where Powershell shines: builds (as in software builds) and throw-away helper projects.

I will discuss the current state of a couple of build systems in more detail in a another post, but I will say here that both NAnt and MSBuild are not the greatest possible tools for the problem. You need to face a bit more than a simple console or Windows Forms project to really see why complex build rules end up unreadable or quirky in either of just mentioned systems. I attribute this to the basic design flaw of both: NAnt and MSBuild are highly declarative XML files that are “interpreted” by an engine. In comparison, both rake (Ruby based) and Powershell are full fledged languages.

Thus expressing intent, especially complex rules, is a lot easier in Powershell than in MSBuild for example. You don’t have to fit into MSBuild limited set of tasks nor to build an extension task (this is a primary way to extend MSBuild) in C#, compile, deploy and reference the assembly with the extension in the MSBuild build file.

Example: what follows is a Powershell script that transforms XML using XSLT.

param ([string]$inputXmlFilePath = $(read-host "Please specify the input XML file"),
       [string]$xslFilePath = $(read-host "Please specify the XSLT file"),
       [string]$outputXmlFilePath = $(read-host "Please specify the output XML file"),
       [string]$xparam
)

$xslFilePath = resolve-path $xslFilePath 
$inputXmlFilePath = resolve-path $inputXmlFilePath 
$outputXmlFilePath = join-path (split-path $inputXmlFilePath) $outputXmlFilePath 

$xslt = New-Object System.Xml.Xsl.XslCompiledTransform
$xslt.Load($xslFilePath, [System.Xml.Xsl.XsltSettings]::TrustedXslt, (New-Object System.Xml.XmlUrlResolver))

if($xparam) {
  $argList = New-Object System.Xml.Xsl.XsltArgumentList
  $argList.AddParam("xparam", "", $xparam)
  $outStream = New-Object System.IO.FileStream $outputXmlFilePath, Create, Write
  $xslt.Transform($inputXmlFilePath, $argList, $outStream)
  $outStream.Close()
}
else {
  $xslt.Transform($inputXmlFilePath, $outputXmlFilePath)
}

It's a bit limited in the sense that it doesn't pass more than one extra parameter to the XSLT, but this can easily be remedied. Since Powershell can use any .NET class, it was trivial to build this.

Another scenario where I found Powershell useful is for small throw-away helper projects. Instead of cluttering your solution with these projects, you need one file in one of the projects and you’re done. The concrete example: I built a simple TCP/IP server that would listen on a port and when a client connects would serve a content of a text file “replaying” one of the real server/client sessions from before. Simple, effective, works.

Finally, if you haven’t, do yourself a favor and download PowerGUI. Personally, I don’t use the main GUI at all, just the script editor. But the editor works really well, is simple and has a killer feature – Powershell debugging. Happy scripting!

I ran into a great question on the Business of Software forum the other day. I give it to you in its entirety:

I want to make a rich web application. Ajax is out of question (too many horror stories). I want to choose 1 platform and stick with it. Requirements are:

1. Widespread install base (I guess Silverlight's already out!)
2. RAD. Need to write an app from inception fast.
3. Has a lot of third-party/free code available on the net.

BTW I'm a C++ Win32 developer, and I would definitely prefer Silverlight *if* it had a higher install base.

I'M ESPECIALLY LOOKING FOR INSIGHTS ON PEOPLE WHO HAVE FIRST HAND EXPERIENCE IMPLEMENTING ONE OR MORE OF THE AFOREMENTIONED TECHNOLOGIES. Yea, I just yelled.

This is a great question for several reasons: the poster tells you why one of the technologies (AJAX) is not on the list (even if you disagree with the reason). He tells you about the criteria for choosing the platform. He gives you his background. Finally, he preempts any “evangelist” comments – do give advice if you’ve used one or more of the technologies above.

Unfortunately, the poster is in a “cheap, fast, good: pick two” situation. None of the technologies listed will satisfy all or even most of his requirements.

I was a C++ Win32 developer, just like him. I have used Java (for applets) and WPF (a bit of Silverlight). I only know what I’ve read about Flash. Here are my 2 euro cents…

Silverlight in its deployed version 1.0 (no CLR) is, for his needs, useless, regardless of the adoption. What he would most likely want is Silverlight 2.0 (CLR included), but that’s months away and then there’s the question of adoption and tools. Personally, I don’t think adoption is what he should be worried about, but that’s another story. Tools (RAD) should be fine for him as most will be integrated in Visual Studio where he should feel right at home. Third-party code will be scarce.

Flash has a great install base (anecdotally, around 90%). Tools appear to be very RAD. I don’t think there’s much third-party/free code available on the net as Flash is not so much about code. Mainly, as far as I can tell, the problem with Flash is the host language. It’s some kind of JavaScript mutant called ActionScript. It appears to be faster than JavaScript in the latest incarnation of Flash, but it’s still a script language. Him being an ex-C++ developer, I don’t see him using a script language and being productive with it. But that really is the only problem with the Flash.

Java has a widespread install base, but you never know which version users have installed. I’ve seen point releases of Java breaking applications and that is to me one of the biggest problems with Java. RAD is questionable (depends on your definition of RAD), but on the other hand if the applet is graphics intensive, he’ll be able to trivially transfer all the GDI/GDI+ knowledge accumulated over the years. There is a lot of third-party and even more free code on the net, so much that it might be a problem to pick which library to use, not to find if there’s one to suit his needs.

All in all, it’s tough for Win32 desktop developers trying to build RIA. Java feels great as a language (if you have C++ experience), but there are deployment issues and RAD aspect. Silverlight looks even better, but it’s not ready. Flash uses awkward script language. Let’s not forget that unlike Java which still uses rather traditional GUI concepts, both Flash and Silverlight are fully vector-enabled and use substantially different GUI concepts and this takes time getting used to.

My recommendation? If possible, wait for Silverlight. If not, go with Java.

Lambda expressions available in the new C# 3.0 compiler are mostly used in the context of LINQ queries, like this:

internal class Product {
  internal int ID { get; set; }
}

var products = new List<Product>();
products.Add(new Product() { ID = 1 });
products.Add(new Product() { ID = 5 });
// continue to fill in products
var one1 = from p in products
           where p.ID == 1
           select p;

It’s not obvious, but the above query is equivalent to (also note that one1’s type is IEnumerable<Product>, not Product):

var one2 = products.Where(p => p.ID == 1);

The part p => p.ID == 1 is the lambda expression and in this case (lambdas are more general than a simple delegate substitute) can be substituted by a C# 2.0 feature called anonymous delegate:

var one3 = products.Where(delegate(Product p) { return p.ID == 1; });

One advantage of lambdas is already obvious: we didn't have to specify the type of the parameter of the delegate, plus there was no need to type return. To a certain extent, this is actually a feature of the new compiler (better type inference), but it does not work in all cases (it can’t), so sometimes (not here, but works nevertheless) you must qualify the parameter with a type, like this:

var one4 = products.Where((Product p) => p.ID == 1);

It is relatively easy to conclude from this that the syntax for lambdas with no parameters is likely:

() => /* some criteria, note that parenthesis are required */

This is probably obvious to many developers (especially those using the help files and not deducing things like this), but the reason I mention it here is I've seen many LINQ articles that use anonymous delegates as if the author did not know that lambdas can have no parameters too. For completion, here's how a syntax of an anonymous delegate with no parameters looks like:

delegate { /* statements */ }

The age of multi-core processors is here. It’s not because we’ve just started getting multi-core processors but because most consumers today will get one without even knowing it. Just like most users today will possess 64–bit processors but because their OS is 32–bit they won’t know it, nor care.

We developers have to care if the multi-core is becoming mainstream because that is the only cheap way to scale. If your code is CPU bound you should try your best to distribute the work over as many cores as the machine has. This is not easy to solve right and a lot of work will be in the libraries anyway so why not create something all of us can use?

Microsoft is working on exactly this. The December CTP of Parallel Extensions is here and it’s looking really good. It’s just a library that you add to your project and all of the sudden there are several ways in which you can trivially parallelize your code.

The emphasis is on trivially – most experienced developers could do the same (or close) kind of work if given enough time but why invent hot water? Parallelism is here to stay, having a library in the .NET Framework is the way to go.

But all this theorizing will not convince you so I’ll give you a concrete example. Let’s say you have a server with lots of data (doesn’t matter which). This data is served to clients over a slow network, thus you’d like to transmit as little as possible. You decide that you should compute a hash of data so that when clients connect to you and send you the hash, if it matches, you won’t send them anything because the data is the same.

Computing a hash is not cheap though. In fact, let’s have a look at how fast it is on a modern 64–bit Core2 Duo running at 2.8GHz with plenty of DDR2 RAM running at 800MHz. The benchmark (whose source will follow shortly) hashes the data in the memory:

Generating 512 MB of random data...
....done.
Calculating hashes sequentually
MD5 hashes 371,82 MB/sec
MD5 hashes 379,82 MB/sec
SHA1 hashes 341,56 MB/sec
SHA256 hashes 68,31 MB/sec
SHA384 hashes 104,79 MB/sec
SHA512 hashes 105,11 MB/sec

The fastest one (MD5) crunches about 380MB/s. Since the memory throughput (theoretical) is about 6400MB/s, this code is CPU bound; if we had a faster processor we’d be able to hash more data. Using a simpler hash algorithm would also help, but let’s assume you only want to use what’s already available in the .NET BCL and you don’t care if the hash is cryptographically secure.

Let’s first take a look at the code:

using System;
using System.Diagnostics;
using System.Security.Cryptography;
using System.Threading;

namespace HashSpeedTest {
 class Program {
  private const int MB = 1024 * 1024;
  private static int _sampleSize;
  private static bool _parallelExecution;
  private static readonly Stopwatch _stopWatch = new Stopwatch();
  static void Main(string[] args) {
   if (args.Length < 2 || !int.TryParse(args[0], out _sampleSize)
    || (args[1] != "par" && args[1] != "seq")) {
    Console.WriteLine("Usage: HashSpeedTest <data_size> <style>");
    Console.WriteLine("<data_size>: size of test data in megabytes (32, 64 or more)");
    Console.WriteLine("<style>: 'par' for parallel and 'seq' for sequential execution (no quotes)");
    return;
   }
   _sampleSize *= MB;
   _parallelExecution = args[1] == "par";
   byte[] data = new byte[_sampleSize];
   Console.WriteLine("Generating {0} MB of random data...", _sampleSize / MB);
   new RNGCryptoServiceProvider().GetBytes(data);
   Console.WriteLine("...done.");
   Console.WriteLine("Calculating hashes {0}", _parallelExecution ? "in parallel" : "sequentually");
   string[] algorithms = new string[] { "MD5", "MD5", "SHA1", "SHA256", "SHA384", "SHA512" };
   foreach (var algo in algorithms) {
    Measure(data, algo);
   }
  }
  private static void Measure(byte[] data, string algo) {
   _stopWatch.Reset();
   int iterations = _sampleSize / MB;
   _stopWatch.Start();
   if (_parallelExecution) {
    Parallel.For(0, iterations, i => {
     var hash = HashAlgorithm.Create(algo);
     byte[] result = hash.ComputeHash(data, i * MB, MB);
    });
   }
   else {
    var hash = HashAlgorithm.Create(algo);
    for (int i = 0; i < iterations; ++i) {
     byte[] result = hash.ComputeHash(data, i * MB, MB);
    }
   }
   _stopWatch.Stop();
   double speed = 1000.0 / (_stopWatch.ElapsedMilliseconds / (double)iterations);
   Console.WriteLine("{0} hashes {1:f2} MB/sec", algo, speed);
  }
 }
}

The main work is done in the Measure method. We use StopWatch class to measure passed time, then hash 1MB of data several times and then calculate the speed of hashing in MB/s. The Main method just prepares the list of names of hash routines, parses parameters, displays usage etc.

Now look at the if(_parallelExecution) branch – it’s almost identical to the non-parallel version. The only difference is usage of Parallel.For instead of keyword for and the fact that we create hasher object for each hash computation – since some of the calculations will be done in parallel, we don’t want to worry about the shared state of the hash algorithm.

What do we gain? Let’s see the results of the parallel run:

Generating 512 MB of random data...
....done.
Calculating hashes in parallel
MD5 hashes 660,65 MB/sec
MD5 hashes 719,10 MB/sec
SHA1 hashes 650,57 MB/sec
SHA256 hashes 132,47 MB/sec
SHA384 hashes 203,26 MB/sec
SHA512 hashes 203,42 MB/sec

Just as expected, we get about 190% of single core performance when we use both cores (excellent result)! Even better is that we almost didn’t have to do anything. But the real gain is this: put this code on a 4–core machine and it will be almost twice as fast – we get scalability for free. As you add cores, they get used. Note: you might have noticed that MD5 is calculated twice in the example: that’s because there seems to be a small performance penalty as the Parallel Extensions library is initializing, just discard the first result and look at the second.

This isn’t the silver bullet of the multi-threaded programming though as it mostly solves CPU bound problems. If you are I/O bound you’ll need a different set of techniques. But this is a great step in the right direction and it’s still just a library. Go get it and try it out yourself.

Quite often I want to quickly try something out – make a class or two, just a couple of simple methods that exercise certain kind of functionality I am trying to produce.

Running this code in the context of a real solution which consists of dozens of projects only muds the waters. It gets hard to separate and execute just the portions of the code you’re writing and may even throw away.

For cases like this I used to use Snippet Compiler – a simple yet powerful editor and mini-IDE for C#, VB.NET and even JScript.NET. It is convenient because it does not generate project files and other residual files, starts and runs quickly and even reroutes console output to its own output panel. Just perfect for small try-out tests.

Snippet Compiler today is quite dated though and has not been actively developed. But yesterday my good friend and développeur extraordinaire Dejan “sold” me on another excellent alternative – Visual C# Express. Version 2008 just came out and this time you can download a single ISO image of a DVD with all of the Express versions in one convenient package.

It’s great. Works almost exactly the same as its more feature rich cousin editions (Standard and Professional) but starts quickly and just like Snippet Compiler does not leave trail on a disk (see screenshot to the right). You get intellisense, all of the designers, build system… everything is there, except for one thing: multi-targeting (you can only use .NET 3.5). Still, for small test projects this is not an issue at all.

Visual C# 2008 Express, just like all the other Express editions is completely free, no registration is required and it doesn’t expire.

Thanks, Microsoft.

Considering how much functionality is in the .NET Framework and how .NET PE files’ metadata is highly compressed, one would expect most .NET applications to be very small.

You can empirically observe this by trying to create a simple “Hello World” in C#: the resulting executable is just 3.5KB (or even smaller with versions prior to 2.0). The size does not increase by much as you continue adding code and reasonably sized (in functionality) .NET applications are just a couple of hundred KB or even less.

Just the other day I checked to see how big the core part of my P2P BitTorrent app was – 160KB. Hm, this doesn’t look right; I keep this library lean in general, it should be smaller.

So I fired up ILDASM (IL DisAsseMbler) and checked the overall statistics (View->Statistics). Here’s the important part:

 File size            : 163840
 PE header size       : 4096 (496 used)   ( 2.50%)
 PE additional info   : 1219              ( 0.74%)
 Num.of PE sections   : 3
 CLR header size      : 72                ( 0.04%)
 CLR meta-data size   : 81268             (49.60%)
 CLR additional info  : 0                 ( 0.00%)
 CLR method headers   : 11081             ( 6.76%)
 Managed code         : 54814             (33.46%)
 Data                 : 8192              ( 5.00%)
 Unaccounted          : 3098              ( 1.89%)

Well, well, well… 50% of the image is actually metadata! Despite heavy metadata “compression” (this is a custom kind of compression) in the .NET Framework, metadata occupies half of the total space, while code takes only 34%. Interesting…

I guess if I obfuscate the image using an IL round-tripping obfuscator that I could get quite a smaller image.

At least in Microsoft world, the MVC pattern is back in fashion. Note that I say back and not finally. Bashing Microsoft is popular and many I’m sure believe that the move towards the MVC is just trend following, but it’s not entirely.

If you did any serious programming during nineties in C++ on Windows, you have most likely used MFC. From the very beginning MFC had MVC pattern, albeit a bit weird (it wasn’t clear is the Frame was supposed to be a controller or not). This presents a bit of a challenge for the newcomers as it’s yet another conceptual thing they have to struggle with but pays off in the long run because even rookies write relatively sane structured code from the beginning.

MVC is suspiciously absent from all three major versions of the .NET Framework and I can’t really say why. Without this foundation, most .NET apps end up a mess, or just a group of Forms with scattered business logic, DAL and view mashed up together. There is no excuse for this and I’m really disappointed in this decision.

Good for us though, thanks to the popularity of other frameworks/libraries that do use MVC or simply because MVC proponents in Microsoft finally had their voice heard (or both, or something else entirely) we’ll be (relatively) soon getting MVC for desktop and web development on the .NET platform!

Project Acropolis is bringing MVC into the desktop world (WPF oriented, but supposedly can be bolted on the Winforms as well). Just a couple of days ago Scott Guthrie demonstrated the ASP.NET MVC  framework in a surprisingly low-key way during the ALT.NET conference (video of crapish quality but watchable is available here, thanks to Scott Hanselman).

The web framework is quite a bit like Ruby on Rails, but that’s to be expected as RoR is well thought out framework. Thanks to the DLR the new ASP.NET MVC framework will most likely be immediately usable from Python and Ruby too. Great times.