The CLR's New Clothes
The following is taken directly from the article One Runtime to Bind Them All by Osvaldo Pinali Doederlein which I found reading Jon Udell's Radio weblog earlier today. The article is fairly technical, but brings up a lot of important issues with regards to the "language-neutral nature of the CLR (Common Language Runtime)."
In particular, I've had several discussions lately where I've argued that having Python work with the CLR doesn't bring a whole lot of benefits to a Python programmer. The central issue for me is that one of the biggest benefits of Python is its large set of standard libraries. If you have to use .NET data structures, classes, and functions and aren't able to leverage Python structures such as strings, tuples, lists and dictionaries effectively, then running in the CLR loses a lot of its appeal. The article doesn't specifically discuss Python, but it does bring up the issue in terms of languages other than C#.
The rest of this post is a direct copy of a section of the original article.:
- The Frameworks. The last-but-not-least important issue: when you do .NET, say you want collections, you don't use Smalltalk's collections, you don't use C++'s STL, you don't use anything that matches your favorite language: you use .NET's collections.
If you are a Smalltalk programmer, you cannot invoke methods that take blocks as arguments and apply them to the elements. If you are a C++ programmer, you cannot do all those neat template tricks. If you are a LISP programmer, you won't see a mess of atoms tied together like a Christmas tree. For the Eiffel programmer, no multiple implementation inheritance, and so on. Whatever the language, you will do things the C# way, at least in every point of contact with the external world (a.k.a. "everything not written in your language" or "any exported interfaces").
We have some experience of this phenomena with distributed services (CORBA, COM) and Web Services; but these usually enforce coarse-grained interfaces, and the native language's frameworks and techniques are used most of the time. For example, a Java programmer will use Java's collections for all data structure work, and CORBA sequences only for walking the IIOP highway. However, if you want your program to be a first-class citizen in the .NET universe, you are bound to use its libraries for collections, GUI, streams, networking, threading and son on.
This is not different from the JVM imposing the J2SE / J2EE APIs; which is not a problem for Java programmers because they are using the Java language, so they are using frameworks that perfectly match the language. The same factor benefits C#, that adopts the new .NET libs as its native framework. .NET programs written in any other language will be bigger and more complex than C# equivalents, if they insist using their native (Microsoft will probably label "legacy") libs, and need to convert things to and from the .NET types. Pick the framework that is suited to your (non-C#-clone) language, or cross language programming, but not both.
2:35:50 PM 
|
|
