Comment Re:C++... always the ugly step-kid (Score 1) 661
Almost any language can read like english if done cleverly.
The key point here is "if done cleverly." I always strive to make my C++ as readable as possible. I agree that the average and novice programmer will be in good shape if they can code C++ cleverly. But that is the definition of novice, that you don't know any better until someone shows you or you figure it out with experience. If these people were able to do things cleverly in C++ then they would not be averages in the first place. They would be master level, which we are saying they are not.
I may not have written the sentence you quoted correctly. What I was trying to say is that there are programming languages that are designed such that you can't really write complex lines of code. That doesn't matter for the clever people but it sure matters a lot for novice developers. These languages tend to be wordy. They tend to need more statements of code to accomplish a task. Then there are languages that are designed such that you can write some code that did things you did not realize was going to happen. These languages tend to be terse. They tend to jam pack many operations in one high level statement. This is where people get in trouble with C++. The classic text book example is being given a line of code and asked how many temporaries will be involved and the lifetimes they have. Most people can't do it. Hell, I can't do it all the time. That's the complexity. Operator overloading is a notorious source of these hidden actions. The statement "a = b + c;" seems so innocent. Then, at runtime, the performance comes to a halt. What happened? What is truly going on in that statement? Then on some other project the statement "a = b + c;" seems to produce garbage values for a, if an exception hasn't been thrown already. Upon debugging we find that b and c are being added just fine. OK, what is going on with the return value? What is the return value? Is it by value, a reference, or a pointer to something? What is being referenced here? Are there treacherous temporaries afoot?
Now think of the kinds of statements that even the gurus trip over on! In a language like Object Pascal some of these issues are almost non-existent. That's always a plus, for the novice, the average, and even the gurus.
Nicholas
The key point here is "if done cleverly." I always strive to make my C++ as readable as possible. I agree that the average and novice programmer will be in good shape if they can code C++ cleverly. But that is the definition of novice, that you don't know any better until someone shows you or you figure it out with experience. If these people were able to do things cleverly in C++ then they would not be averages in the first place. They would be master level, which we are saying they are not.
I may not have written the sentence you quoted correctly. What I was trying to say is that there are programming languages that are designed such that you can't really write complex lines of code. That doesn't matter for the clever people but it sure matters a lot for novice developers. These languages tend to be wordy. They tend to need more statements of code to accomplish a task. Then there are languages that are designed such that you can write some code that did things you did not realize was going to happen. These languages tend to be terse. They tend to jam pack many operations in one high level statement. This is where people get in trouble with C++. The classic text book example is being given a line of code and asked how many temporaries will be involved and the lifetimes they have. Most people can't do it. Hell, I can't do it all the time. That's the complexity. Operator overloading is a notorious source of these hidden actions. The statement "a = b + c;" seems so innocent. Then, at runtime, the performance comes to a halt. What happened? What is truly going on in that statement? Then on some other project the statement "a = b + c;" seems to produce garbage values for a, if an exception hasn't been thrown already. Upon debugging we find that b and c are being added just fine. OK, what is going on with the return value? What is the return value? Is it by value, a reference, or a pointer to something? What is being referenced here? Are there treacherous temporaries afoot?
Now think of the kinds of statements that even the gurus trip over on! In a language like Object Pascal some of these issues are almost non-existent. That's always a plus, for the novice, the average, and even the gurus.
Nicholas
