Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualRattenhirn

Posted 28 December 2012 - 11:06 AM

this rather wordy post
 
Excellent post!
 
I'd like to point out a few things that might not be accurate:
When C started to lose to c++ many of these same arguments appeared. It was bloated, it couldn't match what the expert artisans produced, it forced extra overhead with virtual tables, name resolution was a mess, and on and on and on.

Ignoring the name resolution mess, which has not much to do with the performance debate, there's still a difference between the additional features that C++ adds over C compared to what C# adds to C++.

First, let's look at a few things that C++ brought to the table:
OOP, including runtime polymorphism via ("virtual"), overloading, RTTI, exceptions and templates.

All of these are concepts that were possible to implement in C and integrated them into the language, while retaining the "do not pay for what you do not use" approach. Everything is optional, some things are even cost free, for example overloading, all of OOP, except runtime polymorphism and, for most part, templates. C++ introduced a multi paradigm approach to programming, which seems to confuse a lot of programmers, but is, in my opinion, essential to most often get the best tool for a certain job.

Now, let's see what C++ took away from C:
Nothing! Well, not strictly true, but nothing that really affects anyone.

One might argue, that it should have removed more stupid stuff from C, but then again, remember the "do not for what you do not use" approach, which makes all leftovers, by definition, benign.

Moving on to the differences between C++ and C#/Java.
What did they add?
Fully automatic memory management through GC, a VM for standardization of data types and interpretation or JIT compilation of "byte code", full reflection

Since they are not really an evolution over C++ or C, the comparison is a bit trickier. All of the improvements come with their penalties and are not optional. Every dereference operation has to go through an extra indirection to find out where the memory actually is, the compiler can't really throw stuff away, because the program can still access everything that has been in the source code through reflection, including the names and the VM makes access to system resources that are not already supported tedious or even impossible.

What has it taken away?
Free functions, templates (except for what generics cover), manual memory management, multiple inheritance (except interfaces), and more.

No I'm not saying these are all good or useful things to have, but I'd rather have the options and not be forced into a behaviour that suits the mindset of the creators of the language. Java was created when OOP was kinda new to the mainstream and "teh future", but now it's an old thing and there's a tendency to go data driven programming, for instance.

Some things that it takes away are downright bad:
The RAII idiom is no longer possible, because there's no way to tell when exactly objects are destroyed (C# works around that somewhat with "using"), the GC is unpredictable and introduces nasty pauses when not managed very carefully and there's no way to manage memory manually _at all_ (like, *gasp*, put in on the stack).

The attempt to push the vast subject of programming into a tight set of rules is what upsets me most about these "new" programming languages. I'd hope that something will come along, that adds new goodies, but keeps the old ones.
 
Tools developers have taken notice. Middleware is now touted with being CLR-friendly. Many developers are actively pushing on Sony and the other console developers for direct C# support. A rapidly increasing number of studios want access to hardware-specific functionality in c# compilers. And it is only a matter of time before that happens.

You know, popularity is not a good indicator of how good something is at something. Take a look at Cobol or, ironically, C or C++. ;)
 
 
Not because the language generates magically different executables, but because the gruntwork can be done cheaper.

Not sure what exactly you mean by grunt work, but if it's something un- or lesser skilled people can do, then it should be automated, regardless of language used. Remember, work smart, not hard! ;) j/k

#2Rattenhirn

Posted 28 December 2012 - 11:03 AM

<blockquote class="ipsBlockquote" data-author="frob" data-cid="5015037"><p>this rather wordy post</p></blockquote>&nbsp;<br />Excellent post!<br />&nbsp;<br />I'd like to point out a few things that might not be accurate:<br /><blockquote class="ipsBlockquote" data-author="frob" data-cid="5015037"><p>When C started to lose to c++ many of these same arguments appeared. It was bloated, it couldn't match what the expert artisans produced, it forced extra overhead with virtual tables, name resolution was a mess, and on and on and on.</p></blockquote><br />Ignoring the name resolution mess, which has not much to do with the performance debate, there's still a difference between the additional features that C++ adds over C compared to what C# adds to C++.<br /><br />First, let's look at a few things that C++ brought to the table:<br />OOP, including runtime polymorphism via ("virtual"), overloading, RTTI, exceptions and templates.<br /><br />All of these are concepts that were possible to implement in C and integrated them into the language, while retaining the "do not pay for what you do not use" approach. Everything is optional, some things are even cost free, for example overloading, all of OOP, except runtime polymorphism and, for most part, templates. C++ introduced a multi paradigm approach to programming, which seems to confuse a lot of programmers, but is, in my opinion, essential to most often get the best tool for a certain job.<br /><br />Now, let's see what C++ took away from C:<br />Nothing! Well, not strictly true, but nothing that really affects anyone.<br /><br />One might argue, that it should have removed more stupid stuff from C, but then again, remember the "do not for what you do not use" approach, which makes all leftovers, by definition, benign.<br /><br />Moving on to the differences between C++ and C#/Java.<br />What did they add?<br />Fully automatic memory management through GC, a VM for standardization of data types and interpretation or JIT compilation of "byte code", full reflection<br /><br />Since they are not really an evolution over C++ or C, the comparison is a bit trickier. All of the improvements come with their penalties and are not optional. Every dereference operation has to go through an extra indirection to find out where the memory actually is, the compiler can't really throw stuff away, because the program can still access everything that has been in the source code through reflection, including the names and the VM makes access to system resources that are not already supported tedious or even impossible.<br /><br />What has it taken away?<br />Free functions, templates (except for what generics cover), manual memory management, multiple inheritance (except interfaces), and more.<br /><br />No I'm not saying these are all good or useful things to have, but I'd rather have the options and not be forced into a behaviour that suits the mindset of the creators of the language. Java was created when OOP was kinda new to the mainstream and "teh future", but now it's an old thing and there's a tendency to go data driven programming, for instance.<br /><br />Some things that it takes away are downright bad:<br />The RAII idiom is no longer possible, because there's no way to tell when exactly objects are destroyed (C# works around that somewhat with "using"), the GC is unpredictable and introduces nasty pauses when not managed very carefully and there's no way to manage memory manually _at all_ (like, *gasp*, put in on the stack).<br /><br />The attempt to push the vast subject of programming into a tight set of rules is what upsets me most about these "new" programming languages. I'd hope that something will come along, that adds new goodies, but keeps the old ones.<br /><blockquote class="ipsBlockquote" data-author="frob" data-cid="5015037"><p>Tools developers have taken notice. Middleware is now touted with being CLR-friendly. Many developers are actively pushing on Sony and the other console developers for direct C# support. A rapidly increasing number of studios want access to hardware-specific functionality in c# compilers. And it is only a matter of time before that happens.</p></blockquote><br />You know, popularity is not a good indicator of how good something is at something. Take a look at Cobol or, ironically, C or C++. ;)<br /><blockquote class="ipsBlockquote" data-author="frob" data-cid="5015037"><p>Not because the language generates magically different executables, but because the gruntwork can be done cheaper.</p></blockquote><br />Not sure what exactly you mean by grunt work, but if it's something un- or lesser skilled people can do, then it should be automated, regardless of language used. Remember, work smart, not hard! ;) j/k<br /><br />

#1Rattenhirn

Posted 28 December 2012 - 11:02 AM

<blockquote class="ipsBlockquote" data-author="frob" data-cid="5015037"><p>this rather wordy post</p></blockquote>&nbsp;<br />Excellent post!<br />&nbsp;<br />I'd like to point out a few things that might not be accurate:<br /><blockquote class="ipsBlockquote" data-author="frob" data-cid="5015037"><p>When C started to lose to c++ many of these same arguments appeared. It was bloated, it couldn't match what the expert artisans produced, it forced extra overhead with virtual tables, name resolution was a mess, and on and on and on.</p></blockquote><br />Ignoring the name resolution mess, which has not much to do with the performance debate, there's still a difference between the additional features that C++ adds over C compared to what C# adds to C++.<br /><br />First, let's look at a few things that C++ brought to the table:<br />OOP, including runtime polymorphism via ("virtual"), overloading, RTTI, exceptions and templates.<br /><br />All of these are concepts that were possible to implement in C and integrated them into the language, while retaining the "do not pay for what you do not use" approach. Everything is optional, some things are even cost free, for example overloading, all of OOP, except runtime polymorphism and, for most part, templates. C++ introduced a multi paradigm approach to programming, which seems to confuse a lot of programmers, but is, in my opinion, essential to most often get the best tool for a certain job.<br /><br />Now, let's see what C++ took away from C:<br />Nothing! Well, not strictly true, but nothing that really affects anyone.<br /><br />One might argue, that it should have removed more stupid stuff from C, but then again, remember the "do not for what you do not use" approach, which makes all leftovers, by definition, benign.<br /><br />Moving on to the differences between C++ and C#/Java.<br />What did they add?<br />Fully automatic memory management through GC, a VM for standardization of data types and interpretation or JIT compilation of "byte code", full reflection<br /><br />Since they are not really an evolution over C++ or C, the comparison is a bit trickier. All of the improvements come with their penalties and are not optional. Every dereference operation has to go through an extra indirection to find out where the memory actually is, the compiler can't really throw stuff away, because the program can still access everything that has been in the source code through reflection, including the names and the VM makes access to system resources that are not already supported tedious or even impossible.<br /><br />What has it taken away?<br />Free functions, templates (except for what generics cover), manual memory management, multiple inheritance (except interfaces), and more.<br /><br />No I'm not saying these are all good or useful things to have, but I'd rather have the options and not be forced into a behaviour that suits the mindset of the creators of the language. Java was created when OOP was kinda new to the mainstream and "teh future", but now it's an old thing and there's a tendency to go data driven programming, for instance.<br /><br />Some things that it takes away are downright bad:<br />The RAII idiom is no longer possible, because there's no way to tell when exactly objects are destroyed (C# works around that somewhat with "using"), the GC is unpredictable and introduces nasty pauses when not managed very carefully and there's no way to manage memory manually _at all_ (like, *gasp*, put in on the stack).<br /><br />The attempt to push the vast subject of programming into a tight set of rules is what upsets me most about these "new" programming languages. I'd hope that something will come along, that adds new goodies, but keeps the old ones.<br /><blockquote class="ipsBlockquote" data-author="frob" data-cid="5015037"><p>Tools developers have taken notice. Middleware is now touted with being CLR-friendly. Many developers are actively pushing on Sony and the other console developers for direct C# support. A rapidly increasing number of studios want access to hardware-specific functionality in c# compilers. And it is only a matter of time before that happens.</p></blockquote><br />You know, popularity is not a good indicator of how good something is at something. Take a look at Cobol or, ironically, C or C++. ;)<br /><blockquote class="ipsBlockquote" data-author="frob" data-cid="5015037"><p>Not because the language generates magically different executables, but because the gruntwork can be done cheaper.</p></blockquote><br />Not sure what exactly you mean by grunt work, but if it's something un- or lesser skilled people can do, then it should be automated, regardless of language used. Remember, work smart, not hard! ;) j/k<br /><br />

PARTNERS