Will our current programming model survive multi-core hardware?

For years the innovations of CPU's have been focused on increasing the speed at which a single sequence of instructions gets executed (mainly by increasing the clock frequency). In the last years this trend is changing from increasing sequential execution speed to parallel execution (multi CPU / hyper-threading / multi core). If this trend continues the number of processor cores will no longer be measured in dual or quad, but in K, M or G.
Today's popular programming languages (both OO as procedural) encourage (or force) us to write software as a sequence of statements that get executed in a specific order. This paradigm is called an execution thread and it maps very nicely on the traditional CPU model which has a single instruction pointer. Executing tasks in parallel is made possible by calling a system API that creates a new execution thread. This is more a platform than a language feature, which requires even more system API's to do the required locking and synchronization.
Generally multi threading is considered an advanced and error prone feature. This is why it is generally used only in situations where parallel execution is an explicit requirement, like in server processes to handle multiple client requests and in GUI applications to allow background processing while the UI keeps handling user events. In situations where tasks could be executed parallel, but there is no direct need to do so, we usually stick to our traditional sequential programming model. This is a great waste of the hardware’s parallel processing ability
My personally experience to non-sequential languages is pretty much limited to SQL and XSLT. Maybe it is time to spread the horizon and take a look at some of the modern Functional languages like F#  and Fortress. Who is with me?

Lack of support for generic base classes in Windows Forms designer

Just recently having started my first real life .Net 2.0 project I wanted to utilize all the cool new features in my day-to-day job. One of those features is of course the support for Generics in C#. But, as with all cool stuff, getting your hopes up to high can get you disappointed.
In our Windows forms application we use a design pattern in which a UserControl defines a callback interface which is implemented by a mediator. This makes sure we have a loose coupling between the UserControl and the source of the rest of the application.
To avoid having a lot of duplicate code I decided to make a base class that does some of the stuff related to initializing the mediator. While every control will have a different mediator interface this called for generics (sample code is written by hand, so don't mind the compiler errors).
class ViewControlBase : UserControl
 where TMediator : IMediator
{
 TMediator _mediator;
 protected TMediator Mediator
 {
  get { return _mediator; }
 }
 public InitMediator(IMediator mediator)
 {
  _mediator = (TMediator) mediator;
  // some more generic stuff
 }
}
Now the viewControls are derrived from ViewControlBase like this
class CustomerView : ViewControlBase
{
 // … Use typed access to the Mediator property
}
By using a generic base I was able to have Typed access to the Mediator in all the derived classes, and I avoided writing the initialization code over and over again. Hitting F5 proved all worked just as expected.
But when I opened one of the ViewControls in the designer the designer was filled with an error saying something was wrong. Usually this means that you have to rebuild the solution, clean up, rebuild some more and eventually it works. Not is time
The error stated that the class CustomerView was not 'Designable' because it was not able to create an instance of ViewControlBase. That is true, it is however possible to create an instance of ViewControllerBase
I found a work-around (or a dirty Hack) by creating an empty dummy class like this
class CustomerView : CustomerViewDummy
{
 //…
}
class CustomerViewDummy: ViewControlBase
{}
Now CustomerView is no longer (directly) derived from a generic class the designer stops complaining and shows the control in design view as expected. Since I didn't really like this solution I went back to old-school and duplicated the same code in every control (Bummer!)

Timezone aware DateTime stucture in .Net 2.0 ?

The last year and a half I have been working on a project based on .Net framework 1.1, that (among other things) involved handling multiple time zones. If you have ever worked on such a project you either did it wrong without knowing or you have spent a whole lot of time getting it nearly 100% right. The biggest problems are the XML serialization that always assumes en DateTime represents local time, and the lack of a specific Date-only data type which is time zone independent. When it comes to handling DateTimes in different time zones .Net framework 1.1 just doesn't cut it.
Framework 2.0 brings partly good news, only last week I happened to 'intellisense' over a new property on the DateTime structure; DateTime.Kind. It seems that Microsoft has found a use for 2 unused bits in the 64 bits that hold up the data for a DateTime structure. These 2 bits were not enough to store the actual UTC offset. Instead they choose for three possible values, Local, UTC and Unknown. This is a big improvement because it solves the incorrect XML serialization problem of UTC DateTimes.
The lack of the actual UTC offset in the DateTime structure still has the downside of not being able to handle time zones other than UTC or your own (the one configured in the regional settings) without storing the offset in a separate field and doing your own transformations. Of course the DateTime being a structure which cannot be inherited from doesn't really help to create a generic solution for this one. Second it causes an ambiguity in the hour in the fall when the clock shifts to daylight saving time. This can cause an UTC time being converted to local and back to UTC not to be the same as the original. Last time this happened some of our unit tests broke because the daily build cycle runs exactly within this hour.

SQL Server 2005 vs. Office Web Components

Last week I installed SQL Server 2005 Developer Edition on a development PC. This took almost as long as installing an Oracle server, which is not what I am used to when running a 'routine' SQL Server Setup.
The SQL 2005 installer starts off with a check for all the prerequisites, and all lights were green. I choose an allmost default install of the client tools and the SQL instance itself. When half way installing the required components I got a message that I had a previous version of the 'Office Web Components' (OWC) installed. I needed to remove this previous installation and restart the setup of SQL Server. Bummer.
Checking the 'Add / Remove programs' applet I found that there was indeed a OWC XP version installed, after choosing 'Remove' and clicking through the dialogs I was ready for a retry. Starting up de SQL server setup again choosing the same options as before, all lights green again and …. 'a previous version of OWC is found, please uninstall and redo all the stuff you did twice before ….grrrrr.
Once again I fired up the add / Remove programs and found that now OWC 2003 was installed. Again I uninstalled it, did a reboot for safety and restarted the SQL Server Setup. What do you know… again the same message.
For the third time (of the forth I forgot the actual count) I uninstalled OWC from the Add / Remove programs applet and immediately after removing it I reopened the Add / Remove programs and It was still there!! Even after another reboot, uninstall etc etc the Add remove programs still showed OWC 2003 installed.
As a last resort I located the OWC11.msi on the SQL Server 2005 CD and reinstalled it directly from there. After this I was able to to re-run the SQL Server setup with no problem.