First, let me start by saying that the definition of an experienced programmer is that they don't care about the particulars of any given language. Experience means they have seen many languages come and go and they will continue to adapt.
That's the long-term skill that will keep putting money in your pocket. Coming out of college, it's important you know that.
That being said, congratulations on sticking with Linux in a Windows world. Purely from a job perspective, there might be more jobs on the Windows pl
... it is also pertinent to note here that the GNU standards document, section 3.1 [gnu.org]: "Which Languages to Use" strongly advises plain old C for both performance and absolute maximum cross-platform compatibility.
Since operating system and hardware platform independence are both key factors of code re-usability and really what open source software is all about I personally think this is a strong call.
However the parent post is correct in that application intent trumps all. If you are just writing shell tools y
... it is also pertinent to note here that the GNU standards document, section 3.1 [gnu.org]: "Which Languages to Use" strongly advises plain old C for both performance and absolute maximum cross-platform compatibility.
I remember for years C being considered faster on systems than C++, although I believe over the years the gap, if there still is one at all, has narrowed? What is true, someone share it with me as I am curious? Are there any incompatibilities when using C++ and migrating to different Operating System environments any more like their use to be in the dark ages?
Can you compile C++ down small enough to use in embedded devices or does C++ still pull in libraries that are not needed or too big?
The problem with C++ is that it's a crazy, crazy language. At first, it was just a superset of C, but now there's all kinds of stuff...it's mutated into a totally different kind of thing. C has this elegant simplicity going for it. There's nothing the matter with C++...except that C is (pretty much) perfect.
Also your feel dirty comment, is that because of the ease in which a poor programmer can create unstructured code? If so would it not be the fault of the programmer and not the language specifically? (i.e. Assembly for the 8088,..286,..386 and IBM Mainframe made me feel dirty sometimes with they way you were forced to branch, but it was fast...and no I am far from an expert Assembly programmer.
The problem with PHP (and I code mostly in it for a living) is that it wasn't 'designed' at all. Originally it was just a pre-processor, and it's grown into a full blown language from there. This is all well and good, except that there's no sort of continuity to it at all. Naming conventions? (isset vs every other 'is' function starting with 'is_', etc) Who needs them? OO? Sure...ish.
PHP is great for getting things done, but I certainly feel dirty after coding in it.
FYI, personally I do not have a preference and simply choose what is convenient for me to use that will get the job done, period. I honestly do not know the nuances between them...and I am sure that there are some.
The problem with C++ is that it's a crazy, crazy language. At first, it was just a superset of C, but now there's all kinds of stuff...it's mutated into a totally different kind of thing. C has this elegant simplicity going for it. There's nothing the matter with C++...except that C is (pretty much) perfect.
That's all true... but I think you're missing something: all of that crazy stuff was added to C++ because it is useful. Of course, any given program will probably only need a small subset of those features, but for the programs that really do need feature X, having it available in the language is a big time-saver.
I've done a good amount of both C and C++ programming, and these days when I need to write in C I generally end up writing a fair amount of code to manually re-implement functionality that I would get 'for free' in C++.
I'd say C++ is a lot like English: a big, overgrown, complicated, mess -- and damn useful if you want to get things done. (If you care more about elegance and simplicity, there is always Esperanto, for whatever good that does you)
by Anonymous Coward writes:
on Sunday December 07, 2008 @04:40AM (#26018709)
and these days when I need to write in C I generally end up writing a fair amount of code to manually re-implement functionality that I would get 'for free' in C++.
Odds are you're ignoring one of the true fundamental virtues of programming: Reusability.
You see, when you have a rock stable ABI, like C affords you, you can create these things called "Libraries", which future products can then depend on, often times even in other languages like Python and Java. And those products can then be depended on, and so on and so forth until you have a whole working system.
I laugh every time I hear someone say something like "Oh C++ has [blah] "for free"". No, you don't have it for free, someone else just coded it, stuck it in your fat C++ library and now 10 years later people bicker about whether it was actually the right approach to standardize so much of this crap, when so many different "standard libraries" are so totally and hopelessly incompatible.
C's standard library is so spartan that you can write your own "standard library" full of goodies like lists and queues and trees and other time savers, and you never have to get into such arguments to begin with.
Or, if you're incredibly lazy, you can use some of the community maintained, amazing C libraries that already exist. My personal favorite happens to be GLib, but anyone who's written enough code in C to have an opinion on the subject has probably written one of their own or come across one they like as well (such as eGLib in Mono, the Apache Portable Runtime Library in Apache, and the list just curls on...)
So yeah, all of that stuff was added to C++ because it was useful... Just as long as you're working on one project, with one version of [OS], with one compiler...
So yeah, all of that stuff was added to C++ because it was useful... Just as long as you're working on one project, with one version of [OS], with one compiler...
The key thing here is that C has a well-defined stable ABI that you can use to interact between different versions of a compiler, even different compilers. In C++ it is possible to do this on some level (look at COM, for example), but this does not work at the larger level.
Looking at Qt3 (don't know if they've fixed this in Qt4), but the interfaces don't have virtual destructors. They can't fix this as it will break program ABI, and not having it opens up to bugs (derived destructor not being called when de
It is neither elegant nor simple, though compared to C++ I guess it would look that way. You've got C's byzantine declarations, cryptic syntactic symbols, pointer madness, goto, the C-preprocessor, unions, pea soup of signed/unsigned integer and float types, implicit conversions and casting, undefined or platform defined behavior, null-terminated strings, and the hack #include instead of a real module system.
C has been best described as a portable assembly language.
C has this elegant simplicity going for it. There's nothing the matter with C++...except that C is (pretty much) perfect.
You really should learn C++. Yes, C is really simple, but it's not a good language. At all. Unless you are doing low-level programming, C is probably the wrong choice. I mean, how the hell can you write a program these days without OOP, exceptions, generic containers/algorithms, and user-defined data types? I mean hell, C can't even deal with strings in any reasonable way.
I did learn C++, back in the day when it was a superset...but I stopped, because I didn't really like it.
I mean, how the hell can you write a program these days without OOP,
Honestly... I don't really like writing most things in OO style. I tend to find that most of the time, OOP is just done for OOP's sake, and it's much easier to just program in a procedural manner. A lot of "OO" code is just procedural code in OO clothing.
However, sometimes, it does make sense. Quite a bit of the coding I do is OO code. But that's usually because I'm working with other people who write in
Don't steal; thou'lt never thus compete successfully in business. Cheat.
-- Ambrose Bierce
It doesn't matter as long as it's on Linux (Score:4, Insightful)
First, let me start by saying that the definition of an experienced programmer is that they don't care about the particulars of any given language. Experience means they have seen many languages come and go and they will continue to adapt.
That's the long-term skill that will keep putting money in your pocket. Coming out of college, it's important you know that.
That being said, congratulations on sticking with Linux in a Windows world. Purely from a job perspective, there might be more jobs on the Windows pl
This is all true however... (Score:5, Informative)
... it is also pertinent to note here that the GNU standards document, section 3.1 [gnu.org]: "Which Languages to Use" strongly advises plain old C for both performance and absolute maximum cross-platform compatibility.
Since operating system and hardware platform independence are both key factors of code re-usability and really what open source software is all about I personally think this is a strong call.
However the parent post is correct in that application intent trumps all. If you are just writing shell tools y
Re: (Score:4, Insightful)
... it is also pertinent to note here that the GNU standards document, section 3.1 [gnu.org]: "Which Languages to Use" strongly advises plain old C for both performance and absolute maximum cross-platform compatibility.
I remember for years C being considered faster on systems than C++, although I believe over the years the gap, if there still is one at all, has narrowed? What is true, someone share it with me as I am curious? Are there any incompatibilities when using C++ and migrating to different Operating System environments any more like their use to be in the dark ages?
Can you compile C++ down small enough to use in embedded devices or does C++ still pull in libraries that are not needed or too big?
Re:This is all true however... (Score:5, Interesting)
...C++...
The problem with C++ is that it's a crazy, crazy language. At first, it was just a superset of C, but now there's all kinds of stuff...it's mutated into a totally different kind of thing. C has this elegant simplicity going for it. There's nothing the matter with C++...except that C is (pretty much) perfect.
Also your feel dirty comment, is that because of the ease in which a poor programmer can create unstructured code? If so would it not be the fault of the programmer and not the language specifically? (i.e. Assembly for the 8088, ..286, ..386 and IBM Mainframe made me feel dirty sometimes with they way you were forced to branch, but it was fast...and no I am far from an expert Assembly programmer.
The problem with PHP (and I code mostly in it for a living) is that it wasn't 'designed' at all. Originally it was just a pre-processor, and it's grown into a full blown language from there. This is all well and good, except that there's no sort of continuity to it at all. Naming conventions? (isset vs every other 'is' function starting with 'is_', etc) Who needs them? OO? Sure...ish. PHP is great for getting things done, but I certainly feel dirty after coding in it.
FYI, personally I do not have a preference and simply choose what is convenient for me to use that will get the job done, period. I honestly do not know the nuances between them...and I am sure that there are some.
Always a good way to be.
Re:This is all true however... (Score:5, Insightful)
The problem with C++ is that it's a crazy, crazy language. At first, it was just a superset of C, but now there's all kinds of stuff...it's mutated into a totally different kind of thing. C has this elegant simplicity going for it. There's nothing the matter with C++...except that C is (pretty much) perfect.
That's all true... but I think you're missing something: all of that crazy stuff was added to C++ because it is useful. Of course, any given program will probably only need a small subset of those features, but for the programs that really do need feature X, having it available in the language is a big time-saver.
I've done a good amount of both C and C++ programming, and these days when I need to write in C I generally end up writing a fair amount of code to manually re-implement functionality that I would get 'for free' in C++.
I'd say C++ is a lot like English: a big, overgrown, complicated, mess -- and damn useful if you want to get things done. (If you care more about elegance and simplicity, there is always Esperanto, for whatever good that does you)
Re:This is all true however... (Score:5, Funny)
all of that crazy stuff was added to C++ because it is useful.
If you want crazy stuff that was put there to be useful then why not use perl ?
ducks
Re:This is all true however... (Score:5, Insightful)
Odds are you're ignoring one of the true fundamental virtues of programming: Reusability.
You see, when you have a rock stable ABI, like C affords you, you can create these things called "Libraries", which future products can then depend on, often times even in other languages like Python and Java. And those products can then be depended on, and so on and so forth until you have a whole working system.
I laugh every time I hear someone say something like "Oh C++ has [blah] "for free"". No, you don't have it for free, someone else just coded it, stuck it in your fat C++ library and now 10 years later people bicker about whether it was actually the right approach to standardize so much of this crap, when so many different "standard libraries" are so totally and hopelessly incompatible.
C's standard library is so spartan that you can write your own "standard library" full of goodies like lists and queues and trees and other time savers, and you never have to get into such arguments to begin with.
Or, if you're incredibly lazy, you can use some of the community maintained, amazing C libraries that already exist. My personal favorite happens to be GLib, but anyone who's written enough code in C to have an opinion on the subject has probably written one of their own or come across one they like as well (such as eGLib in Mono, the Apache Portable Runtime Library in Apache, and the list just curls on...)
So yeah, all of that stuff was added to C++ because it was useful... Just as long as you're working on one project, with one version of [OS], with one compiler...
Re: (Score:1)
So yeah, all of that stuff was added to C++ because it was useful... Just as long as you're working on one project, with one version of [OS], with one compiler...
Once again the AC speaks the truth.
Re: (Score:2, Informative)
The key thing here is that C has a well-defined stable ABI that you can use to interact between different versions of a compiler, even different compilers. In C++ it is possible to do this on some level (look at COM, for example), but this does not work at the larger level.
Looking at Qt3 (don't know if they've fixed this in Qt4), but the interfaces don't have virtual destructors. They can't fix this as it will break program ABI, and not having it opens up to bugs (derived destructor not being called when de
Re: (Score:2)
C has this elegant simplicity going for it.
It is neither elegant nor simple, though compared to C++ I guess it would look that way. You've got C's byzantine declarations, cryptic syntactic symbols, pointer madness, goto, the C-preprocessor, unions, pea soup of signed/unsigned integer and float types, implicit conversions and casting, undefined or platform defined behavior, null-terminated strings, and the hack #include instead of a real module system.
C has been best described as a portable assembly language.
Re: (Score:2)
You really should learn C++. Yes, C is really simple, but it's not a good language. At all. Unless you are doing low-level programming, C is probably the wrong choice. I mean, how the hell can you write a program these days without OOP, exceptions, generic containers/algorithms, and user-defined data types? I mean hell, C can't even deal with strings in any reasonable way.
Re: (Score:3, Insightful)
I did learn C++, back in the day when it was a superset...but I stopped, because I didn't really like it.
I mean, how the hell can you write a program these days without OOP,
Honestly... I don't really like writing most things in OO style. I tend to find that most of the time, OOP is just done for OOP's sake, and it's much easier to just program in a procedural manner. A lot of "OO" code is just procedural code in OO clothing.
However, sometimes, it does make sense. Quite a bit of the coding I do is OO code. But that's usually because I'm working with other people who write in