I'm really undecided about the Vista start menu... since I've started using Vista, I've had several different approaches for running applications:

1. Some applications run automatically when I log on to Windows
2. Some applications I run manually after most logins, like e.g. Outlook. I have icons for those in the Quick Launch toolbar.
3. I use SlickRun to run those applications I use most regularly, but which are not running all the time. The Quick Launch toolbar also has icons for some other things that I run occasionally - often enough so I want to have the accessible, but seldom enough to make me think I'm going to forget the name of a SlickRun command if I were to create one for them.
4. I use the Start Menu with its Search functionality to run things that I use rarely.

I see how this doesn't seem like an intuitive system, but it actually is for me.

Now, the Start Menu on Vista is really weird... it has this nice Search feature, which is very useful, but occasionally I can't remember what the name of some item is, so I actually expand "All Programs" - and that's where things start to go wrong. The Start Menu is so horribly slow that it's practically unusable - it sometimes takes 20 seconds or so to expand a folder in the All Programs list. Why? No idea. I've been noticing the same thing on a previous Vista installation on a different machine, so it doesn't seem to be related to my installation. It certainly has to do with the number of applications installed, but then the old Start Menu always coped with that just fine and certainly my 160GB laptop hdd can't be home to the Vista installation with the largest number of installed apps in the world, can it?

Another thing is that even with SP1 installed, working in the Start Menu is something that sometimes crashes Explorer. Again, no idea why - it happens either when clicking around in the All Programs hierarchy, or when entering a Search term and looking through the result list. It almost seems that it's most related to the duration I have the Start Menu open, since I don't think it happens when I just open it, quickly select something and close it again.

I tried switching back to the Classic Start Menu, which has a nice effect on performance the list of installed apps fills the entire screen, but at least it comes up within 2 seconds or so. But the Classic Start Menu doesn't have any features, not even those it should have according to the Options dialog - apparently it's supposed to "store and display a list of recently opened programs", but it doesn't. It also doesn't show top-level Administrative Tools, Computer or Network entries and it doesn't support Search.

As a result, both Start Menu implementations are really unusable, though for totally different reasons. Why don't they ever get it right?

I know there are other launcher applications out there (apart from SlickRun), but I've found those lacking in simple ways - I don't want such an app to take up a lot of memory if it's going to be running all the time, and the command features that SlickRun has are really the absolute minimum of what I need. OTOH, SlickRun doesn't support working with the Start Menu content, which seems like a pretty useful and simple idea. Perhaps some other tools do? If I ever find time, this would be something to look into. If you know something I don't, please comment and tell me!

Thanks to everybody who attended my session at DevWeek! I hope you liked it, I certainly had a lot of fun doing it.

First of all, here's the download of slides and samples from the session: Functional Programming in C# 3.0 (718950 bytes)

Second, I've had a little thought about that example I was asked about during the session. It was one of the methods in the first basic example, and it looks like this:

public static IEnumerable GetAllMembersFunctional( ) {
  return AppDomain.CurrentDomain.GetAssemblies( ).SelectMany(
    assembly => assembly.GetTypes( ).SelectMany(
      type => type.GetMembers( )));
}

The question about it is whether this is a "real" functional implementation of the functionality or not, given that GetAssemblies returns information that changes dynamically outside my own function. I first pointed out in the session that the example was of course about the implementation of the method, not necessarily about whether or not you would want to implement a function that does precisely this same thing, especially if you subscribe to the "pure" theory of functional programming.

The more important thing about this came to my mind a bit later, but it depends a little bit on perspective. From the perspective of the guy who implements this method, I could say "Of course this is entirely valid - I'm simply calling other functions to return information to me (even though those functions don't take parameters, so perhaps the source of the data is just a little suspect). I'm not the one who makes the decision to actually retrieve the information from what might be considered unreliable shared storage." On the other hand, the function in question (GetAssemblies) is a function from my "runtime libraries", in the form of the .NET framework, and it could equally well be said that I have to be aware of the nature of such functions and whether or not they do something I don't want to do, and perhaps make the decision not to use them.

In the end it all comes down to discipline again. Modern functional programming, especially when applied to real world problems, is rarely "pure". There's sometimes a necessity to deal with shared data and external state to solve real-world problems. Modern functional languages recognize that and provide the means to do it, thereby removing restrictions and pushing the problem back into the area of discipline. There are small steps being taken to remind you of that choice you made, like the fact that you need special keywords in F# to create mutable variables. But if it's your choice to try to live without shared state, it's also your responsibility to adhere to that choice as much as you can, and decide sensibly about situations where you can't.

So here they are, the slides and samples of that Functional Programming in C# 3.0 session. My apologies for the slight delay - I already received a few emails about it - but my flight home was cancelled yesterday and everything was a bit chaotic.

Functional Programming in C# 3.0 (718950 bytes)

Have fun!