With regard to point 8: component frameworks such as CORBA and COM (DCOM) provided a means to extend intra-process programming techniques and conventions beyond process boundary (even across the network.) This was accomplished by providing (amongst other things) an infrastructure for converting standard stack-based method invocations into message-based protocols (where the messages could be sent over the wire.)
These frameworks exhorted a price for the conveniences they provided. Basically, you had to program for them. That is, a C++ program written for COM or CORBA looks (and works) differently than a standard C++ application. There was a lot of overhead: writing an IDL, lots of API calls for setting up the system, etc.
Java with RMI showed how easily this type of thing could be done when the environment provides the appropriate facilities, built on a thorough reflection API (see items 2 and 3 in Don's list.) .NET uses the same model and extends it in several notable aspects:
The third point cannot be overstated as SOAP is currently the only means to extend .NET applications beyond the Windows platform.
- The remoting API is open and documented. This means that .NET remoting can (and probably will) be extended to support additional wire protocols.
- Using this API, .NET comes with several built-in remoting services, e.g. TCP and SOAP.
- Speaking of SOAP, .NET automates much of the process of building and using web services. It provides remoting services that work with the various SOAP protocols such as WSDL and UDDI.
With regard to point 9: .NET allows the byte code to be JIT-ed, compiled to native on install, or at build time. Pre-compiling can obviously improve performance but I don't share Don's enthusiasm over this technology:
Basically what I see NGEN providing is improved load times rather than significant performance gains throughout an app's lifecycle.
- Most apps spend most of their time in very restricted sections of their code. These sections will be JIT-ed only once and then executed many time throughout the app’s lifecycle.
- .NET's overhead compared to C++ (even with COM) is not limited to the JIT overhead. For good and bad C++ lets you work much closer to the metal, thus providing much finer control over performance related issues (e.g. custom memory allocators for STL vs. .NET GC.)
- It's all about the algorithms anyway ;)