Charles Petzold on coding


Charles Petzold recently delivered a talk at the NYC .Net Developer's Group and he's made it available online here "Does Visual Studio Rot The Mind?".

It's an interesting read, especially if you actually remember writing early Windows GUI applications and building your dialogs in your resource files by hand. I agree with his view that many of the features of Visual Studio are there simply to help us write code faster and that this doesn't, necessarily, result in us writing code better or in code that is clear of fluff and easy to maintain. I commented recently (on a post that I can't find, on a blog that I can't remember) about how application design can be twisted to make it easier for "wizards" to generate the code for you and how this isn't always a good thing... The OLE DB and MFC Wizards were particularly bad in this respect. Still, from what Charles says it seems that XAML and Avalon may start to move things back in the "right" direction...

Via Chris Sells.


Very interesting; thanks for the pointer. I particularly liked this part.

For example, for many years programmers have debated whether it’s best to code in a top-down manner, where you basically start with the overall structure of the program and then eventually code the more detailed routines at the bottom; or, alternatively, the bottom-up approach, where you start with the low-level functions and then proceed upwards. Some languages, such as classical Pascal, basically impose a bottom-up approach, but other languages do not.

Well, the debate is now over. In order to get IntelliSense to work correctly, bottom-up programming is best. IntelliSense wants every class, every method, every property, every field, every method parameter, every local variable properly defined before you refer to it. If that’s not the case, then IntelliSense will try to correct what you’re typing by using something that has been defined, and which is probably just plain wrong.

I think I still have a copy of Petzold's book somewhere. A long time ago, when MFC was just on the horizon, my wife and I both took the same "Windows Programming in C" class at the Harvard extension school. I'm glad I took it before MFC had fully arrived, because I do think that having programmed Windows at that level at least once gives a person a greater appreciation for what's really going on in their program. It also gives one a greater idea of what's really possible if you're willing to step outside the box that MFC or Visual Studio has built for you. I find that programmers who lack this experience often make poor cost/difficulty choices even when all of the code is written using the common tools.

The comments on intellisense are insightful and something I hadn't really thought about but then I tend to turn it off and I still do a lot of my development work in older IDEs...

I have the second edition of Programming Windows by Petzold, the one that targeted Windows 3. Scarily I knew exactly where to look for it as well though that's more to do with my far too organised book shelves than having had cause to use it recent. It seems I also have the the first book in the three book "Programmers Reference Library set" for Windows 3, I seem to remember that I couldn't afford the other two and the first one seemed most important...

I agree that having written GUI code "the hard way" gives immense perspective that some "Wizard Programmers" don't have; but then it's not just GUI programming that benefits from broad and deep knowledge. It was very useful to have done so much DCOM when I started to do CORBA work (though it did cause me to fight the CORBA way for a while, but the fighting led to understanding). Likewise C++ helped with Java which helped with C#... The flip side, of course, is that when you know things can be "better"/different it sometimes means that you find yourself fighting the system a little; I suppose like most things the trick is to know when to go with the flow...

The blog I couldn't remember was Udi Dahan's and the post in question was this one

Leave a comment