Note: Since this post is about German politics, it’s consequently in German.
You may find a similar obituary here. Background information can be found here.

Am 18.06.2009 hat die Bundesregierung das

“Gesetz zur Erschwerung des Zugangs zu kinderpornografischen Inhalten in Kommunikationsnetzen”

verabschiedet. Dieses Gesetz soll Opfern von Kinderpornographie helfen, indem der (zufällige) Zugriff auf entsprechende Seiten im Web durch eine Internetsperre (soll heißen, die Umleitung auf eine Hinweisseite auf Basis von DNS) unterbindet. Die Diskussion um dieses Thema und die gesetzliche Verankerung ist ein Trauerspiel sondergleichen und veranlasst mich zu dieser virtuellen Todesanzeige.

Wir tragen also zu Grabe…

 
Demokratie und Rechtsstaatlichkeit.

Im gleichen Jahr, in dem wir den 60. Geburtstag des Grundgesetzes feiern, wird ein Gesetz verabschiedet, das demokratischen Grundsätzen, der Rechtsstaatlichkeit und dem Föderalismus Hohn spricht.
Das Prinzip der Gewaltenteilung – eine der Säulen unserer Gesellschaft – gilt nicht mehr. Eine Polizeibehörde wird Ermittler, Ankläger, Richter und vollzugsverantwortlich. Eine öffentliche Kontrolle, wie sie selbst bei den Geheimdiensten für notwendig erachtet wird, gibt es nicht. Der faule Kompromiss nachträglicher Kontrollen ist ein reiner Verwaltungsakt und somit kaum geeignet, Grundrechtsprinzipien aufrecht zu erhalten.

 
Die Erinnerung an missbrauchte Kinder

Dank Sichtschutz dürfen sie bald wieder im Verborgenen leiden.

Wäre es um die Opfer gegangen hätte man die Seiten abgeschaltet. So wie es Carechild, AK Zensur und Jugenschutz.net gezeigt haben. Die Seiten sind und waren aus Sperrlisten bekannt – getan hat das BKA offensichtlich nichts, genauso wenig wie das Bundesfamilienministerium. Und sie taten nicht nur vor der Diskussion nichts (für diesen Zeitraum hätten sie immerhin technische oder personelle Unfähigkeit ins Feld führen können). Sie taten auch während der Diskussion nichts, obwohl ihnen die Möglichkeiten deutlich aufgezeigt wurden.
War es politisch nicht opportun der Argumentation der Regierung durch Abschaltung den Boden zu entziehen?

Wer dachte, es gibt nichts widerwärtigeres als Kinderschändung, der wird mit dieser Instrumentalisierung derselben zur Selbstdarstellung und zu parteipolitischen Zwecken (fast) eines Besseren belehrt.

Jede Form von politischem Anstand

Die Bundesfamilienministerin als Vorreiterin, die Minister für Inneres, Justiz und Wirtschaft im Gefolge – ein nicht unerheblicher Anteil unserer gewählten Regierung –, dazu jede Menge parlamentarisches Fußvolk. Und gemeinsam lassen sie ein Feuerwerk an frech ausgedachten Behauptungen, bewussten Falschinformationen und offenen Lügen los. Wer dennoch dagegen argumentiert, der wird in die Nähe von Kinderschändern gerückt oder zum Internet-Anarchisten abgestempelt, der auf dem Rücken missbrauchter Kinder einer fragwürdigen Utopie nachhängt.

Und dieser Regierung soll ich glauben, dass ein Gesetz, dass den Aufbau einer Zensurinfrastruktur nach sich zieht, nicht in andere Bereiche ausgedehnt werden wird?

***********************

PS: Ich habe lange überlegt, ob ich diesen Beitrag tatsächlich veröffentlichen soll. Dann habe ich misch dabei erwischt, den Artikel daraufhin Korrektur zu lesen, ob er womöglich strafrechtlich relevante Aussagen enthält. Wenn die Schere im Kopf am Schneiden ist…

PPS: Ich habe auf Links verzichtet. Nicht weil ich die Aussagen nicht belegen kann oder will, sondern schlicht weil es einfach zu viele sind. Daher hier nur folgende Verweise:

• “Gutachten: BKA könnte mehr zum Löschen von Kinderpornos beitragen” (heise) betrachtet nur einen Teilaspekt, hat aber eine Linkliste am Ende, die u.a. auf sehr häufig zitierte grundlegende Heise-Artikel zum Thema verweist.
• Solange es verfügbar ist bietet das Forum zur “Petition: Internet – Keine Indizierung und Sperrung von Internetseiten” (Online-Petition beim Petitionsausschuss des Deutschen Bundestages) jede Menge Meinungsäußerungen, Hinweise auf Informationen und insgesamt ein Bild, wie es um die Stimmung der Teilnehmer bestellt ist.
• netzpolitik.org ist eine gute Adresse um auf dem Laufenden zu bleiben. Zum Thema gibt es dort die “Kommentierte Zensursula – Linkliste” (netzpolitik.org), die hier stellvertretend für viele weitere im Netz steht.

PPPS: Stellvertretend für die Opfer: MissbrauchsOpfer Gegen InternetSperren.

In Trauer,
AJ.NET

Today I’d like to share another left over from the SDX Talk I mentioned earlier: Basically some screenshots from Visual Studio 2010 Architecture Edition (VSArch from now on). Don’t expect something fancy if you already know VSArch, I just couldn’t find all that much information on the Web beyond the two screenshots on the Microsoft site.

The main new things within VSArch include the Architecture Explorer, UML Support, and the Layer Diagram.

Architecture Explorer

Note: To make the following more tangible I loaded a sample project I use regularly as test harness and took respective screenshots while I analyzed it. Click the images for a larger view…

The Architecture Explorer is about getting a better view into existing code. Whether you join a project that is under way, whether you have lost control over your code, or whether you just need to spice up your documentation. Architecture Explorer helps you by visualizing your solution artifacts and dependencies. Artifacts include the classical code artifacts (classes, interfaces, etc.), as well as whole assemblies, files, and namespaces.

Architecture Explorer lets you select those artifacts, display graphs with dependencies, and even navigate along those dependencies and in and out of detail levels.

The following screenshot shows VSArch. The docked pane on the bottom contains the Architecture Explorer that acts as “navigation and control center”. This is where you select your artifacts and visualizations. It could certainly use some improvement from a usability perspective, but it does the job anyway.

The screenshot shows two different visualizations of the assembly dependencies in my solution, a matrix view and a directed graph. Just to stress the fact: This was generated out of the solution, by analyzing the project dependencies.

The next screenshot shows a mixture of various artifacts, including classes, interfaces, even files, across parts of or the whole solution.

Depending on what filters you set, this graph could give you a high level overview of certain artifacts and their dependencies. For example you could easily spot hot spots, like the one class your whole system depends upon. Or make sure the dependencies are nicely managed via interfaces and find undue relationships. Even spot unreferenced and therefore dead graphs.

Once you go one level deeper, you may want to cluster the artifacts by some category.

The image shows again artifacts and their dependencies, but this time grouped by the project to which they belong. It also shows what kind of relationship a line represents and lets you navigate along that dependency.

The Architecture Explorer should help getting a better understanding of your code. It helps you to detect code smells or may guide your refactoring.

UML Support

Yes, UML like in, well UML. Not extensively, but it includes activity diagram, component diagram, (logical) class diagram, sequence diagram, and use case diagram. I didn’t spend much time investigating them, just drew some diagrams in order to take the screen shots. Generally I can say that Microsoft can draw boxes and lines (big surprise here) but there is a lingering feeling that those diagram editors may not be finished yet (again, hardly surprising on a CTP).

Creating a new diagram is easy enough. Just create a new project of type “Modeling Project” and add an item:

Everything starts with a use case, so here is our use case diagram:

One can draw the diagram as he likes. As you can see from the context menu, there is something being worked on. Namely the “Link to Artifacts” entry shows the Architecture Explorer, yet I couldn’t quite figure out what’s behind this. Also note the validate entries which didn’t do very much, but we’ll see them later in the Layer Diagram.

Next on the list is activity diagrams:

Works as expected, no surprises, no hidden gems that I’ve found.

The same is true for the component diagram:

Just a diagram, no surprises.

The logical class diagram gets more interesting:

As you can see, it contains very .NETy stuff like enumerations. It also has these menu entries that hint on more to come in the future — right now the selected menu entry brings up the error message asking for a stereotype, yet I didn’t even find a way to set those. Also the editor may still need some work, e.g. one cannot drag classes in and out of packages.

As a side note: The relation between this logical class diagram and the already existing class diagram escapes me. At least they are a little redundant.

Next on the list is the sequence diagram. Rather than drawing one myself I reverse engineered the existing code:

Quite nice and again, used this way it can help you documenting or just plain understanding existing code.

Note: If you want to try that yourself, the CTP has a bug: You need to have a modeling project and at least one diagram before the menu entry “Generate Sequence Diagram” appears. And while you will be presented with a dialog asking what call depth to analyze, it usually works only for one level.

Layer Diagram.

Now for the most dreadfully looking diagram (though Microsoft has a more colorful one on its site…): Some boring connected blocks, meant to represent the layers of your architecture.

Actually this is one of the most interesting features for any architect and dev lead: It’s a living beast!  

You can add assemblies as well as other artifacts to the bleak boxes. Afterwards you can actually validate whether the dependencies between those artifacts match or violate the dependencies implied by the diagram. In the screenshot you can see that I deliberately misplaced an assembly and consequently got a respective error. Using this feature an architect can ensure that all layer related architectural decisions are honored during development.

To conclude…

The Architecture Explorer is certainly a worthwhile feature and I also like the validation feature of the Layer Diagram. That’s certainly something new and not to be found in other products.

Generating sequence diagrams is nice but it remains to be seen whether this will allow roundtrip engineering. The logical class diagram doesn’t yet meet my expectations and it’s not quite clear to me how it will evolve. The other diagrams? Well, they just work. However in this group is nothing exciting for you if you already have another modeling tool like Enterprise Architect (no advertising intended, just happens to be the one I’ve used recently…). And a dedicated tool probably will provide a more complete UML coverage. UML 2.0 has 13 types of diagrams, including state diagrams, which is in my opinion the biggest gap in VSArch UML support.

Anyway, if that caught your attention and your interested in more details there are two options: One, download the CTP and try for yourself. Two, if you want it more condensed and avoid the hassle with a VPC, watch a video with VSArch at work. For that there are two links I can provide:

1. Peter Provost’s talk at the PDC. Go to the timeline on the PDC site, search for TL15 and you should find “TL15 Architecture without Big Design Up Front”, which is about VSArch, despite the title. His talk was the role model for my analysis of VSArch, yet seeing it live could still give better insights.
2. Visual Studio Team System 2010 Week on Channel 9 has a bunch of videos, especially the “Architecture Day” ones. “top down” and “bottom up” show VSArch at work.

The final question however will be if all those features are compelling enough to actually buy the … Visual Studio Team Suite (i.e. the “you get everything” package). Why not the Architecture Edition? Well, if you are a developer as well as an architect, the Architecture Edition lacks too much in the other areas. Given that there is usually quite a monetary gap between dev edition and team suite, that gap might very well be used to buy a 3rd party UML tool instead… .

That’s all for now folks,
AJ.NET

As a follow-up to the last post, I’d like to review one question I got after the talks I held. That one was particularly interesting, because it highlights a certain aspect of the changes that we have to face with multiple cores and some misconceptions some people might have:

Doesn’t today’s multithreaded software profit from more cores automatically?

The answer is a definite yes and no. Server software like IIS or SQL Server has always been optimized for throughput (performance only secondary) and as long as the processing is CPU bound it will certainly put more cores to good use. That should result in better throughput (i.e. more requests handled at the same time), but not necessarily in better performance (i.e. the time to complete one request).

The more interesting observation however is on the client: Client applications follow different use cases for multithreading, actually mainly two of them:

1. Avoid blocking of some task while processing something else. Examples include keeping the Windows UIs responsive (i.e. work around the UI’s thread affinity), Windows Services (their service control handler is invoked by the SCM and has to return in a certain amount of time).
2. Be able to spend processing time on something valuable while one task is blocked waiting for something to happen. Blocking regularly happens during some kind of I/O, especially network calls. This is the „call WebService asynchronously and do something worthwhile until the call returns“ scenario.

Just different sides of the same coin actually. Please note that neither use case has been about actual performance, as in doing things really faster. The first one is about perceived performance by reducing latency for some favored task, the second one improves performance, albeit not by doing things faster but by avoiding unnecessary wait times. Anyway, this works quite well even (or rather especially) on single core machines.

Let’s dig deeper into an example: Say a lengthy CPU intensive calculation is triggered by a button. The time spend on updating the UI and doing the calculation is denoted in the following picture, the red line represents the executing thread:

The calculation is done on the UI thread, giving it peek performance, but at the same time freezing the UI until the calculation has finished. The typical “optimization” is putting the calculation on a second thread, e.g. using the BackgroundWorker component. That way, the UI keeps updating itself rather than degenerating to one of those white and unresponsive windows:

The UI and the calculation run on different threads (yet still on one core), thus the UI can update itself even during the calculation is still running. However, now it has to deal with that intermediary state (denoted by the striped blocks). And every time the UI thread uses the core, that time is lost to the calculation, so the time to completion will actually be longer than with A.

Now switch gears to our new, say quad core, machine…

What happens on a quad core is that both tasks now get executed in parallel:

As you can see, actual processing time is now back to the same it was with A, yet it manages to avoid freezing the UI as in B; again at the expense of having to deal with the intermediary state. However that’s about as good as it becomes. But the application doesn’t get faster, neither will a third or fourth core be utilized at all (other than ensuring that other applications can run there rather then interfering with the cores we just occupied).

So, while the potential in “classical multithreading” lies in shifting or arranging calculations of disparate tasks, the potential of parallelism with many cores lies in doing more calculations of CPU bound tasks at the same time. Like so:

This time the calculation has been split into parts and been distributed on different threads on top of the UI thread. This eventually caused better performance than A. However this is not the way today’s multithreaded applications are written, because on a single core it actually leads to worse performance, due to memory pressure if used excessively, thread context switches, synchronization and contention, etc..

The verdict…

Today’s multithreaded client software may profit from more cores, but to a far lower degree than one might think at first. And what’s more: It might even stop running altogether because actual parallelism opens the door for error conditions that were simply theoretical threats on a single core system but become a reality on multi cores. Something like accessing some memory while another core is still in the middle of an instruction doing the same.

PS: And by the way: the future is now!

I just started in a new project and got my new machine last week: An HP wx6600, with 2 quad cores @ 3GHz, 4GB

This is a task manager screenshot, showing 8 nice little cores, sitting under my desk, waiting for me to send them on one or the other errand…

A single core is such a lonesome entity…

That’s all for now folks,
AJ.NET

The so-called „many core shift“ is happening. It’s not a thing of the future, it’s not „just around the corner“, it has already begun. And it will change our developers’ life.

Last week we had some customer events, containing some talks about PDC and other stuff and how it will affect the near term future. Among other things I tried to describe the many core shift as well as its consequences. Curiously the audience was largely aware of the facts, yet the consequences had yet escaped the vast majority. So let me try to repeat the gist and see whether this is maybe a common symptom…

What’s the many core shift, anyway?

Moore’s Law states that the number of transistors on an integrated circuits doubles every two years. Until not long ago, and accompanied by more complex designs and higher clock speeds, that meant faster CPUs. This was sometimes called the „free lunch for developers“, because if one happened to write a slow application… not that anyone ever would , all he had to do was wait two years and it ran twice as fast.

However this evolution has reached its physical limits (clock speed, power consumption, etc.). Yet, still the number doubles… .
So instead of building faster and more complex CPUs, the manufacturers started placing more CPUs, read cores, on a chip. It started 2006 with Intel’s dual cores, today you won’t find a single core desktop machine anymore. High end consumer machines come with quad cores, and servers with 16 cores (delivered as 4 quad cores). Have a look at the extrapolation:

The “lower” line shows cores on a CPU, starting 2006 with 2 cores, while the steeper one assumes 4 CPU sockets. And just in case the conclusion escaped you: Five years from now we will have between 32 and 128 cores. And remember, we are talking “consumer grade stuff”, that is the box under your desk, not something special! Impressive?

So that’s the many core shift. But what does it mean?

Well, it probably means that today’s software runs a bit faster. Not much, mind you, certainly not the 32 times faster a 64 core machine is supposed to be compared to my dual core. Why is that? Well, have a look at the following task manager of a 64 core machine:

(That’s a fake of course, but have a look at Marks’s blog for a real one.)

Now look at your own desktop and count the open applications. Outlook, Word, perhaps PowerPoint, Internet Explorer, Acrobat Reader? OK, say half a dozen applications, add 10 more for the OS stuff actually doing something. That’s 16 applications, using the upper row of cores, perhaps even to 100% and yearning for more, while the other 3 rows just sit there and twiddle their thumbs. That sad truth is: Most of today’s applications simply are not capable of employing these cores appropriately. Consequence: In order to leverage these cores we have to change the way we write our software!

Two questions come to mind: Do we actually need that kind of processing power? And if so, how do we open it up?

Seriously, does the average user need 64 cores?

Well, yes he does. If for no other reason, he did need the increase in processing power during the last years, why should that change?

So, what does he need it for? Gamers are always at the forefront of processing power demand. We have the generally increasing demand in UI technology: 3D, animations, visual effects are becoming mainstream with windows, WPF and Silverlight. The trend to digital photography has had its effect on the demand for graphics software. On my dual core, DXO needs about 1 hour per 150 pictures, so there’s certainly room for improvement (I brought 2500 pics from my last vacation in Tanzania. Do the math ). Background encryption, compression, virus scanning, etc. also add up.

Even if you are an “ordinary business user”: Word just sits and waits for your input most of the time? Well, open a non trivial 100 page document and see how long Word takes for pagination, spell checking, or updating the TOC. Change the formatting and watch again. So while Word mostly does nothing exciting, there are „burst times“ when it could really need those cores.

And I did not even mention Visual Studio and the compiler yet…

How do I, Joe Developer, put 64 cores to good use?
And how do I make sure the app doesn’t degrade on an old dual core beyond reasonable limits?

Here we are right at the center of the problem: Multithreading is not exactly something new, we’ve had that for more than 20 years on PC’s now. So why do I even have to ask that question? It’s because we didn’t actually use multithreading within our applications if we didn’t have to. Because it’s laborious, error prone, awkward. You have to deal with thread synchronization, race conditions, dead locks, error management, communication between threads. You can’t debug it, tracing doesn’t help very much either. In short: It’s a pain in the …, well.

So let’s face it: Most developers have avoided multithreading altogether (perhaps the lucky ones). And those who did do multithreading probably did it just for optimizations in very distinct areas.

But what we need to leverage those cores is quite the opposite: We need multithreading to become mainstream, kind of ubiquitous. For that it needs to be easier to employ parallelism. Complexity has to be pushed out of our code into the platform. Somewhat like nobody thinks any longer about virtual memory (while some of us are old enough to remember the days of physical addressing).

In other words: In order to deal with the parallelization demands, we need new patterns, libraries, and tools.

Microsoft is going to give us a first delivery on that with the next Visual Studio 2010 and .NET wave. Optimized runtimes (e.g. the thread pool), better tools (e.g. the debugger) and not the least, new libraries, introducing new patterns (e.g. Task Parallel Library). There’s more in the unmanaged world (e.g. Parallel Patterns Library), more on the server side (CCR), more on the language front (F#), more in the research area (transactional memory).
Microsoft even devoted a whole “developer center” to parallel computing (look there for more details). And quite rightly so, because there is no single solution to parallelization, it comes in different flavors (e.g. data parallelism vs. task based parallelism) and we can expect further developments in this area in the future.

Also it’s noteworthy that the OSes, namely Windows Server 2008 R2 and Windows 7 which share the same kernel, can manage 256 cores. Compared to what they supported before this is quite a jump.

Conclusion

So, parallelization is here to stay and we are going to have to deal with it. If anything, the trend is going to accelerate. It’s reasonable to assume that eventually processor manufacturers will trade single core performance for number of cores, i.e. put more but less capable cores on a chip, in order to save power consumption (green IT and mobility being two other major trends).

Looking even further, the many core shift may reach a break even where standard desktop systems will cease to profit from additional cores (how parallel can you become after all?), the problems of memory access may limit the amount of cores. Asynchronous multi cores may evolve, e.g. having cores optimized for certain tasks…

See, there’s a lot to look forward to. Our profession certainly remains interesting

PS: See Being Parallel? for some thoughts on whether today’s multithreaded client software will profit from additional cores…

That’s all for now folks,
AJ.NET

… is something I did explicitly not want to do!

Not that it is not necessary to do so. It’s just that I expected a lot of bloggers, especially from Microsoft itself, trying to spread the news and foster understanding of what is ahead of us. Well, the Microsoft folks became kind of hushed, as if ducking down and counting the shrapnels after having thrown the bomb at the PDC. So I changed my mind…

Preface…

Given what Microsoft unveiled at the PDC — A new vision, a new strategy, a new technology stack, and a mish mash of existing, sometimes overlapping, not yet consistent, much less complete applications and services — it’s no wonder that it took me some time to grasp the idea. And when I thought I might have understood the gist I was still, well, unsure of whether I had gotten it all right.
The breakthrough came at the ask-the-experts. More to the point I had the chance to talk to Ori Amiga (the guy that did the “BB04 Live Services: A Lap around the Live Framework and Mesh Services” talk). Other than joking about the various ways to pronounce “Azure” and the fact that Americans always manage to get it wrong (sorry guys — and sorry Ori, hope I didn’t give you away too badly ) ), this little chat really turned “suspected functionality” into “understood technology” (at least I do hope so…).

Explaining Azure worked not on explaining the ever present Azure picture as is. It worked on developing the pieces of the picture, bit by bit, and relating it to other concepts. And since I worked for me, I thought I might share the gist of that conversation in much the same style, hoping I’m providing new insights rather than reiterating already available information. Actually I’m going to use the very sheet of paper we (mostly Ori) drew throughout said discussion. 

Enough of the preliminaries, here we go…

First of all, keep in mind that there’s two Azures: Windows Azure and the Azure Services Platform. They are not the same and neither presents the full picture. I’ll try to dissect that picture layer by layer, like a cream gateau…

It starts with the cake bottom: Windows Azure

Windows Azure is the basic “infrastructure” (to avoid the term “Operating System” for now) to run applications on, highlighted in the following picture in red:

That includes computing capabilities, basic storage, management of applications (i.e. deployment, including upgrading), and operations (e.g. handling failures). These concepts are abstractions from the underlying OS (Windows 2008 actually), machines, and storage devices.

The terms to think of are service instances rather than processes or (virtual) machines. This is similar to the way virtual memory abstracts physical memory. While any memory access obviously has to happen on physical memory, the virtual memory manager is free to relocate it, even to swap it out to disk. This not only makes applications independent of the amount of physical memory, it also optimizes resource usage, allowing other applications to use the memory my application has claimed but does not access at the moment.

Yet, while Microsoft Azure is one level of abstraction above the machine’s OS, it has similar concepts (highlighted in the above picture in blue):

• computing ~ job scheduling, etc. (NT Kernel);
• storage ~ file system (NTFS);
• management ~ application installer;
• operations ~ task manager, event manager, etc..

Thus it is quite feasible to call Windows Azure an Operating System for the datacenter (or for the cloud if you’re a marketing guy), even if that may not match exactly what you learned in university about operating systems.

The implications of deploying an application to Windows Azure (i.e. how the application has to be built and how the fabric manages it) is actually quite interesting … but a whole new blog post, thus I will skip that for now.

Let’s move on to the second layer of the cake: The Azure Services Platform

A barebone OS like Windows Azure would be of limited use if it were not completed with other general purpose services. Which services exactly that includes may be debatable, yet, again, the similarity with our local environment may help depicting the features we as developers have come to expect from the platform we are developing on: database service, user accounts, IPC, etc..

Again, the following picture highlights the services in red and similarities in blue:

Microsoft decided that the following services may be good ones to start with:

• .NET Services: basic infrastructure services for application security (access control), application communication (Service Bus), and workflow (three guesses…?).
• SQL Services: database related stuff; not exactly a SQL Server, but aspiring to be…
• Live Services: All around social applications (community, devices, etc.)
• Core application services: This is a set of higher level application services, such as SharePoint Services and CRM Services (explicitly not including the UI!). In my opinion they are there because they were readily available, not because they are particularly necessary.

Oh, and not to forget the reoccurring three dots in the PDC slides; those dots tell us that these are not closed and sealed sets. Actually Microsoft said that every major server application will eventually be made available on Azure.

Now for the chocolate and the cream: the applications running on the Azure Services Platform

While Ori included the application layer in the platform, any PDC slide puts it on top:

Where you put the label is of no consequence anyway, because this is no more than a logical hierarchy. However, please don’t misinterpret this hierarchy by assuming that those applications have to run on Azure and only applications running on Azure can leverage the Azure services! Au contraire!

If you have an application deployed on Azure it is (technically speaking) no different from other services. The difference only lies in the purpose, or the consumer if you wish. And still applications and services are free to call any services, not just those running on Azure. Likewise if your application is running on your local machine or network it can use services deployed on Azure to store data or integrate with whatever, that’s fine as well. Actually the best example for this flexibility is coming from Microsoft itself: Live Mesh.

The cherry on the cream: Live Mesh

Technically speaking the Live Mesh Desktop and Live Services are just another set of applications and services running on the Azure Services Platform, complemented with applications running somewhere else and using those services. This limited view however would miss much of the capabilities of Live Mesh, and the way it enhances the platform.

Live Mesh aims no less than to connect people, devices, and applications. Live Services contains services for identity (LiveID), presence, etc., and Mesh Services to maintain users, devices, applications, and — a corner stone — synchronization. The resource model organizes mesh objects (data, news, etc.) in feeds and entries, which in turn are subject to synchronization among the applications being “deployed” to Live Mesh. “Deploying” an application means either actual deployment on Azure, or storing it for (seamless) installation on your local device, via Live Mesh Client, offline capable if built to be.

Still with me? Well, to make this mess, pardon mesh, a little more tangible, let’s recap the example of Ori’s talk (PPTX WMV, images taken from there):

He had his media center PC connected to the Live Mesh, advertising its meta data, like favorites, recordings, etc.. That information was synchronized to the Live Desktop (running in the browser), so he could pick a TV show there and “start” recording. (Actually that “start” was some little piece of data, synchronized back to the media center PC which in turn did, surprise!, start recording.) He then started a locally installed application that showed the TV guide and had the typical red recording sign right at the respective TV show. That application was offline capable, so he could have planed his TV recordings on the airplane and have it synchronized when he gets back online. Finally he also showed the same TV Guide on his mobile phone simulation.
The only thing missing was integration with other people, but I think it was in a key note where they showed an application that allowed sharing of film critics with some friends.
All in all, that’s what I call ubiquitous computing!

Spicing the cake: Developer tools

This part is actually not in the picture, but it’s no less essential: Where does your application or 3^rd party code fit in? How does it get there? Those parts in red may be your application or service:

It’s actually quite easy: You can write applications that run on Azure and provide services (just like the basic services Microsoft provides), or an UI (just like Microsoft’s applications). You can access any of those services from the cloud or your local application, no matter whether Microsoft provided it or someone else. And you can Mesh-enable any of these applications and services as you like. This is an open platform!

Also Microsoft provides a simulated local environment for Azure, called development fabric, along with Visual Studio integration. Thus it is possible to develop your application locally, test it locally, and only afterwards deploy it to the cloud.
Regarding Live Mesh Matthias has more information on developing with Live Framework.

Postscript…

That’s it. You can find the complete untampered drawing here. That scrawl at the bottom of the drawing is actually Ori’s signature, but you should attribute any error, misunderstanding and adverse opinion in this post to me.

Finally two links for some alternate explanations (already repeated a thousand times over, but what the heck, they’re good):

• “Manuvir Das: Introducing Windows Azure”: Manuvir explains a little deeper how Windows Azure works.
  http://channel9.msdn.com/posts/Charles/Manuvir-Das-Introducing-Windows-Azure/
• “Windows Azure (aka “Red Dog”) explained in 145 seconds”: funny and enlightening (presented on a site you might find interesting as well)
  http://www.azurejournal.com/2008/11/windows-azure-aka-red-dog-explained-in-145-seconds/

That’s all for now folks,
AJ.NET

This post (and probably some more) is about coming to grips with Microsoft’s latest announcement at the PDC: Windows Azure and the Azure Services Platform. Matter of fact, I’m constantly turning this thing over and over, trying to discuss it with various different people, trying to think different scenarios through, and I’m constantly adjusting my perception. Frankly, if anybody tells you he has understood what is ahead of us, who says he knows how all that stuff will evolve, you’ve met a fool.

Now for this fool’s current view…

I’ll not try to explain it in technical details (not this time anyway, start at here or here to come up to speed — anyway, there are probably books being written about it right now). And I’m certainly not going to join the debate, whether Azure is an operating system or not.

I was still at the PDC when I started a Google search to see what reactions Azure triggered. That particular question was a predominant topic — and utterly without any consequence. (I couldn’t find that again though, it’s buried under millions of near identical pages describing Azure.)

So let’s talk about what Azure is about. For me, for you, for the companies we work for, for the industry.

Hailstorm — or what Azure is not…

When I first heard about some of the Azure stuff I immediate thought “Wait, didn’t they announce something very similar in 2001? Called Hailstorm a.k.a .NET Building Blocks a.k.a. My Services?”. It turns out that I was not the only one with this particular déjà-vu…

Taking a closer look, however, there are some significant differences in strategy between Hailstorm and Azure: Hailstorm was about Microsoft providing services to manage your data. Azure is about providing a platform for your services. In other words: With Hailstorm Microsoft said “give us your data and identity, keep the apps”, with Azure they say “give us your apps, you may keep the data and the identity (or you may choose to let us handle that as well)”. This is certainly a noteworthy change in attitude.

There’s another thing that changed since 2001. In 2001 Hailstorm was a new approach. It was visionary. It was the first time that someone asked me to let him manage my identity, appointments, even my wallet! And it was the evil empire that asked this very question… .
Today, hosting providers are a common thing and trusting Google or online communities with personal information is quite normal. Going even further, Amazon already offers a service platform with AWS, based on virtual machines (EC2), storage (S3 and SimpleDB), and a queuing service (SQS) as messaging bus. Google App Engine provides scalable application hosting (Python apps) and complements that with their identity system (Google Accounts). So, the good news for Microsoft is that they are for once not the bad guys. Of course, Microsoft being Microsoft, that probably only means that they will be accused of being the copycat again… .

What Azure may eventually become…

Still, what’s the big deal about Azure? I mean, doesn’t my hosting provider offer virtual or dedicated servers? Aren’t there enough storage offerings, many of them for free? Aren’t there Internet communities, online applications, service providers, …?

Well, looking at Azure piece by piece, there’s nothing new, nothing especially exciting. But take a step back and look at the big picture, at the strategy. With Azure…

Microsoft becomes a service hoster and operator. Not just a server hoster. They don’t stop at booting a VM. They operate your applications, load balance them, restart them on failures, scale them, provision them, provide an upgrade mechanism that doesn’t disrupt 24/7.

Microsoft becomes an application service provider as well as a service provider. They do not stop at providing fully fledged business applications like CRM or other. They offer basic infrastructure services like SQL Data Services or Workflow Services. You could even build your own CRM System, run it on Azure, competing with Microsoft’s CRM — and Microsoft couldn’t do anything about it (for if they would, that would put them out of business at the speed of light).

Microsoft becomes a service integrator. They don’t stop at getting applications into the cloud. They offer bridges to your company’s private network. Using Access Control you can leverage your local AD to control security. Using Service Bus you can integrate with any application on premise or in the cloud, even let business partners integrate with you.

Microsoft becomes a device integrator. They don’t stop at central storage or some device specific app for synchronizing contacts and appointments. The let you sync any application data on any Live enabled device on the fly, including handling offline cases.

Microsoft becomes a people integrator. They don’t stop at providing some social application. They allow you to collaborate with other people within your own application. “People” being users authenticated by your AD, LiveID, OpenID, and probably any other well-known ID provider. All based on “claims” in order to build trust between app and user.

And most important: They do all this at once! Putting it all together Microsoft offers a far more complete, comprehensive, and concrete vision of what the hazy term “cloud computing” means than anybody else out there. It’s the vision of interconnected, intertwined applications, devices, networks, … the next level of ubiquitous computing.

OK, I may have been carried away. Currently Azure is rudimentary, not yet version 1 (and we know what version 1 usually means at Microsoft) and many questions remain unanswered. I cannot help but think that the mixture of various existing apps and services with hosting and a big bunch of announcements, all wrapped up in a nice name, is more like a stew, thrown together but not yet readily cooked.

But then I might not. After all, Ray Ozzie said it loud and clear:

“[…] the systems that we’re building right now for cloud-based computing are setting the stage for the next 50 years of systems, both outside and inside the enterprise.”

and

“[..] we’re betting on Azure ourselves, and as the system scales out, we’ll be bringing more and more of our own key apps and key services onto Windows Azure because it will be our highest scale, highest availability, most economical, and most environmentally sensitive way of hosting services in the cloud.”

That’s what I call an announcement.

Does Azure stand a chance?

Cloud computing and Software-as-a-Service is widely seen as a coming trend, Azure or not. Microsoft is entering this market with vision, data centers, and service offerings. And a huge developer community and tooling support. This will change the IT industry and not many companies will be able to compete with that.

But a small statistic may be funny:

Google search for „Windows 7“: about 35,000,000 hits
Google search for „Windows Azure“: about 1,830,000 hits
Google search for „Amazon AWS“: about 13,000,000 hits
(measured 12. Nov.´08; add one for this post )

That’s 20 times more hits for Windows 7 than for Azure. Quite a poor result for the thing that denotes a change in strategy for the worlds biggest software company, the thing that Microsoft is betting its future on.
On the other hand, 2 million hits is “not too shabby” just two weeks after its announcement on the PDC. And it starts to shine if compared to the mere 7 times more hits for Amazon’s AWS, the offering that’s probably the most similar to Azure and one that dates back to 2004(!).

My opinion? Don’t expect Azure to play a big role next year or the year after. But then, don’t expect it to play no role in 10 years.

That’s all for now folks,
AJ.NET

Some time ago I promised some additional thoughts about how LINQ 2 SQL affects (web) application architectures. Well, here we go…

There are two defining characteristics of LINQ 2 SQL that may affect the architecture of a web application:

1. The DataContext class, being “the main entry point for the LINQ to SQL framework.” (as the documentation states.)
2. The way code generation works.

While the first point affects what features of LINQ 2 SQL we are able to use in web applications, the second one affects the application architecture.

Note: if you need to catch up with LINQ 2 SQL have a look at the my earlier post.

DataContext Effects

In this post I’ll focus on the DataContext class generated by LINQ 2 SQL.

The DataContext class is not only an anchor to access the tables, views, and stored procedures. It also offers more interesting features like change tracking, maintaining object identities, optimistic concurrency, and deferred loading. Consequently this is what most people I talked to attributed to LINQ 2 SQL: The possibility of reading some data, manipulating it, and call SubmitChanges, while LINQ 2 SQL handles all the gory details of mapping the data, efficiently talking to the database (including load on demand), dealing with concurrent changes, and so on.

This read/manipulate/submit approach is what the documentation describes as being “designed to last for one ‘unit of work’.” And in case the consequence escaped you: This this implies a statefull programming model. The very DataContext instance that was used to read the data has to be available until every potential change or deferred access has been settled.

This does generally not agree with web applications, as read/manipulate/submit regularly spans several requests: The data is read, presented to the user, and then the request dies, and in a stateless scenario the DataContext as well. The next request comes in, say an update request, but there is no DataContext available, carrying information about the data that was read before. In order to work with the laid out programming model, one would have to create a new DataContext, reread the data, and then apply the changes and submit them. With optimistic locking being the first victim, because for that the information from the previous request is mandatory. And delayed loading degenerates to “optional loading”, because either you need the data (no benefit in delaying then) or you don’t.

How about maintaining the DataContext instance across requests? No way either; since it is not serializable, you can’t put it into the session. (And that’s just a technical reason, whether one should do that even if it were possible is a different matter altogether.)

To make a long story short, let me rephrase and emphasize the first sentence:
For web applications the generated DataContext class is only an anchor to access the tables, views, and stored procedures.

BTW: Services are frequently bound to be stateless, too. Thus the same reasoning applies to them as well. Additionally they face another problem: They hand out the entities and get fresh ones from the outside world via serialization. Thereby they are removed from the DataContext, which is kind of unforgiving.

Less is More

Now we have concluded that the statefull approach doesn’t work. Reverting to a stateless employment of LINQ 2 SQL however leaves out a lot and raises the question whether there is something left at all. Well, there certainly is. We still have code generation for entity classes (based on tables and views) and for stored procedures and functions.

May web applications are really quite simple in that they are mainly “browsers over a (one) data store”. The complexity of those kind of applications lies more in sophisticated presentation rather than coding the business logic. In this scenario, and to really benefit from the productiveness of LINQ 2 SQL, I have had good experience using LINQ 2 SQL with just two simple tweaks:

• Limited number of result set types (i.e. the set of columns):
  Rather than having my SELECTs (e.g. in stored procedures) produce different projections (i.e. tailored to the particular stored procedures task), I let them produce the same set of columns if they work on the same table. This way I will get a Customer entity and respective instances rather than a CustomerWithAddress, CustomerWithRating, CustomerWithName, CustomerWithAllInfo, … . And if I get that customer, I can always be sure it’s not some half filled entity.
• Explicit result set types:
  It’s quite common to work on JOINed data. LINQ 2 SQL handles this quite well and will figure out the entity type even for stored procedures as “auto-generated type”. In order to make this type explicit in the database I would define a view containing the JOIN and have the stored procedure work against this view. And of course I use the view to generate a respective entity with LINQ 2 SQL. 
• I also refrain from having stored procedures return more than one result set or varying result set types depending on some condition. (I don’t consider this to be a tweak, because I would do that anyway.)

Of course the database may need some tuning, as some of these tweaks may hurt the performance. But optimization when optimization is due… . And while I like the stored procedure approach, those tweaks will also work with free statements in code.

These tweaks are not meant as rules but as guidelines. Feel free to break them at leisure , their intention is merrily to support the LINQ 2 SQL code generation. However… I experienced that the define-your-entities-and-the-operations-on-top approach caused more OO-like thinking than the traditional define-your-operations-and-let-them-return-the-result-at-hand approach.

So, after dragging and dropping the tables, views, and stored procedures LINQ 2 SQL will happily generated the respective classes and methods. Getting type safe data and DB access was never easier.

If you are in the “use CRUD statements to access the database” camp, the usual round trip for an update would be: read the data that is to be changed, change it, submit changes. Like this:

using (MyDataContext dc = new MyDataContext())
{
    var customer = (from c in dc.Customer where c.ID == id select c).First();
    customer.Name = “new name”;
    dc.SubmitChanges();
}

Compared to ADO.NET this still eases db access a lot.

If you follow the “use stored procedures to access the database” approach it gets even simpler:

using (MyDataContext dc = new MyDataContext())
{
    dc.ChangeCustomerName(id, name);
}

This is kind of “anti-sophisticated” but quite efficient. And it allows to do concurrency in stored procedures if you maintain the version field on the client and provide it during the update call. I found this to be much more concise and better suited to the way web applications work.

One word of warning (or rather a disclaimer if you like): This works for me. And it works for a certain kind of web applications. And it only works because I’m willing to trade some academic architectural demands for the KISS principle, productivity, and maintainability. So please don’t follow this advice blindly.

Oh, by the way: I used this approach in a project using an Oracle database as well. Writing a simple code generator that read the system tables and generated wrappers around stored procedures was no rocket science, the only caveat was dealing with REF CURSORs.

The next post will take a closer look at LINQ 2 SQL code generation and how it affects the architecture.

That’s all for now folks,
AJ.NET

Advertisement warning!

I’ve said it in an earlier post: I like working for SDX. In fact my work has become even more challenging due to a changed job description (with the unfortunate side effect that I have less time to spend on this blog). Anyway, we are looking for people (don’t look at the date of the post; if you are reading this in a year the statement will still be true). Well, here’s a short description of my latest project to give you an idea on some of the work we do for our customers…

I just completed a pilot study for one of our major customers, running about 3/4 of a year. Starting point was a system consisting of a non-trivial database and of two VB6/ActiveX/DHTML applications. Initially created a decade ago as replacement for a simple MS Access application, it had grown organically into a multi-purpose-application and a very vital, central data pool for “quite a few” stakeholders.

Since Microsoft has decommissioned VB6, the customer decided to do a VB6-to-.NET migration. My job as responsible architect was designing the target architecture, and coming up with a migration path that supported parallel operations of old and new world during the anticipated two years time the migration would take.

Of course in a decade the world has changed, so has the business and the way software has to be built to honor that. Globalization, European Union, changed customer’s perceptions, constantly changing demands, the way software is built, maintained, and operated.
So the job quickly grew to include a new domain model, adjusted business processes, better business alignment. So far the demands.

The agreed on strategy we came up with is an ecosystem of applications. One core application implements the main parts of a new domain data model, ensures consistency and — essential in any distributed system and surprisingly difficult to achieve at times — provides stable identifiers. Circled around this core application is a number of other mutually independent applications. (The possibility to do this of course relies on the business requirements being mutually independent.)

This approach is driven by

• the separation of the monolith in as many as possible disparate applications (pardon the exaggeration, but it is a fair number),
• defined ways of interaction between these applications (including off-the-shelf-software),
• and providing a sound basis to support building the custom-made family members.

This strategy provides the flexibility to build each application according to demand of specific stakeholders, even allowing for contradicting business demands of different departments. The set of applications can change in the future to address changed needs. Future technology changes can be applied in small steps (lessening the chance that will build the next Moloch). Maintenance should get better, because each application is less complex (simpler architecture, less business functions). And it conforms with Roger Sessions works on complexity of software systems.

Of course, a small but rigid set of rules and governance has to be implemented to ensure peaceful coexistence and avoid “chaotic growth” of our application family in the future. Especially the growth of interdependencies between the applications has to be watched carefully.

Next steps will be applying for the budget at the top management and then hopefully building that system. Of course with my and SDX participation .

Now, if that sounds like a challenging and interesting project; if you happen to be willing to work in the Rhein/Main area, Germany; if you could envision yourself working for the same company as I do … (not necessarily in that project!). Well then pay a look at http://www.sdx-ag.de/jobs.aspx (German language skills mandatory!).

That’s all for now folks,
AJ.SDX

Something is going on out there…

While I still work on LINQ 2 SQL some people started an open discussion, rant, or rail (depending on one’s view and taken offense) about the upcoming Entity Framework.

In all frankness, an “ADO .NET Entity Framework Vote of No Confidence” (VoNC from now on, see here) is certainly capable to triggering off some very strong reactions.

What I disagree with is the way in which it’s presented. The language of “Vote of No Confidence” is intended to start a fight and is long hand for “You suck”. [...]

I’m not upset that people are giving feedback. I want them to give feedback. But here’s the deal – do it in a grown up way. My way or the highway doesn’t sit well with anyone on the receiving end. There’s a WIDE path between being constructively critical and downright offensive.

(Josh Holmes, Ranting and Raving or Getting Results?)

Also quite funny: While the VoNC has probably been popularized by Mary-Jo Foley, she instantly got her … feedback …. from one of the VoNC’s authors:

The signatories list represents leading developers, architects, and practice leads within the Microsoft community. The representation of the signatories as testers is misleading and inaccurate.

We would appreciate an immediate retraction and correction of this misrepresentation.

(Scott Bellware, MVP, see here)

Seems people got a little testy. Anyway, Scott also points out “the history of the feedback and relationship between the community of experts and the Entity Framework team going back to April of 2007″, which raises the question why they still had to publish the VoNC in the first place, despite that relationship.

Given all that, Microsoft’s response was a fine example of “cooling things down” and trying to focus in the facts. Well, essentially Tim more or less tells us that all the VoNC asked for will be kind of there in EF v2.

But already the VoNC is experiencing string headwind. Most is aimed at the, well, call it appearance, of the VoNC and a nice listing can be found here. There is even an “An Open Letter to the ALT.NET Community” (see here).

My opinion?

Thought I would spare you? Silly you

What instantly caught my attention, if just because it was the first point made in the VoNC, was the statement that “entities are more significantly behavioral objects from the perspective of entity-oriented applications” and the claim that this is a “key architectural enabler and distinction”.

Having some experience with EJB those statements vividly reminded me of entity beans. I have expressed my opinion on the notion of “intelligent data objects” (for lack of a better term) more than half a decade ago:

My opinion is that the support of statefull components (i.e. entity beans) in J2EE is one of its biggest weaknesses. Not because it’s technically bad but it leads to wrong architectural design decisions [...]
(microsoft.public.dotnet.general, 4/9/2001, see here)

The reasons for this opinion in 2001 (scalability, reliability, etc.) are still valid. Additionally there are a bunch of other reasons: Trends to lightweight architectures have prospered in Java and even affected .NET (back then, DataSets were the means of choice, today entity classes are very common). The Service notion put emphasis on data shape and operations on that data. Business process engines move data from system to system, shaping and reshaping it along the way. In the distributed, sometimes disconnected world that our enterprise environments have become I could build cases against behavioral objects around security, maintenance, outsourcing scenarios, versioning, testing (which is ironically so favored in the VoNC), software complexity, future safety, and so on.

The VoNC seems to imply that if you don’t have “behavioral objects from the perspective of entity-oriented applications”, then you are stuck with “data objects from the perspective of data storage and data storage technologies” (as I read it more or less simple mappings from database tables to objects). Well, correct me if I’m wrong, but data can be reshaped without putting behavior in it. That’s exactly what I expect from an ORM tool like EF.

I’ll stop before I get carried away. Much to my own relief, I’m not the only one having these reservations, though: Ian noted the similarity with EJB as well and got deeper in this topic. Ward makes a good point on the issues of “Persistence Ignorance” which I share and thus won’t reiterate here.

Where are we?

As I see it, the ongoing discussions are circling around the issue on whether entities should follow the data centric pattern of value objects, or whether they should be complemented with behavior to become business objects. That is largely a matter of taste.

On the other hand, the discussion is somewhat misleading. The topic has got nothing to do with domain models, which in itself is agnostic of those two approaches. And the VoNC’s reference to the anemic domain model (i.e. a domain model based on value objects) only muddies the water. The very verdict that this is an anti-pattern, and a horrific one at that, is due to a judgment by Martin Fowler and only justified by the fact that it violates OO principles (which is obvious) and people think (yes, they do, according to Martin) that value objects are real objects. No wonder the VoNC calls this a “degraded architecture”.

So, two opposing forces, standing in muddied water, and Microsoft caught between them. The PDC is going to be interesting…

BTW: Please note that I never said, Microsoft should not do what the VoNC asks for. There are bright people among the signatories and they should not be ignored. Microsoft as tool vendor should provide a tool than can be used in any architecture.

That’s all for now folks,
AJ.NET

… that functional programming might be the next big shift in general purpose development paradigms.

The other day I realized a trend that may be decisive for the evolution of our development environment in general: Functional Programming! It is not that I did not see the symptoms. It is just that it took that long to realize the breadth of it. (I’m in good company, though.)

Yesterday…

… it started quite unobtrusive.

We got generics and with them (hardly mentioned as more than syntactic sugar) type inference.

In retrospect it even seems misleading that generics were discussed as something akin to C++ templates. The technical differences may seem superfluous at first, yet some advanced techniques with templates, orthogonal libraries such as STL (only recently available as STL/CLR for managed code) and template meta-programming have never been broadly considered for generics. Rather type inference plays a major role with generics, effectively pushing the burden of type safety from developer to compiler.

We got anonymous methods, which was at that time hardly worth the effort and not at all a justified language change — if looked at in isolation.

We got iterators, which was again a feature no one had missed, much less asked for.

Several features, seemingly unrelated, some rather tiny unmotivated additions to the language.

Today (the obvious)…

… we have LINQ.

LINQ has been introduced at the PDC 05 by Anders Hejlsberg et al. as kind of “complied SQL statements”, “type safe SQL”, and “unified query language”, thus the name of course.

The language features that make up LINQ rely on the above language features. And with LINQ those pieces suddenly fall into shape. Type inference for anonymous types and together with generics as general foundation, anonymous methods for lambdas, iterators for deferred execution. A concise system.

And this is how LINQ is seen by many people: Type safe queries. Something to replace ugly ADO.NET code over SQL strings with beautiful and compiler checked C# statements. Who can blame them, that’s how it got introduced.

What those people miss is the less obvious force behind LINQ. It’s functional programming, as Anders itself explains — not the other way round, as presented in “The Evolution Of LINQ And Its Impact On The Design Of C#”.

It’s not that the trend to functional programming is kept secretly. Matter of fact, the term is mentioned quite frequently in relation to LINQ. And there’s other evidence, like the new .NET language F#, incidentally written by Don Syme, the man who built generics for .NET. And there’s enough bloggers out there, talking about the topic.
It’s more that the average corporate developer, the kind that has more than enough to do getting his job done, is not directly exposed to this information. Therefore he picks up only occasional hints at best, not connected, not nearly enough to identify a larger trend. Many of them may not even be aware about the degree to which they have already exposed to functional programming bits and pieces.

Today (the not so obvious)…

… there is a lot of talk around functional programming going on in the blog sphere. Some examples:

Regarding lambdas have a look at Wes’ blog to learn about currying, continuations, monads. Other bloggers have written about other language features (e.g. extension methods). Luca tries to bring F# features to C#.

Also there has been a lot of noise around one of the tenets of functional programming: immutable data types. Just as we got new collection classes with generics, we may get immutable ones sometime in the future.

If you like to read up on immutable data types, Roy has compiled a list of related blog posts; I found Erics series to be the best, as he addresses not only the purpose but also the feasibility (consider the insolence, a list that does not change, how can that be feasible?). And he addresses null values (not exactly part of the functional universe) better than the others.

Another interesting application is MoQ (if not by itself, then as an example for the functional approach), a LINQ based mock framework. It may serve as indication that even stuff that is not directly related to functional programming may come in a functional shape.

Tomorrow…

… — and this is strictly a personal guess — the trend will continue. If anything it will diverge in different areas. Functional programming in general and F# idioms in particular may contribute to our languages, the patterns we use, and the libraries. F# may not only be the first functional language to decisively enter the .NET environment, it may be the very first functional language with at least the potential to become a mainstream language. 

The driving force behind this is something that Anders hinted at it in his interview above, and that Pat Helland pointed out quite clearly at the TechEd: The future is parallel. And functional programming is so much more suited to parallel processing than imperative programming. Matter of fact, Parallel LINQ (PLINQ) is already working in that direction.

Right now…

… that’s enough gazing in the crystal ball. What’s the consequence (provided you share my view)? Today probably nothing. None of my daily work is affected, beyond using LINQ as a nice tool. Tomorrow perhaps still nothing, as I may be totally wrong. All I can recommend is this: Try to see the bigger picture behind LINQ and keep watching for the trend. For if it’s the other way round, you may be tomorrows next VB guy, like the one in the next cubicle that never mastered inheritance and exceptions.

As an afterthought: I’m not aware that this functional programming trend happened somewhere outside the Microsoft space. This is contrary to the dynamic languages trend. And I’m honestly not sure what the implication is.

That’s all for now folks,
AJ.NET