My History of Visual Studio (Part 7)
[All the other Parts: History of Visual Studio]
[I know I promised to talk about “Whidbey” in this installment but I realized I needed a bridge to get there or else I’d totally skip over “Everett” – so this is that bridge.]
In MSN the arrival of the .NET Framework and Visual Studio .NET was like a breath of fresh air. My team was working on (among other things) a COM based object model for a content management system. I once estimated that fully half the code was associated with the implementation of IUnknown in direct or aggregated cases (let’s hear it for punkOuter) or else tricky ref count management – to say nothing of the similar code that was in every client.
Using the old code as a reference, just one developer was able to re-implement the entirety of the interfaces – save one class which we chose to wrap with COM interop instead – in about 3 months. While it’s true that I have a high opinion of her (you know who you are) I think this was a great example of the .NET Framework shining in its strong areas.
The resulting libraries integrated seamlessly with ASP.NET (naturally) and were maybe ¼ the size with superior performance. One should never discount the cost of all those interlocked increments in COM objects and all the small allocations and long term fragmentation.
Fragmentation, or rather lack of it, was another key benefit we got from the .NET stack in that time frame. Until then it had been the bane of our existence, with 72 hour tests frequently showing performance degrading over time – we found that we got 5x the speed of regular ASP and stable performance over time.
We had other systems, formerly written in Perl that we were again able to rewrite in C# in a fraction of the time. A key benefit was the strong UNICODE support that .NET offered – we just weren’t getting what we needed out of the Perl implementations we had, to say nothing of the threading benefits. Debugging it was a dream compared to the old world.
In less than 6 months we had an all new data pump and all new managed content management system both scalable and more reliable than either of the previous systems. Life was good.
So I decided I should give up on MSN and go work on the CLR; I don’t think they ever forgave me. :)
By the time I joined the CLR, fall of 2002, their work on “Everett” (aka Visual Studio .NET and .NET Framework 1.1) was nearly done, it didn’t release until the spring but things were winding down there and so I started working on “Whidbey” almost right away, but I don’t want to just gloss over Everett because some important stuff happened.
C++ is a moving target, I guess all non-dead languages share that property but perhaps C++ is a lot more robust in this regard than many other modern languages, as a result there is almost always standards-catch-up work a compiler team should be doing. In this case it was around partial templates – this stuff makes my brain hurt – but I guess it should hurt: C++ templates are Turing Complete. Frankly I was amazed by what the C++ team had managed to accomplish in the time they had, the needs of managed C++ and IJW (It Just Works) managed support.
But there was a lot more in “Everett” despite the fact that it was supposed to be a minor update. For instance, Everett introduced support for managed code on mobile devices. I can’t believe I’m saying that like you just push the “go mobile” button on .NET and out pops .NET CF and all the compilers, debuggers, emulators, and deployment tools just like that. I think they made it look too easy.
Everett also introduced the Enterprise Architect version with the first UML support in our systems, maybe foreshadowing VSTS. Designers were definitely here to stay.
But truthfully I can’t say very much about “Everett” because I was desperately trying to learn about the runtime and getting ready for “Whidbey”. Meanwhile “managed code mania” was at its zenith at Microsoft; sometimes it seemed like every product was trying to find a way to incorporate the .NET Framework into their plans.
[See The Documentary on Channel 9!]