Bring It On

It is no secret that the parallel programming is the Next Big Thing^TM. The processor speeds are mainly constant and the only thing that increases is the number of cores. For the general parallel programming, at least for the data parallelism, there are already several initiatives that should help programmers escape the world of manual thread creating and locking.

But most of these technologies only count on the presence of the CPU with certain relatively low (<16) number of cores. But what if you had hundreds of cores at your disposal?

The GPU (chip that powers your graphic card) is one example of a highly paralellizable processing unit albeit it's parallel "cores" are not nearly the same kind of cores as we have on the CPU. Consequently the development model for the GPU is significantly different and additionally burdened by its historical graphics-only usage. You really can't easily develop applications or routines using graphical APIs like OpenGL or DirectX - they are simply not meant for anything else but graphics development.

Yet the computing power of  GPUs is enormous. One PS3 can provide many times the performance of a very powerful modern CPU for the Folding@home project. The possibilities for financial and scientific use are enormous.

But to get this kind of performance you'd have to use the API appropriate for the target chip. If you have NVIDIA hardware, you're forced to use CUDA. For ATI/AMD, you'd use stream computing APIs.

But no more. In a record 6 months, the Khronos group has published the specification for OpenCL 1.0, the common API for general purpose GPU computing on all platforms that implement the support for the API. Both NVIDIA and ATI are in as is Apple which plans to make OpenCL a big part of the next OSX release.

Even better news is that OpenCL supports CPUs as target so as soon as the support is available from any of the vendors we can start playing with the technology - once the algorithm works on the CPU you can try to execute it on a GPU. Most of the vendors pledged support in the first or second quarter of 2009.

Exciting times, indeed.

Yeah, just like that. Since 2004 I've been using Orange SPV E200, which is actually produced by HTC and known by the name HTC Voyager. It was my first smartphone that worked reasonably well and the one that ran .NET micro framework under Windows Mobile 2003.

I've been thinking about the upgrade for quite some time now but the prices of the new models have been everything but affordable, so I waited. Some of the newer Windows Mobile phones looked really nice and me being a Windows .NET developer that would be the most logical choice.

Then I realized that I don't actually have to buy a Windows based phone ;) and that maybe I should consider iPhone as well. This coincided well with the launch of iPhone 3G that fixed several issues I had with the original iPhone: the price isn't insanely expensive any more, the phone is reasonably capable for the modern phone (read: has 3G) and the thing that decided for me: I could keep my old subscription (and not pay 49€ for "unlimited" Internet which is actually limited to HTTP, POP and 500MB per month)! I don't think many providers in Europe offer this but Orange here in France does.

In the end, the phone cost me exactly the same as would a brand new HTC Diamond - 179€. Considering how all of the reviews of HTC Diamond noted the sluggishness of the UI where the iPhone's UI is really fluid, it was no contest in the end.

Besides, I am a bit curious about the Mac platform itself and will most likely soon buy a MacBook (as soon as new models come out, supposedly very soon). Make no mistake, I still stay first and foremost a Windows developer (thus the MacBook will be dual-boot with Vista x64), but I simply want to see what all the hype is about.

For now, I am really pleased with the iPhone 3G, but keep in mind: it's just a phone. I really don't understand people who stood in lines for days to get ahold of one. I had to wait a week or so until the phone was on stock (it sold out within 2 hours of availability), ordered it online and got it two days later, no fuss.

One final and important note: through iTunes (a bit weird), I was able to move everything important from the Outlook 2003 into iPhone: contacts, emails and tasks. It just worked.

More detailed review of iPhone will follow once I get to use the phone a bit and get to know its dark side too.

Just in case you're not aware of it, there's a great TV show called Battlestar Galactica. It's a remake recreation of the original show from the seventies, but much darker and more realistic. Despite the sci-fi setting, don't let that fool you - the show treats many timeless human issues like meaning of life, love, religion, betrayal...

I won't go into detailed analysis of why this show is so good but one thing is obvious: without the most excellent soundtrack that keeps getting better season after season the show wouldn't be half as good. The music is original with lots of unusual instruments and expresses emotion in a way previously unheard of for a TV series.

The last season's final episode was a shiny example of that: perfect synergy of picture and sound, great timing and excellent execution.

Now, just a couple of episodes later there's another genius example of the use of music and lyrics to enhance the viewing pleasure. In the episode 7 of the season 4 (warning: spoilers ahead! If you haven't watched the episode, don't read further) called Guess What's Coming to Dinner we all witness great vocal capabilities of the actor Alessandro Juliani (aka Felix Gaeta).

While recovering from the leg amputation Gaeta sings to reduce stress and cope with pain. The lyrics are original and so is the music, but the way the song is delivered will send chills down your spine. The song is appropriately named Gaeta's Lament and both the lyrics and music sheet are available.

Even better, a thorough analysis of how the song came to be and how it improves the narrative, especially at the end when the hybrid is awaken (awesome scene!) can be found at the Bear McCreary's blog. I highly recommend you to go through it. Considering how much thought and love when into making an episode like this no wonder it turned out as good as it did.

Relation between developer's quality and compensation is a hot topic. Lots of e-ink has been spilled over this issue but not much crystallized in the end. Unlike lawyers who have established a baseline price of their work, developer's pay fluctuates wildly and is not necessarily related to the quality of their work (in fact, more often it boils down to how good negotiator you are). Quite often you'll see developers (who recently started contracting) asking for help on how to price their work on a public forum. Clearly we need some kind metric to measure developer's productivity, but even more we need to understand the quality of the work, more than the quantity.

Martin Fowler's Cheaper Talent Hypothesis is a great read that covers many important points. The relevant piece that talks about quality says:

Faster cycle time leads to a better external product, but perhaps the greatest contribution a talented team can make is to produce software with greater internal quality. It strikes to me that the productivity difference between a talented programmer and an average programmer is probably less than the productivity difference between a good code-base and an average code-base. Since talented programmer tend to produce good code-bases, this implies that the productivity advantages compound over time due to internal quality too.

I'd say this is actually the most important aspect. Of what use is the ton of code if it doesn't work? In one of the previous companies I worked for, an informal study showed that every bug that ends up in developer's lap (confirmed bug that needs fixing) costs the company, on average, one thousand euros. The reason is not that developers' time is expensive, but that the problem needs to be processed by support personnel, repeated, described/documented and after the developer is done fixing, the issue needs to be confirmed as fixed.

Think about this. With a couple of bugs "generated" a cheaper but lower quality developers will nullify the salary difference. Or vice-versa: with each bug not created a more expensive but higher quality developer will cost you less.

Unfortunately not many (if any) companies look at the problem this way. Usually the only metric is how fast one can reach the "finished" product state. The time spent in fixing all the issues introduced by rushing the product out of the door never "counts". It's a shame.

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.

Having a richer UI than the HTML can provide while still keeping the great deployment model of HTML (or lack of, you don’t deploy anything) is what brought us semi-solutions like AJAX (helping in the interactivity department) and RIA platforms like Adobe AIR and Microsoft Silverlight.

Actually, there was one sorta-kinda competitor here since the end of 2006: XBAP or XAML Binary Applications (at least I think that’s what it stands for). XBAP is a way to bring your WPF application into the browser. You get all the rich interactivity of WPF and simple deployability of Web based solution.

Except that the XBAP sucks, big time. It conforms to the .NET security model and naturally XBAP falls into the “Internet zone” which basically means nothing will work. In the end XBAP is useful in the Intranet scenarios and even there with a few issues.

When Silverlight (SL) 1.0 came out I was really looking forward to its successor, version 2.0 which was supposed to bring .NET CLR into the mix (SL version 2 beta 1 just came out a week ago). SL is a smaller subset of WPF and .NET with added benefit of a lot smaller download size and portability – runs inside all major browsers on Windows and Mac OS X (and even on Linux as soon as Mono guys finish the porting). SL uses different security model and thus is actually useful for (shocking) network-enabled Web applications. Microsoft almost ruined even SL – initially the plan wasn’t to have Socket support in the SL, but after many protests from developers Socket support is now present in 2.0 beta 1.

If you ask me, XBAPs are obsoleted by SL. In Intranet scenarios, I’d just use desktop WPF applications while for Internet scenarios SL is a way to go.

Additionally, Silverlight is revolutionary as it brings the .NET Framework into one other major platform besides Windows – Mac OS X.

Reading Slashdot one could safely assume that Microsoft is the root of all evil on earth. But to think that Microsoft’s power (pun intended) extends to the other worlds… I didn’t see this one coming.

The screenshot to the right shows what the spelling checker of Firefox 2 (on Windows, oh the irony) thinks of the most excellent Windows scripting/administration shell called Powershell. Powers hell? No wonder Microsoft is as successful financially

When it was revealed that IE 8 is indeed in the making a couple of months ago, the news of the day was the improvements Microsoft has made to IE regarding standard compliance.

Theoretically, things were going great: Microsoft passed the ACID 2 test demonstrating quite a big step up from the IE 7. For years Microsoft has been catching up with the Web standards, but the pace of the progress has been slow. Each new version of IE after and including version 6 was just a bit more compliant. Passing ACID test was supposed to demonstrate that IE 8 will in fact be sufficiently standards compliant so that Web developers can finally code once, deploy everywhere (for more on the different modes of browser behavior see Wikipedia page on “quirks mode”.)

Or so it seemed. The problem at the time of the original IE 8 announcement was the way the standard behavior of the browser was supposed to be triggered. Due to the large number of Web sites that still target broken “standards” mode of older IE versions, Microsoft decided to introduce a new meta tag with which a developer would opt-in to the “really really standards mode”. Thus, by default, the IE 8 would behave the same as IE 7, which in a way defeats the purpose of the real standards mode and would most likely slow down the adoption of the standard compliant pages.

The decision to go with the IE 7 standards mode by default resulted in a huge backlash from developers. Basically by doing this Microsoft introduced yet another special case that a web developer has to think about. If the IE 8 was in the standards compliant mode by default and judging by the level of the standards compliance of both Safari 3 and Firefox 3 it looked like web developers could finally stop conditionally styling the pages, which is a huge win for everyone.

Then a great thing happened. During this years’ MIX conference Microsoft announced that IE 8 will in fact by default do things the right way. If a developer wanted to get a IE 7 “standards” mode it had to explicitly say via a meta tag, so the situation is a reverse of what it used to be. To rectify the cases where a developer didn’t say anything, the web site was targeting IE 7 and therefore looked bad in IE 8, Microsoft added an “Emulate IE7” button featured very prominently in the main toolbar.

We can only speculate what motivated Microsoft to make such a change. Some think that increased pressure from various lawsuits in Europe and particularly complaints by Opera about the need for Microsoft to increase IE’s standard compliance was a main driver. Some think that it was simply a part of the overall Microsoft strategy to open up. Some think Microsoft actually listened to customer feedback.

Whatever it is I am grateful. Even though I do not do much Web work, what I did do was often an exercise in pain trying to align the look & feel across major browsers.

Here’s to hoping that by the end of this year one will have very reasonable standards support across all major browsers  and that the compatibility nightmare will finally be over.

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.