o The self-containedness of objects does make code reuse simpler and less bug prone.
I don't buy that one. A well-designed C module is just as easy to maintain and reuse. Basically classes (without inheritance) are just structs with syntactic sugar (i.e. the first parameter, "this" in C++, is written in front of the function name).
I disagree. With the C++ class the initialization and cleanup are done automatically for you, whereas with the C module the programmer can easily forget to initialize or to cleanup under some particular failure case. With enforced (via private:) opaque data interfaces, the C++ class protects the integrity of the data, whereas with exposed data structures the tempation is there to modify something directly, particularly if you're under time pressure.
I'm not saying that a well-designed C module can't be easily maintained or re-used, but rather that a well designed C++ class can outright remove the possibility of certain types of bugs. Using class-based code, I've sometimes surpised myself at the complexity of programs (e.g. multithreaded, shared complex data structures, communications code) that have worked first time. I consider myself an expert level programmer, but we all create bugs, and anything that can eliminate that possibility is a good thing!
Well, hopefully with the switch case you'd still have procedures to do the drawing rather than in-line code(!), so you'd still have multiple places to change. With the object approach, there's at least the possibility that the change might be implementable in the base class, if the programmer had structured the code to allow this.
Anyway, the example was only intended to illustrate the self-contained nature of an object. Certainly there are different design techniques that are appropriate/beneficial in different circumstances. Having said that, though, I will say that ALL my code nowadays is based on C++ classes. I don't use OOD, and very rarely inheritence other than to extend a class or implement a virtual base class, but the convenience of objects is nonetheless there.
According to your definition there's no difference between procedural programming with good practices such as data encapsulation, and OOP. But there IS a difference... an object is self-contained.
One classic example is a program that draws a bunch of different shapes. With the structure+procedure approach, the code would have to be:
switch (shape.type) {
case Circle: DrawCircle(shape); break;
case Square: DrawSquare(shape); break;
}
With an OOP approach, the object "knows how to draw itself", and the code becomes:
shape.Draw();
See the difference? -- Procedural vs OOP.
What happens to both these code fragments when you want to add support for triangles?
That is the essence of OOP - to keep things self contained.
The above example is also an example of polymorhism, and doesn't need a language such as C++ that explicity supports it. In C the Draw() member would just be a function pointer.
If you just have a data structure and a bunch of procedures that operate on it, then that's just good old-fashioned procedural programming.
How would you implement polymorphism this way? It's impossible, since the caller would have to know which "methods" to call! You HAVE to have the methods as part of the structure in order for it to be a self contained "object".
You'll see that to be OO a language must support certain things like inheritance, polymorphism, run time binding (dynamic binding) and many other fun things that you can't do in procedural languages. C doesn't support any of those.
Huh?
All the early C++ compilers just translated it into C. Evidently C supports C++ features just fine.
Poor design and algorithms is a much greater cause of inefficency than the fit of C/C++ generated code to a processor's architecture.
Anyway, 99.99% of programs don't need anything approaching the full performace of a modern processor, and those that do (such as games, speech recognition, media encoding) are always going to have been heavily optimized anyway.
The article is vapid since it addresses a collection of OOP myths that don't cover the real benefits, and secondly comletely ignores the practical reality that for most people the OOP/procedural choice is C/C++ choice, and that C++ has many features (such as constructors/deconstructors) that while not necessary for OOP, are huge benefits.
Myth: OOP is a proven general-purpose technique
Myth: OOP models the real world better
Myth: OOP makes programming more visual
Myth: OOP makes programming easier and faster
Myth: OOP eliminates the complexity of "case" or "switch" statements
Myth: Inheritance increases reuse
Myth: Most things fit nicely into hierarchical taxonomies
Myth: Self-handling nouns are more important than self-handling verbs
Myth: Only OOP has automatic garbage collection
Myth: Components can only be built with OOP
Myth: Only OO databases can store large, multimedia data
Myth: OODBMS are overall faster than RDBMS
Myth: C is the best procedural can get
Myth: Implementation changes significantly more often than interfaces
Myth: Procedural/Relational ties field types and sizes to the code more
Myth: Procedural/Relational programs cannot "factor" as well
Classic OOP features such as inheritence may generally be over-hyped, but specific cases such as polymorphism are very useful (even if there are ways of doing the same thing in languages such as C that were not designed for OOP).
Some of the major benefit of OOP, and specifically C++'s objects, are:
o It is a clean module packaging mechanism that encourages cleaner interfaces between modules
o It encourages opaque data interfaces (method access vs public access) which results in less bugs
o It makes use of self-initialization/cleanup (constructors/deconstructirs) that avoid a whole slew of programmer errors.
o The self-containedness of objects does make code reuse simpler and less bug prone.
etc, etc.
The guy who wrote the article (and the esteemed Mr. Taco) appear not to have much hands on experience writing OO code.
I also like the "melting pot" aspect, the lack of a social class system (vs England), the lack of stigma of failure (keep trying until you succeed).
Don't get me wrong, it's a great place to live, but there are definite trade offs involved, and having to give up some personal freedoms is definitiely part of the trade off.
Fine. Then back up your claim that America is not as free as other countries by giving me specific examples of how other countries are better.
What's wrong with the examples I already gave?
These are specific differences between the UK and US. Canada also seems much more UK-like in that regard - people are assumed to have common sense.
Sometimes the swings will be big and sometimes they'll be small. But the result is that we continue to gradually move to a point of stasis and stability where everyone's interests are given equal weight.
Yeah, and no-one will feel left out, because it'll be illegal to comment on peoples differences, and no-one will feel stupid because products that people are too stupid to use will be made illegal.
But the fact remains that individuals still have the power to move the system.
That's true of any democracy.
And add to that the fact that this country is the world leader in technological innovation (as well as other things) and I feel I have a pretty good deal.
Really? So why do people need to be told to "Buy American"? Why are sick Americans dying because the FDA won't move fast enough to approve foreign drugs? Ever heard of German engineering, Swiss pharmaceuticals? Europe/Japan both ahead of the US on nuclear fusion research. Japan ahead on robotics.
America has one of the poorest education systems of any developed country. Has a dysfunctional legal system. Has widespread violence. Has widespread drug use, even within high schools...
It's a nice place to live, but you need to open your eyes a little if you think America has the best of most things.
A typical American response - you justify these lack of freedoms as being reasonable rather than viewing them as government instrusion. That way you can go on believing that America is freer than other countries. It's not.
The American approach seems not to expect that people have an iota of intelligence, responsibility or civility, but rather to restrain them by laws under the pretence that it's for their own best interest.
You can argue that you find it reasonable, but it's still there, and not all countries are like that.
The US is undoubtedly a good place to live, but by no means the best.
There are many trade-offs between living in the States and elsewhere, but it appears that most people in the US are unaware of that.
For example, comparing England (where I was born and lived until I was 25) and the US (where I chose to move, and am now a citizen), I'd say that life in the US may be more comfortable, but that quality of life is higher in the UK.
Still, who needs culture when you can drive huge SUVs on cheap gas, and afford giant TVs?
Actually I've always thought of the Bill of Rights (and the whole written constitution for that matter) as more of a negative than a positive. These may have worked a hundred years ago, but nowadays the twisted "letter of the law" interpretations that lawyers can wrangle out of them are part of what makes the US legal system so screwed up.
It really would be a zillion, because so many of them are little things that no-one really thinks about (unless you come from a country where things are different).
Want to have a fire in your yard to burn some brush?
Want to take your dog for a walk off the leash?
Want to have a pool without a fence around it?
Want to tell a risque joke in the office without being fired?
Want to start a small business and hire the best people for the job?
I'm originally from England, and moved to the States about 15 years ago. From what I'd seen and read I believed the US had a frontier spirit of freedom and essentially unfettered capitalism/entrepreneurism, but this notion was dashed very quickly after I came here.
Compared to England, the US has a zillion restrictions on individual freedoms that everyone takes for granted and doesn't question. I guess most countries are the same, but US citizens (which I am now myself) do seem much more naieve in that they seem to believe their country compares favorably in this regard when IMO it does not.
I don't know typically how much the author gets, other than that it's actually very little.
What used to really piss me off at college (in the UK) was when the official text was actually written by the lecturer giving the class, and available only in hardback!
I don't think a book would be chosen as a course book before it was published/priced, so I don't think the publishers are taking direct advantage of that, but of course prices are determined by the target audience.
Incidently I know someone in the used book finding business who say that they (and presumably they're not alone) price books based on their perceived ability of the customer to pay!
Huh? An ordinary out-of-order execution processor with multiple functional units already exploits instruction level parallelism (ILP).
Isn't the whole point of SMT specifically because there usually isn't enough ILP in a single thread to keep the CPU busy...so you expose additional thread-level parallelism to the out-of-order execution engine to hopefully keep things humming?
Hmmm.. it'd be interesting to benchmark different versions of the same code explicitly written to have less sequential dependencies, and see if there's actually a noticeable speed-up. I guess you'd also have to be carefuol to do this on the scale of the processors pipeline.
Do you have any idea if this type of code rewriting/reordering can actually be effective?
I'm sure this'll soon sound like Gates' "640KB should be enough for anyone", but it does seem that for every day stuff processors are getting close to as fast they need be anyway. As long as your game engine can feed the video card at 30fps and you can do real-time video (de)/compression, what next? There doesn't seem to be much on the immediate horizon (like true AI) that'll really demand a lot more CPU power for average Joe.
Yeah, but it wouldn't do much for books that are more inherently read-once (novels, humor, and Hilary Clinton's "Monica sucks").
Perhaps it is a good thing though, since it would mean that read-many books would naturally be more valuable that read-once books, which is the way it should be.
The whole premis of SMT is that even with a modern out-of-order execution CPU that there are hardware resources sitting idle that other threads could use... Is this pretty much unavoidable when executing typical compiled C/C++ code, or is this just because the compiler is doing a lousy job of generating code that gives the CPU enough opportunity to reorder instructions to keep the execution units busy?
Slashdot Mirror
Lisp an OO language? Hmm.. last time I checked it was functional!
o The self-containedness of objects does make code reuse simpler and less bug prone.
I don't buy that one. A well-designed C module is just as easy to maintain and reuse. Basically classes (without inheritance) are just structs with syntactic sugar (i.e. the first parameter, "this" in C++, is written in front of the function name).
I disagree. With the C++ class the initialization and cleanup are done automatically for you, whereas with the C module the programmer can easily forget to initialize or to cleanup under some particular failure case. With enforced (via private:) opaque data interfaces, the C++ class protects the integrity of the data, whereas with exposed data structures the tempation is there to modify something directly, particularly if you're under time pressure.
I'm not saying that a well-designed C module can't be easily maintained or re-used, but rather that a well designed C++ class can outright remove the possibility of certain types of bugs. Using class-based code, I've sometimes surpised myself at the complexity of programs (e.g. multithreaded, shared complex data structures, communications code) that have worked first time. I consider myself an expert level programmer, but we all create bugs, and anything that can eliminate that possibility is a good thing!
Well, hopefully with the switch case you'd still have procedures to do the drawing rather than in-line code(!), so you'd still have multiple places to change. With the object approach, there's at least the possibility that the change might be implementable in the base class, if the programmer had structured the code to allow this.
Anyway, the example was only intended to illustrate the self-contained nature of an object. Certainly there are different design techniques that are appropriate/beneficial in different circumstances. Having said that, though, I will say that ALL my code nowadays is based on C++ classes. I don't use OOD, and very rarely inheritence other than to extend a class or implement a virtual base class, but the convenience of objects is nonetheless there.
According to your definition there's no difference between procedural programming with good practices such as data encapsulation, and OOP. But there IS a difference... an object is self-contained.
One classic example is a program that draws a bunch of different shapes. With the structure+procedure approach, the code would have to be:
switch (shape.type) {
case Circle: DrawCircle(shape); break;
case Square: DrawSquare(shape); break;
}
With an OOP approach, the object "knows how to draw itself", and the code becomes:
shape.Draw();
See the difference? -- Procedural vs OOP.
What happens to both these code fragments when you want to add support for triangles?
That is the essence of OOP - to keep things self contained.
The above example is also an example of polymorhism, and doesn't need a language such as C++ that explicity supports it. In C the Draw() member would just be a function pointer.
If you just have a data structure and a bunch of procedures that operate on it, then that's just good old-fashioned procedural programming.
How would you implement polymorphism this way? It's impossible, since the caller would have to know which "methods" to call! You HAVE to have the methods as part of the structure in order for it to be a self contained "object".
You'll see that to be OO a language must support certain things like inheritance, polymorphism, run time binding (dynamic binding) and many other fun things that you can't do in procedural languages. C doesn't support any of those.
Huh?
All the early C++ compilers just translated it into C. Evidently C supports C++ features just fine.
Poor design and algorithms is a much greater cause of inefficency than the fit of C/C++ generated code to a processor's architecture.
Anyway, 99.99% of programs don't need anything approaching the full performace of a modern processor, and those that do (such as games, speech recognition, media encoding) are always going to have been heavily optimized anyway.
These arn't my myths - they're the list that the linked article was written to address!
The article is vapid since it addresses a collection of OOP myths that don't cover the real benefits, and secondly comletely ignores the practical reality that for most people the OOP/procedural choice is C/C++ choice, and that C++ has many features (such as constructors/deconstructors) that while not necessary for OOP, are huge benefits.
Myth: OOP is a proven general-purpose technique
Myth: OOP models the real world better
Myth: OOP makes programming more visual
Myth: OOP makes programming easier and faster
Myth: OOP eliminates the complexity of "case" or "switch" statements
Myth: Inheritance increases reuse
Myth: Most things fit nicely into hierarchical taxonomies
Myth: Self-handling nouns are more important than self-handling verbs
Myth: Only OOP has automatic garbage collection
Myth: Components can only be built with OOP
Myth: Only OO databases can store large, multimedia data
Myth: OODBMS are overall faster than RDBMS
Myth: C is the best procedural can get
Myth: Implementation changes significantly more often than interfaces
Myth: Procedural/Relational ties field types and sizes to the code more
Myth: Procedural/Relational programs cannot "factor" as well
Classic OOP features such as inheritence may generally be over-hyped, but specific cases such as polymorphism are very useful (even if there are ways of doing the same thing in languages such as C that were not designed for OOP).
Some of the major benefit of OOP, and specifically C++'s objects, are:
o It is a clean module packaging mechanism that encourages cleaner interfaces between modules
o It encourages opaque data interfaces (method access vs public access) which results in less bugs
o It makes use of self-initialization/cleanup (constructors/deconstructirs) that avoid a whole slew of programmer errors.
o The self-containedness of objects does make code reuse simpler and less bug prone.
etc, etc.
The guy who wrote the article (and the esteemed Mr. Taco) appear not to have much hands on experience writing OO code.
Sure OOP is a design technique not an attribute of a language (although some make it easier than others), but your example is bogus.
A data structure is a structure, not an object.
If you add the methods to manipulate the structure (via function pointers if you're using C), then you have an object.
No X = No X Window management.
Is this just meant for (a single) full screen app?
Money, choice, oportunity, lazyness.
I also like the "melting pot" aspect, the lack of a social class system (vs England), the lack of stigma of failure (keep trying until you succeed).
Don't get me wrong, it's a great place to live, but there are definite trade offs involved, and having to give up some personal freedoms is definitiely part of the trade off.
Fine. Then back up your claim that America is not as free as other countries by giving me specific examples of how other countries are better.
What's wrong with the examples I already gave?
These are specific differences between the UK and US. Canada also seems much more UK-like in that regard - people are assumed to have common sense.
Sometimes the swings will be big and sometimes they'll be small. But the result is that we continue to gradually move to a point of stasis and stability where everyone's interests are given equal weight.
Yeah, and no-one will feel left out, because it'll be illegal to comment on peoples differences, and no-one will feel stupid because products that people are too stupid to use will be made illegal.
But the fact remains that individuals still have the power to move the system.
That's true of any democracy.
And add to that the fact that this country is the world leader in technological innovation (as well as other things) and I feel I have a pretty good deal.
Really? So why do people need to be told to "Buy American"? Why are sick Americans dying because the FDA won't move fast enough to approve foreign drugs? Ever heard of German engineering, Swiss pharmaceuticals? Europe/Japan both ahead of the US on nuclear fusion research. Japan ahead on robotics.
America has one of the poorest education systems of any developed country. Has a dysfunctional legal system. Has widespread violence. Has widespread drug use, even within high schools...
It's a nice place to live, but you need to open your eyes a little if you think America has the best of most things.
Forget the hideous sins or oral and anal sex, there are even places in the US where drinking is illegal, even dancing for that matter.
I used to have a Canadian girlfriend, and from what she says, it seems they're WAAAAY more relaxed about sex up there than people are in the States.
A typical American response - you justify these lack of freedoms as being reasonable rather than viewing them as government instrusion. That way you can go on believing that America is freer than other countries. It's not.
The American approach seems not to expect that people have an iota of intelligence, responsibility or civility, but rather to restrain them by laws under the pretence that it's for their own best interest.
You can argue that you find it reasonable, but it's still there, and not all countries are like that.
The US is undoubtedly a good place to live, but by no means the best.
There are many trade-offs between living in the States and elsewhere, but it appears that most people in the US are unaware of that.
For example, comparing England (where I was born and lived until I was 25) and the US (where I chose to move, and am now a citizen), I'd say that life in the US may be more comfortable, but that quality of life is higher in the UK.
Still, who needs culture when you can drive huge SUVs on cheap gas, and afford giant TVs?
Actually I've always thought of the Bill of Rights (and the whole written constitution for that matter) as more of a negative than a positive. These may have worked a hundred years ago, but nowadays the twisted "letter of the law" interpretations that lawyers can wrangle out of them are part of what makes the US legal system so screwed up.
It really would be a zillion, because so many of them are little things that no-one really thinks about (unless you come from a country where things are different).
Want to have a fire in your yard to burn some brush?
Want to take your dog for a walk off the leash?
Want to have a pool without a fence around it?
Want to tell a risque joke in the office without being fired?
Want to start a small business and hire the best people for the job?
...
I'm originally from England, and moved to the States about 15 years ago. From what I'd seen and read I believed the US had a frontier spirit of freedom and essentially unfettered capitalism/entrepreneurism, but this notion was dashed very quickly after I came here.
Compared to England, the US has a zillion restrictions on individual freedoms that everyone takes for granted and doesn't question. I guess most countries are the same, but US citizens (which I am now myself) do seem much more naieve in that they seem to believe their country compares favorably in this regard when IMO it does not.
I don't know typically how much the author gets, other than that it's actually very little.
What used to really piss me off at college (in the UK) was when the official text was actually written by the lecturer giving the class, and available only in hardback!
I don't think a book would be chosen as a course book before it was published/priced, so I don't think the publishers are taking direct advantage of that, but of course prices are determined by the target audience.
Incidently I know someone in the used book finding business who say that they (and presumably they're not alone) price books based on their perceived ability of the customer to pay!
Huh? An ordinary out-of-order execution processor with multiple functional units already exploits instruction level parallelism (ILP).
Isn't the whole point of SMT specifically because there usually isn't enough ILP in a single thread to keep the CPU busy...so you expose additional thread-level parallelism to the out-of-order execution engine to hopefully keep things humming?
If you think SMT is different, please explain!
Hmmm.. it'd be interesting to benchmark different versions of the same code explicitly written to have less sequential dependencies, and see if there's actually a noticeable speed-up. I guess you'd also have to be carefuol to do this on the scale of the processors pipeline.
Do you have any idea if this type of code rewriting/reordering can actually be effective?
I'm sure this'll soon sound like Gates' "640KB should be enough for anyone", but it does seem that for every day stuff processors are getting close to as fast they need be anyway. As long as your game engine can feed the video card at 30fps and you can do real-time video (de)/compression, what next? There doesn't seem to be much on the immediate horizon (like true AI) that'll really demand a lot more CPU power for average Joe.
Yeah, but it wouldn't do much for books that are more inherently read-once (novels, humor, and Hilary Clinton's "Monica sucks").
Perhaps it is a good thing though, since it would mean that read-many books would naturally be more valuable that read-once books, which is the way it should be.
The whole premis of SMT is that even with a modern out-of-order execution CPU that there are hardware resources sitting idle that other threads could use... Is this pretty much unavoidable when executing typical compiled C/C++ code, or is this just because the compiler is doing a lousy job of generating code that gives the CPU enough opportunity to reorder instructions to keep the execution units busy?