Sun, 11/11/01

Many years ago when Java was new, I dove in. My first program I wrote like a C++ programmer and I didn’t get it. Then I rewrote the program as a Java program and it was much nicer, but I still didn’t get it. Then I discovered the lack of deterministic finalization and that’s all she wrote; my C++ thinking turned me away (the fact that Java was ashamed of my favorite platform and, in fact, all platforms didn’t help).

Now I’ve spent the last year doing .NET programming, mostly focused on Managed C++ and I didn’t get it. I’ve participated in DevelopMentor’s ASP.NET and Guerrilla .NET and loved both of them, but still didn’t get it. I rewrote (with my good friend Jon’s help) my entire web site in ASP.NET and didn’t get it. And I spent most of last week preparing for my teach of the latest version of DevelopMentor’s Essential .NET and I *still* didn’t get it. Until today. Today I finally got it. The major power of Java wasn’t that it was platform independent, as Sun so often touts. The power of Java (and therefore the power of .NET) is that it provides a major productivity boost for the programmer. I realized this today for the first time.

It started yesterday. Yesterday I ported a tiny little application (a time client) from MFC and C++ to .NET and C#. The first time I ported it, I ported it like it was still C++ and the result was ugly (I was trying to do the standard library trick of representing time as a the number of seconds since some marker time and then translating it into a formatted string at the last moment). In fact, I couldn’t even do the nice formatting of the current time since .NET didn’t support that means of conversion. But then I remembered that, unlike C++, .NET has proper date, time and span classes. Once I rewrote it in .NET style, it was a thing of beauty. With knowledge of only the name of the sockets namespace (System.Net), I was able to learn .NET and build a time client in under an hour. To paraphrase the closing sentence of one of my first articles, it just makes you want to grab the back the of computer monitor and feel the power of .NET.

Encouraged by my success and armed with the courage of my convictions (and a couple of web sites given me by Jason and Peter), I sat down to write a MSN Instant Messenger application. Those of you unlucky enough to have me as an IM contact saw me log in and log out about a hundred times yesterday (sorry : ). This was because every step of the way, I’d run my client and every step of the way, I’d make more progress. 90% of my code was reading and writing from the sockets and parsing strings. For the former, I used the StreamReader and StreamWriter and for the latter, I used the Regex class. Both did a ton of heavy lifting so I didn’t have to. It was amazing.

But yesterday, I still didn’t get it. I was so focused on getting my IM client working (about a half day’s work) that I completely missed the magnitude of what I was doing. I was implementing an async notification-based socket protocol after reading an example doc, skimming a spec and digging in. And the code I ended up with wasn’t spaghetti. It wasn’t production ready yet (my error handling, while present, was rudimentary) and I didn’t implement the entire spec, but I had refactored along the way and now I have the beginnings of a nice little namespace for doing IM work. And all of this happened the same day that I first discovered the existence of the System.Net namespace. It’s only after reflection (and a good night’s sleep) that I finally get it. The power of  .NET is the programmer productivity.

This productivity comes from a combination of ease of use and flexibility that’s going to attract almost everyone. It will attract the VB programmers because of the continued ease of use and the new functionality of the .NET Foundation Classes. It’s also going to attract the C++ and the Java programmers for the same reason, but they won’t admit that’s why they like it. They’ll claim to love .NET because of the power and flexibility. Not only are the .NET languages themselves allowed to be fully-featured, but the framework itself has tons of amazing functionality built right in. So much so that it’s easy to miss some of it. When I needed to calculate an MD5 hash in my IM client, I went to the net, downloaded some C++ code and built myself a COM object (although I could have easily built a MC++ component, too) and then brought it into my app via interop (see what not being ashamed of the platform can do? : ). That was great, but this morning Peter asked me why I hadn’t just used the MD5 functionality built into .NET. There’s so much stuff in there that I missed it. As a community, we’ll be digging into it for a long time to come.

In the past, I had scoffed at the value of programmer productive over user productivity. My argument was that programmers are soldiers on the field of combat taking bullets and protecting the users at home. This was how I justified the complexity of C++, but measured it against the flexibility of the language and the performance of the produced code, and therefore the pleasure of the user. Don’t get me wrong. We’re still going to be using C++ for high-performance, shrink-wrap software for some time to come. Windows and Office XQ (or whatever they’re going to call them) will still be implemented in C++. Client applications that cannot dictate their deployment environment, i.e. can’t dictate the presence of the .NET runtime, will still be implemented in C++ or VB6. Most of the rest is going to be built in .NET without 12-24 months. Stand-alone corporate applications can dictate the presence of the runtime, as can server-side n-tier applications. Web-based applications can take advantage of the compiled and caching performance gains using ASP-style programming, will still enjoying the flexibility and power of ISAPI-style programming via .NET modules and handlers. Everyone in these spaces that works under Windows is going to be moving to .NET, especially the Windows Java programmers who already know the power of such a platform, but want easy access to their DLLs and their COM servers. The reason that people in these environments can now afford to move is that continued research in virtual machine-style environments and increase in machine power has brought about the first platform where ease of use for the programmer does not mean that the user has to suffer. Applications built with .NET are going to be fast enough and when it comes to ASP, they’re going to be much faster than what we’ve had in the past.

The combination of ease of use for the home-by-5 style programmer and the flexibility for the computers-are-my-life style programmer was so great in Java that tens of thousands flooded the Java conferences from the first year. Mix in a user experience that doesn’t have to suffer from the programmers’ choice of  .NET and I finally get it.

Wednesday, 10/17/01

According to legend, the TA office next to the Stanford computer science lab is guarded by a teddy bear. Before a student is allowed to consume valuable time asking a question of the TA, they must first explain it to the teddy bear. Apparently the bear is able to answer 80% of the questions that students ask, saving time for the TAs to play Unreal Tournament.

I often feel like I act as the teddy bear for the COM community. I get several email messages a day from folks that consider the mailings lists (resources set up to answer just these kinds of questions) to be too slow, so they ask me directly. If I don’t know the answer off of the top of my head, I often respond with the following phrase:

    “Can you send me a tiny, tiny project that reproduces the problem? –Chris”

This, of course, implies that I will actually build and debug the project. And 20% of the time, I do. The other 80% of the time, by the time folks have reduced the problem enough to demonstrate it for me, they’ve already solved it, saving me the time (thank goodness).

Knowing that this is the case, I recommend that you become your own teddy bear. A whiteboard is handy for explaining the problem to yourself and Microsoft development tools are now so handy that you can typically whip out a small reproduction project very quickly. These very activities will often solve the problem, but even if they don’t, you’ve got a concise description of the problem and a small repro case to send to your friends or to post to the list.

Made you look!

(if you don’t know what I’m talking about, check here)

In a recent interview with Barbara Walters, Bill Gates was asked how he felt about Ted Turner’s one billion dollar donation to the United Nation. This is what he had to say:

“Certainly, my giving will be in the same league as Ted’s, and beyond. … During my lifetime, you know, the money will be given away.”

He further went on to say:

“I don’t believe in passing on major wealth to (one’s) children, and therefore everything that I’m earning is going toward the causes that I think can help out.”

So far, Bill has given several hundred million dollars to libraries to provide lower income children with access to PCs and the Internet. Do you have an idea for a charity worthy of Bill’s Money? Post your comments here and I’ll keep track of them for Bill. When he’s ready, he’ll know where to come.

P.S. Just so you know, Bill has never once supported anything from this page and as far as I know, he has no idea this page even exists. Don’t get your hopes up.

September 17th, 2001

Is it imitation or nudity that’s the sincerest form of flattery? Either way, it looks like Robert Scoble is naked outside where the neighbors could see (unlike mine, which was inside and very private : ).

Oct 10, 2001

I’ve updated CorPub to show *all* managed AppDomains by initializing the COR debugging sub-system prior to enumerating them. Thanks to Atif Aziz for the tip.

September 13, 2001

I built the CorPub utility when my friend Jason pointed me at the .NET corpub.idl interfaces (his exact words were “ICorPublishProcess rocks!“). CorPub lists the managed processes on the current machine and the AppDomains in each process, as follows:

Managed process 0xa54: D:\project\mine\RegexPlorer\bin\Debug\RegexPlorer.exe
	AppDomain 0x1: RegexPlorer.exe

Managed process 0xdc8: C:\vs.net\Common7\IDE\devenv.exe
	AppDomain 0x1: DefaultDomain

Managed process 0x1ec: C:\PROGRA~1\MICROS~2.NET\FRAMEW~1\Bin\ildasm.exe
	AppDomain 0x1: DefaultDomain

It’s fun for spelunking. Enjoy.

NOTE: .NET beta 2 is required to run this utility.

September 11th, 2001

The World Trade Center and the Pentagon were attacked today when hi-jacked commercial airlines crashed into them, destroying both of the towers and damaging the Pentagon. I can’t possibly know what the people who had friends and families in those buildings are going through right now, but my thoughts and prayers are with them. If there’s anything you can do today or in the coming weeks or months to help those people to recover from their loss, please put aside your computers and your work and do it. I will be doing the same. Thank you.

If you’re interested, both Amazon.com and PayPay.com have set up disaster relief donation funds. 100% of all donations go directly to the American Red Cross.

August 23rd, 2001

Q: D.J. Stachniak writes:

I missed the Conference.NET, but I’ve been reading through the PowerPoint presentations posted on DevelopMentor’s web site. I noticed in the C++ In A Managed World presentation that there is a slide (page 62 specifically) which says ”.NET supports real inheritance across languages - Although, that doesn’t mean you should use it…”

Would anyone like to take a crack and explain to me why cross language inheritance might be bad?

A: Chris responds:

At the Microsoft PDC in 1993 (also known as the “COM PDC”), Kraig B. introduced COM by saying that it didn’t have inheritance, but that was a good thing, because of the fragile base class problem. This problem says that derived objects, by definition, need to have incestuous knowledge of their base classes, including full understanding of the implied contract (which often requires to source to determine). What made this relationship fragile was that reliance on the implied contract caused all kinds of trouble when it changed, implying that it was knowledge of the source that caused this problem.

Of course, that’s not the case. We often experiment with components that we don’t have the source for and made decisions based on implied contracts that can easily change version to version. I would call this the “fragile use” problem, but it’s more commonly called “DLL Hell.” The idea that components can be replaced in the field without breaking things has long been known as a fallacy, and it doesn’t matter if you’ve got the source or whether you’re doing inheritance, aggregation or mere creation.

Eiffel’s Design by Contract is a good step towards detecting problems, but that’s an Eiffel-only thing. A good step towards reducing DLL Hell is the aggressive versioning and side-by-side installation of multiple versions that  .NET supports. If your client or derived class binds to a specific version of a component, then there’s no need to worry about it changing out from under you. Lack of source makes it harder to derive than to merely use, but assuming you can make things work empirically, cross-language inheritance might actually work in .NET (but don’t hold me to that : ).