Chris Anderson - Why release Longhorn/Avalon so early?

I'd have to say that's it's nice to hear why they moved away from COM and into .NET and to hear them talk about how awful COM is to many programmers who must use it because that is all that there is.
How bad was COM? Many of us, myself included have only heard from others why COM was so ugly. Is COM really that bad, or did you guys just decide to start from scratch because it was time to re-architect
Anders' explanation that COM wasn't suitable for building code inside an application made a lot of sense to me - I struggled with that fact on many occasions.Stepaniuk wrote:
How bad was COM? Many of us, myself included have only heard from others why COM was so ugly. Is COM really that bad, or did you guys just decide to start from scratch because it was time to re-architect
For example, I can't even begin to count the number of times I wrote IEnumVARIANT wrappers around std::vector, std::set, etc. It is a lot easier to cast ArrayList to ICollection and be done with it.
Another one that always got on my nerves was that you couldn't use smart pointers to refer to a class - only an interface. No problem, just put all of your class stuff in an interface? Well, then you're limited by the expressiveness of IDL, which wasn't even close that that of C++.
I'm very happy with .NET's way of doing events with delegates. I wish I could re-claim the part of my brain that holds the many subtleties of COM's IConnectionPoint, IConnectionPointContainer, etc.
HRESULT's were another pain. In C++, you had exceptions, you could put any sort of information you wanted in them, it was great. But as soon as you crossed apartments, processes, or even interfaces if you're a purist, you had to drop all of that rich error info in exchange for a single 32-bit number (32 is being generous, you really only had about 16 for your own purposes). Of course there was IErrorInfo, and ATL helped out where it could, but at its best, HRESULT was an abysmal failure compared with System.Exception.
Another annoyance I had with COM was marshalling. I have a lot of respect for RPC's marshalling capabilities, but dealing with oleautomation interfaces was torture - always having to talk down to the lowest common denominator (scripting languages). I guess in .NET, we have the CLS, so it's a similar situation, but at least you don't have to write custom marshallers to get any real work done.
And, there was always the separation of COM from the Win32 API. COM was a decent, usually good-enough object model, but as soon as you wanted to talk to the operating system, it was back to good ol' DLL imports. .NET's coverage of Win32 isn't complete, but imagine how much more painful it would be if there were no Framework, and you had to write a P/Invoke to do file i/o.
If someone had shown this single video to me years ago, I'd have jumped on the .NET bandwagon a lot sooner.
HE3 wrote:Anyone else...
The first thing I saw was the big word "*" in the image.
Don't forget.... "Your"...
phunky_avocado wrote:I sure hope COM goes the way of the dodo. COM programming was masochistic and C++ programming is just plain annoying (yet desirable under some circumstances). .NET makes writing software fun again.
sparky wrote:Anders' explanation that COM wasn't suitable for building code inside an application made a lot of sense to me... /snip/
Stepaniuk wrote:
How bad was COM? Many of us, myself included have only heard from others why COM was so ugly. Is COM really that bad, or did you guys just decide to start from scratch because it was time to re-architect
Nice synopsis. COM had a difficult learning curve, for many of the reasons you mention. I have spent too much time debugging COM code, and too much of that was written by developers who didn’t know better. The.NET CLR is leaps and bounds ahead with respect to allowing one to simply write application code and reuse components.
The most common idiom I have used to track down issues in production COM code was to narrow the scope down to a particular component, print out a couple of its source files and do a thorough code review. This generally revealed the source of the problem as well as another two or three lurking in the code, all generally simple COM mistakes. I don’t know why, but it’s difficult for a lot of folks to grok COM well enough to write good COM code—or at least code that doesn’t mess up the reference count.
That said, COM *is* part of Windows and is still necessary for some purposes. I look forward to writing some more COM code in the next couple of weeks.
I actually never really used COM objects, because they were simply not usable in my Delphi applications I wrote at the time.
Now I use C# to develop all my applications and it made it possible to build applications far greater than I had imagined before. (Well, ok... I did a study computer science too...)
But those stupid things like cleaning up pointers and memory aren't really a good job to do for a developer like me