Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

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

Download

Right click “Save as…”

"We built for the future," Anders says. It wasn't an easy road that brought us to .NET, though. Listen in as Anders explains how .NET was born (and how it differs from COM).

Tag:

Follow the Discussion

  • 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.

  • KnightOfNIKnightOfNI Ni Ni Ni
    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++.... Smiley


    NI!
  • BrockyBrocky Yes its realy me
    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...


  • HE3HE3 oh.
    Anyone else...
    The first thing I saw was the big word "*" in the image.
  • phunky_avocadophunky_avoc​ado Dude! It's the (grilled) cheese.
    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.
  • billhbillh call -141
    HE3 wrote:
    Anyone else...
    The first thing I saw was the big word "*" in the image.


    Above that it looks like the word "potent"...
  • KnightOfNIKnightOfNI Ni Ni Ni

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

  • CharlesCharles Welcome Change
    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.


    Glad to hear this. I agree that it is just SO nice to be able to spend most of the time thinking about and implementing algorithms and not spending much time figuring out how to clean up their mess.

    I love what the CLR has enabled.


    Keep on posting,

    Charles
  • amotifamotif No Silver Bullet
    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. Smiley

  • 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 Smiley

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

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

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.