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

Download this episode

Download Video

Description

"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:

CLR

Embed

Format

Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • User profile image
      Stepaniuk

      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

    • User profile image
      sparky

      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.

    • User profile image
      KnightOfNI
      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!
    • User profile image
      Brocky
      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...


    • User profile image
      HE3
      Anyone else...
      The first thing I saw was the big word "*" in the image.
    • User profile image
      phunky_avoc​ado
      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.
    • User profile image
      billh
      HE3 wrote:
      Anyone else...
      The first thing I saw was the big word "*" in the image.


      Above that it looks like the word "potent"...
    • User profile image
      KnightOfNI

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

    • User profile image
      Charles
      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
    • User profile image
      amotif
      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

    • User profile image
      chris31
      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.
    • User profile image
      WillemM

      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

    • User profile image
      RuneSpyder
      It would make me really happy if Anders was still playing with Delphi!

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

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you can Contact Us.