Tools will make or break the platform

I’m quite particular, even protective, about my development tools. Microsoft’s Visual Studio 6 is the only integrated development environment that came out of the box matching the way I think and work. I bonded with VS6 so well that I used it to code for other platforms.

When Visual Studio .Net appeared, I felt betrayed. Not only did it bind me to Windows, it tried to force me to design and develop according to Microsoft’s best practices. I have my own

best practices, thank you. I don’t need tools that get in my way by shaping my approach to development. And I certainly don’t need tools that make every language feel like Visual Basic. Opacity and abstraction, sold as the panacea for complex code, only get in the way if you know what you’re doing.

My failure to appreciate Visual Studio .Net is not .Net’s fault. Rather, the strong concepts and deft execution of .Net were buried under tools that demanded that programmers design and code Microsoft’s way. Even the best part of Visual Studio .Net, the C# language, had a serious downside. Microsoft was so enamored of .Net that it assumed C++ and Java programmers would flock to C#. Visual C++, once Microsoft’s crown jewel, was stuffed into the trunk when .Net took the wheel. And that is at the heart of it.

I never bought into the Java argument, later the C# argument, that C++ is so arcane and dangerous that it has to be replaced. If Visual Studio .Net were your first brush with C++, you would leap into Sun’s arms and say, “By golly, you’re right -- C++ is a horrible language!” It’s not the language. It’s the environment. If a C++ programmer can’t get a helpful, intelligent, and permissive development environment such as VS6, he or she will happily go back to the command line. Going back may mean, as it did for me, walking away from developing for Windows.

Microsoft has a shot at redemption. If Visual Studio Whidbey stays on the path that was shown at the Microsoft Professional Developer’s Conference, I could get excited about writing Windows-client code again. It helps that the Visual C++ demo was presented by a Microsoft guy who has the same thorn in his shoe that I do. He didn’t bother dancing around Microsoft’s neglect of serious developers. I also saw program-manager-level slides about C# and Visual Basic. But no one rivaled the table-pounding evangelism of the Visual C++ leader. Were it not for the necessity to maintain a journalist’s cool and distant demeanor, I would have stood on my chair and proclaimed “Amen!”

I was similarly moved by a demo at Apple just a couple of weeks earlier. There, I saw a beautiful demo of Xcode. Compared to Whidbey, Xcode has the advantage of shipping now. It’s also free and bundled with every copy of OS X 10.3 (Panther). My Xcode demo was handled by an Apple manager who crowed about the company’s new commitment to C++, which is quite apparent in the tools.

There is plenty of time for the technical details. The point here is that developers have an emotional investment in their tools. Pundits can rave all they like about whether this should be the case. But ever since we started using computers to help write software, tools have made the difference between platforms that make it and platforms that are relegated to the dustbin.