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 143582
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Pointless
by segedunum on Sun 16th Jul 2006 18:14 UTC in reply to "RE: Pointless"
segedunum
Member since:
2005-07-06

It is easier than ever to pick the right tool for the job. If I feel that I need the easy expressiveness of Python/Boo for a particular part of my app, I can code that section with one of those languages. If on the other hand I need powerful macro and or functional programming support, Nemerle is a nice choice.You've utterly missed the point.

The simply question you need to ask yourself is: Can you simply and trivially add support for many 'features' from one language like Boo or Nemerle to another .Net language like C#? If the answer is yes a different language is pointless. That's what is happening with C# as it gets developed further, and you'll see any alternative .Net languages fall even further by the wayside.

The only differences between .Net languages are syntactic differences simply for the sake of being different.

The *point* is that at the end of the day, it all works together as if it had all been written in just one language.

You've just given yourself everything you need to know there. That's because *it is* one language ;-).

With .Net, this is no longer the case. How I interact with OpenGL, collection classes, etc, etc, etc is the same no matter which .Net language I'm using.

Makes a different language a bit pointless, doesn't it? That's because at the core of it it is the same language.

Having the same common framework and runtime environment that at the same time allows the use of different languages is a paradox that cannot be squared. Either you enjoy the benefits of having the same framwork and runtime environment, or you enjoy the benefits of having a different language created for a different purpose. You can't have it all ways I'm afraid, and it's something many in the .Net world have come to realise.

This is not religious, but rather pragmatic.

Hmmmm. My point is logic. If you can compile many languages to IL then they are logically the same language, separated only by different syntactic sugar that does the same thing.

Having been through many 'this is the end all be all language' phases, I'm thinking that a framework which elevates the art beyond any particular language

Any framework which gives you that is giving you one language, as .Net is doing and as you've confirmed yourself.

Whenever this is raised, fans of .Net squirm and wriggle like there's no tomorrow. VB and C# coders out there have accepted there's no difference between .Net languages, hence all the fuss from VB coders about what the point of VB.Net is. Microsoft has seemingly accepted it, and the promotion of .Net as a language neutral environment seems to have very much fallen by the wayside.

not only minimizes my risks, but also has the potential to help me realize better ROI and code reuse.

*Finger firmly down throat*. That's a .Net fan comment if ever I heard one.

Edited 2006-07-16 18:19

Reply Parent Score: 0

RE[3]: Pointless
by mjmoran on Sun 16th Jul 2006 19:02 in reply to "RE[2]: Pointless"
mjmoran Member since:
2005-08-13

Let me preface this comment by saying im no Microsoft fanboy, but I do think that the IDEA of .NET is probably the best thing Microsoft has ever done, even if the implementation(re:license) is poor. Infact, thats the only thing that really keeps me off the platform(though I am tracking mono). Its exactly what Sun should implement for Java. Support multiple languages natively.
Now, I realize that everything compiles down to CIL, but thats really no different then what GCC does when it uses one of its many front ends to compile down to a 'middle end' before compiling down to machine for the target system.

"My point is logic. If you can compile many languages to IL then they are logically the same language, separated only by different syntactic sugar that does the same thing. "

Why write code in C or any language which compiles down to machine then? After all, whether you are writing your program in machine, raw assembly, assembly+macros, c, c++ or any other language which compiles down machine they all are logically doing the same thing separated only by different syntactic sugar.

The reason is abstraction. Writing even a mildly complex program in assembly is absolutely mind-blowing(its fun, but can be a drawn out affair). The reason to have multiple languages and in fact, higher level languages is to be able to abstract certain elements of the code AND be able to use the best features of different languages in a cohesive way.

This is one thing that CPython really excels at. It is a very good glue language. For instance, its much easier to write a gui app in python than c. However, if you have one function that is processor intensive, you can recode only that module in c and use it in your app.

Now, in this case, everything ends up as CLR bytecode, however, the principle is the same. By allowing different languages, you app can use the features of all languages. Now, I realize that you could code everything in CIL but that really is the assembly of CLR.

Reply Parent Score: 4

RE[4]: Pointless
by segedunum on Sun 16th Jul 2006 21:04 in reply to "RE[2]: Pointless"
segedunum Member since:
2005-07-06

I'm having a good laugh at someone who's modding these comments down, presumably because they just don't like them :-).

Let me preface this comment by saying im no Microsoft fanboy, but I do think that the IDEA of .NET is probably the best thing Microsoft has ever done

Doesn't really mean anything unfortunately.

Now, I realize that everything compiles down to CIL, but thats really no different then what GCC does when it uses one of its many front ends to compile down to a 'middle end' before compiling down to machine for the target system.

Totally and utterly different. The .Net framework and the CLS and CLR provides an object oriented framework, and it specifies exactly what must be implemented and how, including data types, functions etc. etc. That's if you want interoperability, which is the whole point of using .Net anyway.

If what you're saying was true then if you compiled C, C++, Java or Fortran with GCC then they would all use the same data types, functions, framework and classes and would be totally interoperable and interchangeable. They aren't, for reasons that should be obvious. You'd end up with four languages that all did the same thing, and used the same paradigm, and where you'd have syntax that would be completely equivalent in each, line for line, as in .Net.

Why write code in C or any language which compiles down to machine then?

Because C actually provides an easier, higher-level language that actually does something different in it's own right. There is no underlying framework straight jacketing it in the way that .Net demands for the sake of interoperability, and in turn it doesn't straight jacket software written with it. There are no standard data types, no standard functions and no standard framework classes to adhere to. C++, Java and Fortran, to take the previous example, all do things that are different for different purposes, and as such, they are not interoperable - not directly anyway. If they all used the same framework, same data types, same functions and same paradigms and compiled to exactly the same underlying code then you'd only pick one language over another because of syntax. That's not a good reason.

The reason to have multiple languages and in fact, higher level languages is to be able to abstract certain elements of the code

And perfectly sensible too, if you use totally different languages for totally different purposes in the way I've described. However, that's not the case in .Net - unless you implement something totally different in it, but then what's the point of interoperability and .Net?

AND be able to use the best features of different languages in a cohesive way.

The data types, functions, framework and concepts are so well defined and nailed down that any other higher level, human readable language over the top of C# becomes pointless. You might as well just implement those new features in C# instead. This is happening with successive versions of C# as it simply acquires many of the features of languages like Boo and Nemerle, and they are implemented in exactly the same way because of the underlying framework. You can reasonably ask if Boo and Nemerle are actually different languages. Once you've got up to C#, .Net simply doesn't have abstraction. Within the framework and the concepts of its runtime environment it has been abstracted enough.

However, if you have one function that is processor intensive, you can recode only that module in c and use it in your app.

That's tough luck I'm afraid. Once you start to dictate a common base, runtime, framework and set of standards you end with with each language being so straight jacketed that any differences that made them useful are gone or severely reduced. Interoperability has to be done in other and less exact ways, otherwise you lose all or most of the differences and advantages of the language you've chosen.

By allowing different languages, you app can use the features of all languages.

No, you can't. You can only use languages that have been ported to .Net. If you want to use, in an interoperable way, a language with a different paradigm or that doesn't implement various concepts in the same way as .Net then you're out of luck. You can't put square pegs in round holes, which is what many people claim is possible with .Net.

Now, I realize that you could code everything in CIL but that really is the assembly of CLR.

I think you're getting your comparisons a bit mixed up. You could quite conceivably replace CIL code with C# since everything interoperability-wise should be CLS compliant, in theory, but that would simply be too restrictive in view of the other, non-compliant, things you may want to do in the runtime.

Reply Parent Score: 1

RE[5]: Pointless
by mjmoran on Mon 17th Jul 2006 02:53 in reply to "RE[4]: Pointless"
mjmoran Member since:
2005-08-13

"Doesn't really mean anything unfortunately. "
Wasn't intended to. Just my personal observation.

" If they all used the same framework, same data types, same functions and same paradigms and compiled to exactly the same underlying code then you'd only pick one language over another because of syntax. That's not a good reason."

The problem with that is not everything is the same. Also, syntax is important. Especially if you are porting an existing app.

"
That's tough luck I'm afraid. Once you start to dictate a common base, runtime, framework and set of standards you end with with each language being so straight jacketed that any differences that made them useful are gone or severely reduced. Interoperability has to be done in other and less exact ways, otherwise you lose all or most of the differences and advantages of the language you've chosen. "

This was an example of what you could do with CPython. On .net this could translate to a situation where the gui is already coded in vb.net however you want to use a different language for the backend.

"No, you can't. You can only use languages that have been ported to .Net. If you want to use, in an interoperable way, a language with a different paradigm or that doesn't implement various concepts in the same way as .Net then you're out of luck. You can't put square pegs in round holes, which is what many people claim is possible with .Net. "

Well, the statement was only focused on .net , however, if you wanted to create a language specifically for a purpose, you might find it useful for that purpose. Remember, CPython(the reference version of Python) is coded in C(which I assume why C# is used for IronPython)

"I think you're getting your comparisons a bit mixed up. You could quite conceivably replace CIL code with C# since everything interoperability-wise should be CLS compliant, in theory, but that would simply be too restrictive in view of the other, non-compliant, things you may want to do in the runtime."

You could always replace assembly with C however, it would introduce irritations aswell.

One example(from Wikipedia)

C#
class HelloWorldApp
{
static void Main()
{
System.Console.WriteLine("Hello, world!");
}
}

CLI
.method public static void Main() cil managed
{
.entrypoint
.maxstack 1
ldstr "Hello, world!"
call void [mscorlib]System.Console::WriteLine(string)
ret
}

As you see, they are similar, in the sense that they do the same thing, but one is very different from the other.

Also, I think where IronPython could be very useful is in the case where you want to port an existing program to .net while staying on Python.

-Mike

Reply Parent Score: 1