Anders Hejlsberg - What brought about the birth of the CLR?

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

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

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. 

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.

I´m not all that mad at COM but, it's like he said...Its time to move up...

Let's focus on the Creative Work.....


PS: we can allways forget that and have a good time playing with C++....


NI!

maybe its just because
how we used it here in our company.
But with Com we always had the problem
when we had a Com Server and a client

You always had to clear shut down the client
in order to get the connection again running when the client restartet and connected again to the server.

Very often we had to manually shut down the serve and or client with the taskmanager...

Anyone else...
The first thing I saw was the big word "*" in the image.

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.

HE3 wrote:

Anyone else...
The first thing I saw was the big word "*" in the image.

Above that it looks like the word "potent"...

Don't forget.... "Your"...

sparky wrote:

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

Anders' explanation that COM wasn't suitable for building code inside an application made a lot of sense to me... /snip/

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.

Doesn't sound all that good when a microsoft engineer tells us that moore's law will make up the speed difference of .net in a year! What about the rest of the world still on older computers and havn't upgraded to 3 Ghz pentium 4's.

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

It would make me really happy if Anders was still playing with Delphi!

http://www.blong.com/images/Eggs/Delphi1d.gif