[Sorry about the blogging gap - nothing dramatic, just a little case of overworked and underslept. Good excuse to start up again though.]

Imagine a room with a table, no computers, and four really smart people who care tremendously about helping people write software, and who tackle questions like "what keywords should be in this language" every day -- and whose decisions actually will get implemented. A full hour of amazing conversation appeared recently on Channel 9.

How will imperative programming languages evolve to suit the needs of developers in the age of Concurrency and Composability? What role can programming languages play in enabling true composability? What are the implications of LINQ on the furture of managed (CLS-based) and unmanaged(C++) languages? How will our imperative languages (static) become more functional (dynamic) in nature while preserving their static "experience" for developers? 

Answers to these questions and much more are to be found in this interview with some of Microsoft's leading language designers and programming thought leaders: Anders Hejlsberg, Technical Fellow and Chief Architect of C#, Herb Sutter, Architect in the C++ language design group, Erik Meijer, Architect in both VB.Net and C# language design and programming language guru, and Brian Beckman, physicist and programming language architect working on VB.Net.

This is a great conversation with some of the industry's most influential programming language designers. Tune in. You may be surprised by what you learn...

Some quotes and paraphrases that caught my attention:

• "No language can ignore concurrency and stay successful for mainstream programming over the next five, ten years."
• our entire industry is based on composable software and we manage to do composable software with the languages, libraries and frameworks we have now. it's rather amazing that we can do it.
• "all you can do as a language designer is slow down the accrual of new features that will eventually lead to cave in."

Now if you aren't sure you know what a lambda expression is, or what makes a language functional as opposed to imperative, or what LINQ would have to do with that, or what composability is, then you may think you don't want to watch this video. But you'd be wrong! Spend this hour with these gentlemen and not only will you learn all those things, you'll learn why it affects you and why you should be following, at least a little bit, the current work in this area.

Watch it!

Kate

A lot of people are asking me if I am using Vista, if they should use Vista, if I think Vista will get good adoption, and so on. I have Vista on some machines, still have XP on my ancient primary laptop, and miss Vista when I'm not using it. I tell people this and they assume it's all about the shiny and the seethrough and the pretty. It's really not. For me the fast search is a big thing. And I still consider UAC a feature and have no intention of turning it off or launching everything I do from an elevated command prompt. I like the thumbnails that actually show your content - though I suppose some might dismiss that as "pretty", it's saved me from opening big files with odd names more than once, just so I can tell whether I want to delete them or not. An MSDN article lists a number of useful benefits of running on Vista that have nothing to do with being pretty. Beyond UAC and other security benefits, consider Sleep (fast as Standby, safe as Hibernate), SuperFetch, ReadyBoost, restart manager, presentation mode, ... there's so much! It's not just about the .NET Framework 3.0 -- you can have that downlevel. It really is a new version of the operating system and it does a lot of things a lot better.

So I forgive it for being pretty.

Kate

I once had an opportunity to write one of those Teach Yourself <Something complicated> in 21 Days books, or it might have been 24 Hours, or A Weekend, I forget. I was overloaded with work at the time and didn't write it. One of the things about writing those books is that nobody actually expects the reader to learn what they need in 21 days or 24 hours or whatever. It's basically the number of chapters. And if you processed one chapter a day, I guess you would cover the book in three weeks, but you wouldn't be a <Something complicated> programmer at the end of that, would you? Some folks might do 5 chapters a day, others might do a chapter a week. It depends on where you're starting from.

I came across a few interesting blog posts on this topic. Peter Norvig found hundreds of such books on programming languages or frameworks, and proposes instead Teach Yourself Programming in Ten Years. He has a point. Jasmine refines the point a bit, saying that if you're already a good developer you probably can pick up a new language or framework in a matter of days, and that if you don't have what it takes to be a good developer, ten years of plugging away at it won't make you good enough.

I've been getting paid to program since 1979, and I learn new things all the time. But I try to learn new languages no more than once a year -- and I wouldn't be able to invest 21 days in learning a language, either. More importantly, I've invested quite a lot of time and effort into spotting those who will be good developers some day, and trying to speed the process of making them better. I think the emphasis on debugging and on reading or fixing the code of others is appropriate. It's tempting to have the newbies work on little projects alone since they can't understand your big complicated project with difficult code written by the really smart people. But trying to understand that project and that code is what will make that newbie a developer -- or show you both that it's a hopeless cause .

Kate

I do my searching these days at www.live.com -- the ads are less obtrusive or easier to ignore or something and on the occasions I've done the same search in two places, I like my Live results better. But for the next little while I'm going to use a slightly more complicated URL: http://click4thecause.live.com/Search/Charity/Default.aspx?locale=en-us&source=msnhp. I know, that's a mouthful, but here's the thing - it searches the same, but it also donates to charity. Really! I know we've all seen those "if you forward this to 40 people Microsoft will know and they will give money to charity" emails, but this is different. After all, counting web hits is something that can really be done.

Education and sports programs for refugee youth around the world? Sounds like a good cause to me. Check it out, and make it your new search page, won't you?

Kate

Rory interviews Kam VedBrat about glass, composition, DWM, and other ways to stray from the gray-buttons-and-white-textboxes-on-a-big-gray-background that is the UI most devs naturally create. Watch it!

Kate

Try this. Open up Visual Studio and make yourself an MFC app. It doesn't really matter what kind of application it is - a dialog app is probably the quickest to create but you could use some more complex MFC app that you happened to have lying around if you preferred. Build the app and run it to prove to yourself that it's fine.

Now bring up the project properties, and under Configuration Properties, General set Common Language Runtime Support to Pure MSIL Common Language Runtime Support.

Click OK and build the application. Blam! Errors everywhere. My little nothing dialog application got 18 and they all look like this:

What does this mean? Well, every function has a calling convention. These include __stdcall, __clrcall, __cdecl, and so on. Many of the functions in the MFC libraries (look at the include files for which these errors occur) are declared to be __stdcall, meaning that they are common-or-garden native C++ functions. But when you compile your application /clr:pure, you are saying "I don't have any common-or-garden native C++ functions in here. Everything is managed."

Since you can't change MFC, you have to change your compiler options. Change the CLR support to just "Common Language Runtime Support (/clr)" and build again. All the errors go away.

Kate

Thottam R. Sriram has an article in the January MSDN Magazine called CLR Inside Out: Introduction to COM Interop. As the introduction says:

COM is a wonderful technology. One aspect of the common language runtime (CLR) that makes it an extremely powerful platform is that it allows seamless interactions between Microsoft® .NET applications and unmanaged COM components. However, when I searched the Web, I found few working samples demonstrating the very basic concepts of COM interop. The purpose of this column is to illustrate those basic concepts in order to provide solid working examples that can jump-start users in this technology.

I'll start off with a simple Active Template Library (ATL) COM server and try accessing methods in this server using an unmanaged COM client, then do the same thing with a managed client. I'll walk through the various DLLs to illustrate the translation from unmanaged to managed, and I'll show how to access an exported method in an unmanaged DLL using P/Invoke. The toughest part of this is to figure out marshaling of complex structures, which I don't cover exhaustively in this column-it would be a complete column (or book) on its own. I'll show you how unmanaged code can call back into managed code using interfaces. (You could do this with delegates as well, but I won't cover that in this column.)

Finally, I'll discuss debugging your COM interop project using public symbols. This will give you very basic introduction to WinDbg.exe, unmanaged debugging, and managed debugging using SOS. I'll demonstrate the stack from managed to unmanaged as calls are made in either direction.

The managed client is in C# -- when you write your clients in C++/CLI you don't have to figure out how to declare and marshal complex structures, after all. And seeing how to call back from native code to managed code is helpful indeed. I'm not sure if Reverse P/Invoke is the official name for this, but it works for me. You set up an interface in your C# code and decorate it with attributes for COM. Then you implement that interface in your code and use tlbexp to make a COM Callable Wrapper around your .NET object. Then you hand-define the same interface as a COM interface in your native code and you're all set. The .NET code can P/Invoke some native function and pass in a reference to the .NET interface. By the time it's unmarshaled over in the native world, it's become a smart pointer to that COM interface and you can invoke the method from the native code. It's a little tricky, but it's not hard - once you've seen it done.

Since the article wraps up by touching on Windbg, there's something for everyone. Check it out!

Kate

I read an interesting blog entry at Dumb Little Man. Essentially, the story goes like this. A guy is fed up with his job, doesn't like it, is ready to quit. Instead he throws himself whole-heartedly into it and gives it his all. He does the tasks he dislikes, he does tasks he isn't asked to do, he speaks up and speaks out, and he becomes so much happier in the job. And if that wasn't enough, he gets a two-layer promotion and a $15,000 a year raise.

His list may not precisely work for you. You may not be asked to do TPS reports, whatever they are. You may live a life like mine where no one can give you a promotion. You may not think that working long hours is important to success at your company, or worth what you have to give up in your private life. But look past the details of his particular list. What would happen if you totally threw yourself into what you are doing now and really really did it?

Kate

Here's another reason to install Visual Studio SP1 - it fixes one class of "intellisense stops working" problems. Intellisense stops working a lot for C++ developers. It doesn't happen very often for me, but people mention it quite often when I speak and some of my coworkers are less lucky than I am because it happens in their day to day work.

If Intellisense stops working for you and you're working on a C++ project, the workaround is to close Visual Studio, find and delete the .ncb file, and re-open Visual Studio. As you can imagine, that cuts into flow quite a bit. Now a KB article mentions that SP 1 fixes "In a Microsoft Visual C++ 2005-based solution that includes multiple projects, the IntelliSense of a project does not work correctly if the project references types from another Visual C++ or Visual C# project." Cool!

Kate