What makes C and C++ a "good" language?
-
Consider that C can work in microchips with very little memory and a very reduced CPU instruction set (for example http://www.microchip.com/[^]). Java and .NET are very different that C. They are "platforms", not languages. Java and .NET runtime is in the 20Mb+ size libraries. Latest versions don't support old operating systems. rt.jar is 42.6Mb (compressed!!). Java and .NET strings are inmutable, etc. I'm not defending C, but most modern languages aren't languages, they are frameworks. And C/C++ are few of the languages out there not owned by a corporation (.NET-Microsoft, Java-Oracle). C/C++ do not target app developers. They target compiler developers, OS developers, driver developers and libraries developers. I guess thats why C tops TIOBE (and C++ is 4º).
it´s the journey, not the destination that matters
ErnestoNet wrote:
Consider that C can work in microchips with very little memory and a very reduced CPU instruction set
You are wrong. You are confusing language, compilation and executable. One uses a C compiler to create a program where the executable then runs on the chips that you cite. compiler != program != executable
ErnestoNet wrote:
Java and .NET are very different that C. They are "platforms", not languages
Wrong. Java and C# very specifically are languages. I would guess that you are unaware of real time Java which is specifically targeted at embedded devices. You are confusing language with libraries and you will NOT be able to write a C program that does anything discernable without the C libraries. And it is quite possible to write a C program on windows that would never run on the chips that you cite.
ErnestoNet wrote:
I'm not defending C, but most modern languages aren't languages, they are frameworks.
What exactly do you think that the C++ Standard Library is? Where do you think 'printf' comes from in C?
ErnestoNet wrote:
C/C++ do not target app developers. They target compiler developers, OS developers, driver developers and libraries developers.
I guess thats why C tops TIOBE (and C++ is 4º).Nonsense. The people who write compilers, drivers, OSes and libraries are a small, small fraction of the developer base. If those were the only people using it then it would be far down the TIOBE list. Developers creating business applications use it. That is why it shows up there. You would be better off citing embedded development but there is also C++ and Java development in that domain.
-
The problem with C (and C++) is that they have to be compatible with older code. And they are too flexible (too much for my taste). Don't think of high or low level. Templates in C++ are higher level than C# and Java generics (for sure). Think it this way. C/C++ is compatible with new and old stuff. ansi AND Unicode. Asm, procedures, objects and templates. Don't be sad for C/C++. They will outlast C#, Objective-C and Java (Java has started to decline and C again tops the tiobe index). You ask what makes C/C++ "good". Speed, portability, flexibility, huge codebases and an absense of an owner. But, most of all, a compromise of compatibility, no matter how complex the language becomes, how outdated the structure is. New features will be added, old features will not be replaced. To be "better", C/C++ should be incompatible with older code or fork. Luckily that won't happen. It will sacrifice simplicity and ease of use for compatibility. Oh, and C/C++, in certain cases, can be MUCH faster than C#/Java. I have an article where C/C++ is 10x faster that well written C#/Java.
it´s the journey, not the destination that matters
ErnestoNet wrote:
Oh, and C/C++, in certain cases, can be MUCH faster than C#/Java.
And in certain cases I am faster than C/C++/C#/Java and any other language that you care to name. Not to mention all of the functions that I do that no language can accomplish. But since people don't pay me to digest lunch but they do pay me to write large systems I can be safe in the knowledge that the flavor of the month language (even when it is an old flavor) will have little impact on the performance of the systems that I write and will not make me more or less productive either.
-
ErnestoNet wrote:
Text based compilers are easier to write that binary based compilers.
The headers approach is easy to build a compiler from.
C is a very simple language to write a compiler.
There are LOTS of C compilers.At this point I am rather certain that you do not know what you are talking about. C headers are part of the language. Period. C compilers implement the C language. Period. The first fact is only related to the second by the fact that headers are in the language. It has nothing to do with compilation. There is no such thing as a "binary" compiler in common usage. Best I can suppose you are talking about is what occurs in a Java Virtual Machine when it process a Java class file. That process it best described as interpretation not compilation. Your confusion about the above also has nothing to do with your confusion about what portabiity means.
ErnestoNet wrote:
More compilers provide better portability.
Wrong. You have confused availability with portability. More compilers means you can use it on more platforms. In point of fact almost all C code written for the Windows system will not work on any other platform (without extreme care but that is my point about portability in the first place.)
ErnestoNet wrote:
There are not many cross platform/architecture languages.
You are wrong. Java and Perl exist on many platforms. Excluding small unix platforms, perl exists on basically all unix systems that C does. And again availability is NOT the same as portability.
ErnestoNet wrote:
Name a crossplatform language and I'll compare that to C in terms of portability....
Your term definition for portability is wrong. http://en.wikipedia.org/wiki/Software_portability[^] By definition of programming languages I can always (within resource limits) create compiler/interpreter that originated on one platform and implement it for another. You are using that for your definition and then claiming that because C exists in many places that that makes in "portable" but instead is what it proves that it is 'popular' and '
Call it availability. C is the most available language. There is an important point you make: I can always (within resource limits) create compiler/interpreter that originated on one platform and implement it for another. "within resource limits" is the key here. C is simple. Java JVM is complicated (and owned). It's important that you know that I'm not defending C. It's really ugly compared to other languages and prone to error. But it's fast (predictable fast, no GC collection pause), very "available", flexible and stable. Most of the programs I use everyday are built in C/C++. None in Perl. None in Java.
it´s the journey, not the destination that matters
-
ErnestoNet wrote:
Oh, and C/C++, in certain cases, can be MUCH faster than C#/Java.
And in certain cases I am faster than C/C++/C#/Java and any other language that you care to name. Not to mention all of the functions that I do that no language can accomplish. But since people don't pay me to digest lunch but they do pay me to write large systems I can be safe in the knowledge that the flavor of the month language (even when it is an old flavor) will have little impact on the performance of the systems that I write and will not make me more or less productive either.
It's good to know different languages and try to understand why they are the way they are. Even more, it's good to know about different technologies (SQL, COM, OLAP, EJB, Corba, XML, JSON, CSS, HTML, etc). It's not about being good, but keeping the right attitude towards developing knowledge. People that know a lot about developing are the ones that admit they know nothing and keep learning, with an open mind. About the pay...that usually involves other skills that have very little to do with technologies or programming...:): http://www.theregister.co.uk/2012/03/21/how_to_get_paid_more/[^]
it´s the journey, not the destination that matters
-
ErnestoNet wrote:
Consider that C can work in microchips with very little memory and a very reduced CPU instruction set
You are wrong. You are confusing language, compilation and executable. One uses a C compiler to create a program where the executable then runs on the chips that you cite. compiler != program != executable
ErnestoNet wrote:
Java and .NET are very different that C. They are "platforms", not languages
Wrong. Java and C# very specifically are languages. I would guess that you are unaware of real time Java which is specifically targeted at embedded devices. You are confusing language with libraries and you will NOT be able to write a C program that does anything discernable without the C libraries. And it is quite possible to write a C program on windows that would never run on the chips that you cite.
ErnestoNet wrote:
I'm not defending C, but most modern languages aren't languages, they are frameworks.
What exactly do you think that the C++ Standard Library is? Where do you think 'printf' comes from in C?
ErnestoNet wrote:
C/C++ do not target app developers. They target compiler developers, OS developers, driver developers and libraries developers.
I guess thats why C tops TIOBE (and C++ is 4º).Nonsense. The people who write compilers, drivers, OSes and libraries are a small, small fraction of the developer base. If those were the only people using it then it would be far down the TIOBE list. Developers creating business applications use it. That is why it shows up there. You would be better off citing embedded development but there is also C++ and Java development in that domain.
It's not about being right, but if you want to be right, there you have it: YOU'RE RIGHT! That said, the STL, if you don't use it, you don't load it. The header approach only loads (and compiles) what you use. In fact, when you compile and link, only the functions that you use are linked. In Java and others, you load everything (even if you don't use it). About Embedded development, I know a lot of people that work with it and they work mostly with Assembler and C. Java and C++ may exist, but they are not used. Today embedded has changed with ARM cellphones. A 2Gb memory dual core CPU cellphone is closer to a PC that to embedded. There you can run Java, as in the PC. A real, cheap embedded chip with 64Kb of memory and a few cycles processor can't run (with decent performance) Java or C++. Java embedded only runs on ARM to start with. It requires at least 130Kb (with tweaking) and 700kb by default. It requires a network connection! It does not support real time. You can check everything here: http://www.oracle.com/ocom/groups/public/@otn/documents/digitalasset/1852008.pdf[^] I'm going to say it again, just because Bjarne Stroustrup said it and I think he is right: Java and .NET ARE PLATFORMS.
it´s the journey, not the destination that matters
-
Call it availability. C is the most available language. There is an important point you make: I can always (within resource limits) create compiler/interpreter that originated on one platform and implement it for another. "within resource limits" is the key here. C is simple. Java JVM is complicated (and owned). It's important that you know that I'm not defending C. It's really ugly compared to other languages and prone to error. But it's fast (predictable fast, no GC collection pause), very "available", flexible and stable. Most of the programs I use everyday are built in C/C++. None in Perl. None in Java.
it´s the journey, not the destination that matters
ErnestoNet wrote:
"within resource limits" is the key here. C is simple. Java JVM is complicated (and owned).
Not sure what you think "owned" means but far as I know the term "Java" is owned but the language is licensed in such a way that I can in fact take it and create a compiler and complete JDK fro a new platform free of charge. See "Licensing" in the following. http://openjdk.java.net/faq/[^] If you had to start from scratch then C, as in C11, is not trivial. And I am talking about the language and not the libraries. Implementing everything from scratch would be a large undertaking. Of course one would start with the existing source and modified for a new platform. Which is the same thing one would do for Java.
ErnestoNet wrote:
But it's fast (predictable fast, no GC collection pause),
Again - research Real Time Java. Other than that modern business usage is not impacted by the modern GC.
ErnestoNet wrote:
Most of the programs I use everyday are built in C/C++.
None in Perl. None in Java.Which is why *I* said that language choice is by user preference and not availability. Perl is available on all of the C platforms so they don't choose C because it is available.
-
It's not about being right, but if you want to be right, there you have it: YOU'RE RIGHT! That said, the STL, if you don't use it, you don't load it. The header approach only loads (and compiles) what you use. In fact, when you compile and link, only the functions that you use are linked. In Java and others, you load everything (even if you don't use it). About Embedded development, I know a lot of people that work with it and they work mostly with Assembler and C. Java and C++ may exist, but they are not used. Today embedded has changed with ARM cellphones. A 2Gb memory dual core CPU cellphone is closer to a PC that to embedded. There you can run Java, as in the PC. A real, cheap embedded chip with 64Kb of memory and a few cycles processor can't run (with decent performance) Java or C++. Java embedded only runs on ARM to start with. It requires at least 130Kb (with tweaking) and 700kb by default. It requires a network connection! It does not support real time. You can check everything here: http://www.oracle.com/ocom/groups/public/@otn/documents/digitalasset/1852008.pdf[^] I'm going to say it again, just because Bjarne Stroustrup said it and I think he is right: Java and .NET ARE PLATFORMS.
it´s the journey, not the destination that matters
ErnestoNet wrote:
In Java and others, you load everything (even if you don't use it).
Wrong. In a number of ways. First both C and C++ in modern compilers commonly rely on shared libraries. Modern OSes load the entire shared library even if one method is used. Static linking although possible isn't normally used on desktop OSes and there is no reason to expect that Java/C# would need to do anything different on a desktop OS. In contrast Java and C# do something similar but, at least for Java, that is done solely as a run time performance optimization. One can create a stripped down version of the library is one wants. And one can also do a load only on use case (at least in java) even if using the standard API jars. I suspect the same is true for C#. And that is true for a desktop OS. If one has an embedded Java SDK then there ware going to be substantial differences when compared to a desktop OS. But the same thing apples to using C in embedded systems as well.
ErnestoNet wrote:
Java and C++ may exist, but they are not used.
If it wasn't used then there wouldn't be companies creating compilers for just that purpose. Googling provides that. A company selling nothing but compilers wouldn't be viable if there wasn't a sizable market of people creating applications using it. As another example the following is a link for a company that specializes in creating java embedded solutions. http://www.k-embedded-java.com/[^] Following is a device. http://www.avidwireless.com/AVIDdirector.html[^]
ErnestoNet wrote:
Java embedded only runs on ARM to start with. It requires at least 130Kb (with tweaking) and 700kb
That is a product that Oracle offers. It is far from the only product out there.
-
It's good to know different languages and try to understand why they are the way they are. Even more, it's good to know about different technologies (SQL, COM, OLAP, EJB, Corba, XML, JSON, CSS, HTML, etc). It's not about being good, but keeping the right attitude towards developing knowledge. People that know a lot about developing are the ones that admit they know nothing and keep learning, with an open mind. About the pay...that usually involves other skills that have very little to do with technologies or programming...:): http://www.theregister.co.uk/2012/03/21/how_to_get_paid_more/[^]
it´s the journey, not the destination that matters
ErnestoNet wrote:
It's good to know different languages and try to understand why they are the way they are.
Which is why I do in fact know quite a few.
ErnestoNet wrote:
It's not about being good, but keeping the right attitude towards developing knowledge.
People that know a lot about developing are the ones that admit they know nothing and keep learning, with an open mind.And know how to look for objective data as well.
-
ErnestoNet wrote:
In Java and others, you load everything (even if you don't use it).
Wrong. In a number of ways. First both C and C++ in modern compilers commonly rely on shared libraries. Modern OSes load the entire shared library even if one method is used. Static linking although possible isn't normally used on desktop OSes and there is no reason to expect that Java/C# would need to do anything different on a desktop OS. In contrast Java and C# do something similar but, at least for Java, that is done solely as a run time performance optimization. One can create a stripped down version of the library is one wants. And one can also do a load only on use case (at least in java) even if using the standard API jars. I suspect the same is true for C#. And that is true for a desktop OS. If one has an embedded Java SDK then there ware going to be substantial differences when compared to a desktop OS. But the same thing apples to using C in embedded systems as well.
ErnestoNet wrote:
Java and C++ may exist, but they are not used.
If it wasn't used then there wouldn't be companies creating compilers for just that purpose. Googling provides that. A company selling nothing but compilers wouldn't be viable if there wasn't a sizable market of people creating applications using it. As another example the following is a link for a company that specializes in creating java embedded solutions. http://www.k-embedded-java.com/[^] Following is a device. http://www.avidwireless.com/AVIDdirector.html[^]
ErnestoNet wrote:
Java embedded only runs on ARM to start with. It requires at least 130Kb (with tweaking) and 700kb
That is a product that Oracle offers. It is far from the only product out there.
You said it yourself, in C and C++ you can statically link. Or not use. In Java/C# you can't. You load 42Mb rt.jar in Java. About embedded Java in http://www.avidwireless.com/Products.html[^], it looks rather expensive and not a custom solution. Most embedded code I've seen are for PIC modules http://en.wikipedia.org/wiki/PIC_microcontroller[^] We are talking about different kind of machines here.
it´s the journey, not the destination that matters
-
You said it yourself, in C and C++ you can statically link. Or not use. In Java/C# you can't. You load 42Mb rt.jar in Java. About embedded Java in http://www.avidwireless.com/Products.html[^], it looks rather expensive and not a custom solution. Most embedded code I've seen are for PIC modules http://en.wikipedia.org/wiki/PIC_microcontroller[^] We are talking about different kind of machines here.
it´s the journey, not the destination that matters
ErnestoNet wrote:
You said it yourself, in C and C++ you can statically link. Or not use. In Java/C# you can't. You load 42Mb rt.jar in Java.
Actually no I didn't say. Actually I said the opposite. Rather specifically. What part of what I said didn't you understand?
ErnestoNet wrote:
About embedded Java in http://www.avidwireless.com/Products.html[^], it looks rather expensive and not a custom solution.
Which is irrelevant.
ErnestoNet wrote:
We are talking about different kind of machines here.
If you want to define "embedded" software in a specific way and get the developers who currently call themselves embedded developers to agree that they are not in fact embedded developers then go for it. But until then my statement stands.