On April 13th, during Microsoft’s inaugural UK TechDays event, I’ll be speaking for the Edge UG at the main Fulham Broadway venue. This is part of what Microsoft call the Fringe events, community hosted events that complement the main Developer and IT Pro days.
I will be speaking about functional programming on the .NET platform, using both the C# and the F# languages. Here’s the abstract for this talk:
F# is a new language in Visual Studio 2010, a hybrid that crosses over from the well-known object oriented .NET world into that of functional programming. It makes parallel programming easier, they say - and it does, in addition to all the other cool language structures it offers. But the idea of functional programming doesn’t depend on the language alone, and good old C# can be used to implement many of the same ideas. In this presentation, Oliver gives an overview of functional aspects in both languages, explaining F# as he goes along and conjuring up much mind-bending syntax in C#. Don’t miss it!
To sign up for the event, just go to the Edge UG homepage. See you there!
Last week I was down in London and spoke at DevWeek 2010. As usual, it was a great conference! Thanks to everybody who attended my talks!
I promised to put up my slides and samples – my apologies, it didn’t work out earlier. Here’s everything you need:
Post-con Workshop: Functional Programming in C# Deep Dive
I just twittered a few minutes ago, saying “Seems like VS 2010 can still not show the same file twice in panels next to one another. Am I missing something?". I’m still interested in the answer, if there is one, but meanwhile I thought I’d blog about something I’ve found interesting for a long time: the way our heads seem to work differently when it comes to applications of the words “horizontally” and “vertically".
You see, in Visual Studio (and that has been the same thing with MDI windows before that), they have a thing called a “Tab Group", which comes in horizontal and vertical varieties. These days the difference is illustrated in little icons at least, defining it like this:
Horizontal group (exhibit A):
+--------------------+ | | +--------------------+ | | +--------------------+
Vertical group (exhibit B ):
+-------+-------+ | | | | | | | | | | | | | | | | | | +-------+-------+
Now here’s my gripe with that: it’s the wrong way round!
In my eyes, exhibit A might be described as “a tab group with a horizontal splitter", but it is not a horizontal tab group. These things are not the same. A horizontal tab group is one where the tabs, the defining feature of a tab group, surely, are shown “horizontally", i.e. next to each other in horizontal direction. Just like exhibit B, in fact. And vice versa, of course.
I don’t know what somebody was thinking when they came up with those names, or maybe it’s just my head that works differently. It doesn’t make sense to me, in any case. And that’s the important point of this post: if you never realized that these terms might be confusing to somebody, here you are now!
One important factor in successful communication is about understanding misunderstanding – which is why, in my tweet, I was avoiding the terms “horizontal” and “vertical” as being confusing in the context. Of course the first and so far only reply I got to my tweet (and I’m not naming any names here <g> ) went “hey, do you mean vertically?” Hmpf.
Oh, and yes, according to the MS definition I mean vertically, yes. A tab group with a vertical splitter, that has been split in vertical direction, or whatever. A tab group with the tabs showing horizontally next to one another. And the same file on both sides of the splitter. Not possible, is it?
I have a solution with several projects that I currently work on in VS 2008. I would like to use VS 2010 for it instead, to benefit from new debugger features etc… but it should remain on the .NET 3.5 platform, and I would also like to keep things compatible so the solution can be opened and built in VS 2008 later on, if necessary.
I’m sure I haven’t looked at everything yet, and perhaps there will be issues down the line. But it certainly seems that this is pretty simple. Of course, right when you open such a solution in VS 2010, it doesn’t look simple at all: the import wizard comes up and wants to convert your projects. After you’ve done that, VS 2008 won’t open your solution anymore. Hm… so Microsoft doesn’t want you to do this?
Looking at the project (.csproj) files, quite a lot of changes have been made. The version number has been increased, but there’s also lots of new stuff included in the various sections of the file. That looks difficult. The solution (.sln) file on the other hand has only one change made, which is the version number. Now guess which of the two is the one that causes the problem? Wrong.
The problem is in fact the solution file. Although it’s only the version number that has changed, that number is evidently used to prevent opening the solution in an older VS version. Fair enough – until you find out that it is perfectly possible, and apparently even safe, to open the vastly more complex project files in an older VS version. Go figure.
So, the solution I went for is simple: I moved aside the modified .sln file and reverted the old one from svn. Now I have two different .sln files, one for VS 2008 and one for VS 2010. Both include the same projects, and these are in the VS 2010 format. Nevertheless, they work in both versions of VS without a hitch.
There’s one complaint during the build process in VS 2008, which is about the ToolsVersion – this is a parameter in the project file, which has been set to 4.0 by the conversion wizard. Fortunately, msbuild reverts to 3.5 automatically, so there’s no damage done and the build still works just fine. Other than that, I haven’t found any problems yet. I even tried to change project settings in VS 2008, and this leaves the versions intact even though 2008 must be a bit surprised to see 4.0 in there… again, go figure.
I just blogged about this problem I was having with Gallio/MbUnit. I don’t regard the issue as fixed, but I’ve certainly worked around it.
I found that the delay happened when the tool Gallio.Utility.exe was being run during the startup process of Icarus. I noticed that the same thing happened when I tried to run other included tools like the control panel, and it also happened when using TestDriven to run an MbUnit test from VS. I had the impression that the tool was being run multiple times, but that turned out to be a mistake – the tool was simply running for a rather long time, jumping up and down a bit in the task manager list. I finally ran the tool on its own and found that (a) it has something to do with the plugins that Gallio apparently uses (for purposes unclear to me, I have to admit) and (b) even to just run the tool and display the usage info message in a console, it takes 25 seconds or so.
So, simple solutions are sometimes the best: I deleted Gallio.Utility.exe. Next run of Icarus, it was restored. Okay, MSI is more cleverer than I. Or so it thinks – I went and configured the file access permissions on the file and removed all access permissions. Hah, take that, MSI. Next run, Icarus comes up within about 3 seconds, taking another 2-3 to load my test assembly. Hah!
Running a test through TestDriven from VS takes about 3.9 seconds now, so it’s at least 2 times slower compared to running the same test through the CodeRush test runner. Weird, but then who am I to complain.
Now, could somebody please fix that Utility program before I end up needing it for something?