Linked by Eugenia Loli on Sat 15th Jul 2006 22:45 UTC
.NET (dotGNU too) Jeff Cogswell writes: "I'm about to make a confession. Even though I've written several books and articles about C++, I have a secret: C++ isn't my favorite language. I have lots of languages that I use, each one for different purposes. But the language I consider my all-time favorite is Python."
Thread beginning with comment 143561
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Pointless
by saxiyn on Sun 16th Jul 2006 16:42 UTC in reply to "Pointless"
saxiyn
Member since:
2005-07-08

I find mapping existing languages to the .Net framework and the Common Language Specification utterly pointless, simply because you don't get Python at the end of it but yet another .Net language.

And you are completely wrong. IronPython implements a full Python language, not any subset of it. As a result, it is not a ".NET language", or in more technical term, "CLS compliant". It is not its goal.

Reply Parent Score: 4

v RE[2]: Pointless
by segedunum on Sun 16th Jul 2006 18:45 in reply to "RE: Pointless"
RE[3]: Pointless
by TBPrince on Sun 16th Jul 2006 22:44 in reply to "RE[2]: Pointless"
TBPrince Member since:
2005-07-06

The goal of ANY .NET languages is not to have a language per se but to allow access to .NET framework.

While most language implementations have macros (or sometimes libraries) which allow compatibility with popular constructs or functions, that's just an handy tool for legacy code which should be converted.

So the goal of IronPython is not to have a Python implementation per se but to allow people to use Python to code against the .NET framework. This won't be portable by definition, not as side-effect.

(Please notice that I'm not using Python but I'm using .NET framework)

Reply Parent Score: 1

RE[3]: Pointless
by n4cer on Sun 16th Jul 2006 23:44 in reply to "RE[2]: Pointless"
n4cer Member since:
2005-07-06

It's written in C#, so it inherits CLS compliance in some way. I find the notion that somehow it isn't a .Net language and that it's somehow different rather silly.

Neither C#, C++/CLI, VB.NET, nor many other languages that target CLI/CLR are inherently CLS-compliant languages. Each language has features that violate CLS compliance rules, and their respective compilers do not check for CLS compliance by default. Unless you actually take the necessary steps to ensure that your code is CLS compliant, it likely is not.
See the following links and excerpts from MSDN.

Common Language Specification
http://windowssdk.msdn.microsoft.com/en-us/library/12a7a7h3.aspx

"The CLS was designed to be large enough to include the language constructs that are commonly needed by developers, yet small enough that most languages are able to support it. In addition, any language construct that makes it impossible to rapidly verify the type safety of code was excluded from the CLS so that all CLS-compliant languages can produce verifiable code if they choose to do so."

Writing CLS-Compliant Code
http://windowssdk.msdn.microsoft.com/en-us/library/bhc3fa7f.aspx
Language Interoperability Overview
http://windowssdk.msdn.microsoft.com/en-us/library/a2c7tshk.aspx
"Even though the runtime provides all managed code with support for executing in a multilanguage environment, there is no guarantee that the functionality of the types you create can be fully used by the programming languages that other developers use. This is primarily because each language compiler targeting the runtime uses the type system and metadata to support its own unique set of language features. In cases where you do not know what language the calling code will be written in, you are unlikely to know whether the features your component exposes are accessible to the caller. For example, if your language of choice provides support for unsigned integers, you might design a method with a parameter of type UInt32; but from a language that has no notion of unsigned integers, that method would be unusable."

Reply Parent Score: 2