------ extPartTM-000-bc23894f-6c70-4dd3-ab41-64d082d8d119 Content-Type: text/plain; charset s-ascii" Content-Transfer-Encoding: quoted-printable //> //Ow ow ow. The concept of a Microsoft platform providing a //> //"true level playing field" for anything just made by brain hurt. // //> Hey, backoff. // //What's the big deal? It's a fair point substantiated by //several courts of law. The idea behind the CLI and that behind MS as a commercial company are two different things. While I could ask you to not dislike the CLI because MS created it, it simply easier if you read Dave Stutz's books first chapter that introduces the CLI. Let me post the link again: http://www.oreilly.com/catalog/sscliess/chapter/ch01.pdf Secondly the big deal is that not everyone may share the same opinion about MS as a company and people are free to do that same as you have yours. What bothered me was that something that was description about the CLI was equated to MS, in rhetoric that is so typical of open source. I will stop now. // //> Yes I figured that Matz's reasons would be those. Which is //good. But I //> would always argue for the Ruby being on the CLI - I might even do //> something about it, had I been a good enough programmer, //but that will //> have to wait. Today the CLI/CLR let you write a class in C++ and //> inherit and extend that in Visual Basic. Being on the CLI //simply makes //> avilable to Ruby everything the .Net community has done and thats //> awesome. // //I won't stand behind or attempt to justify these claims, but //I'm told that the CLI doesn't really support multiple //languages; rather the languages have changed to support the //CLI. It's probably an exaggeration to say that the languages //are now the same but with different keywords, but it's also //an exaggeration that the CLI supports C++ and VB in their //original spirits. Do you have an opinion on this? Yes I do, but admittedly it's a hard question. The CLI offers, listen to me carefully, execution services to code in certain way - it is not a classical virtual machine so to speak. The CLI does consume byte code of a theoretical processor or machine. Execution services include verfication of types loaded into the system, garbage collection, life time management, reflection, IPC (of a sort) and other things. Not ALL languages fit into the execution model provided by the CLI in its present state. Essentially what the desifgners of the CLI have tried to do is to create a notion of _types_ that can exist across language boundaries. COM used to do do that in limited ways, but in the COM model one could not garauntee various services that a _type_ would provide. In that sense the CLI essentially manages types and objects across languages. That said, C++ is supported under the CLI in mostly the same form, additions have been made to the language so that it can interoperate with other CLI types and with the garbage collector - because C++ never had a GC. VB is a language that has changed a lot - most of the changes where inevitable in the language whether the CLI was there or not such as making it object oriented and providing support for threading. //> But if Matz (or anyone knowledgible enough) were to put out reasons //> for why the CLR is inadequate, the .net community might be able to //> respond and do something about it. // //Forgive my ignorance, but what can the community do about it? // Do they have any influence over the spec? Yes, in terms of where the CLI is going. The MVP program and the univrsity grant program related to the SSCLI are steps to help facilitate this. Regards Rosh ------ extPartTM-000-bc23894f-6c70-4dd3-ab41-64d082d8d119 Content-Type: text/plain; name nterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename nterScan_Disclaimer.txt" This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com ------ extPartTM-000-bc23894f-6c70-4dd3-ab41-64d082d8d119--