Questions regarding the text in Thinking in C++ by Bruce Eckel

hi frnds,
i have just now started studyin Thinking in C++ Vol. 1 by Bruce Eckel
so i went through the chapter no.1 on Objects... but i m having my doubts in it.... thats why i m here to seek help :)
in chap. 1, i found the following text

Quote:

---

All programming languages provide abstractions. It can be argued that the complexity of the problems you’re able to solve is directly related to the kind and quality of abstraction. By “kind” I mean, “What is it that you are abstracting?” Assembly language is a small abstraction of the underlying machine. Many so-called “imperative” languages that followed (such as Fortran, BASIC, and C) were abstractions of assembly language. These languages are big improvements over assembly language, but their primary abstraction still requires you to think in terms of the structure of the computer rather than the structure of the problem you are trying to solve. The programmer must establish the association between the machine model (in the “solution space,” which is the place where you’re modeling that problem, such as a computer) and the model of the problem that is actually being solved (in the “problem space,” which is the place where the problem exists). The effort required to perform this mapping, and the fact that it is extrinsic to the programming language, produces programs that are difficult to write and expensive to maintain, and as a side effect created the entire “programming methods” industry.

---

i want to emphasize specially on the part in blue... what i have got from it is tht when a programmer gets a problem he has to analyse the problem from two reference points. one from the machine point of view and the other from the problem's point of view.. bt i want to ask two things..
1. by mapping what does the author actually want to say
2. in C does the programmer really need to think totally in terms of machine (i m not really gud in C so this foolish doubt had to come) what about the modern C approaches like 'Objective C??

thanx for ur help :)

1. That it would take a long time to cut your grass with scissors.

2. Not entirely. But in a more procedural manner, which is the only way a computer knows how to operate.

1) Basically translating how you would do it to a way that a computer can do it.
2) Objective C is not modern C. It is a different language. And yes, the programmer does need to think in terms of the machine, if you want. That's a little different with high-level languages such as C++ where you think more about it in an object sense. For example, we have a cat and we tell it do meow; we don't tell the computer to make sounds.

Moved to GD.

This is a lot of puff pastry IMO. The author is just trying to paint a picture about "why" to use some method (I'll assume OO) by claiming it is more conducive to some theoretical standard of natural (ie, not machine like) "problem solving"? Blah, blah, blah. Filler.

WRT to your questions:

1) I suppose "mapping" here would be like proto-implementing the problem as you understand it, in code that you understand.

2) Only in so far as C presents things on a byte literal level very transparently, whereas this is more difficult to perceive in higher level languages. So it may be easier to conceptualize what you are doing in terms of playing with physical memory (part of the machine) than elsewhere. As for "thinking like a machine" -- machines don't think. Thinking about a machine? It's not even that. You're thinking about a language. You could think about some other language. Same difference, more filler.

I don't like OO (or C++) because I think it is somehow "more naturally conducive to problem solving" or whatever Bruce is trying to say there. I like OO and C++ because they provide an expanded set of possibilities within which to conceptualize. They are good ideas, but they have nothing to do with some "less machine like, more human" mentality*. They are just building on more fundamental concepts, which is why "higher level" means something.

That said, I would just skip over Bruce's attempts to construct some kind of philosophical/cog-sci treatise (you are not going to learn anything but propaganda from it**) and deal more with whatever concrete things (here I mean: related directly to C++ syntax) he discusses. It probably is true that C++ is an answer to "the entire 'programming methods' industry" -- just like all the other ones.

* I absolutely promise: there is some book out there on every single existing programming language which makes exactly the same claim: "This language is more easy for humans than other languages because it is more like a language humans would use". Humans made them all. Different strokes for different folks. That's all.

** the only value of which will be regurgitating later in programming forum discussion threads :p

Quote:

---

Originally Posted by capt.jack

1. by mapping what does the author actually want to say

---

In the context of the author text, it is the relationship that a programmer needs to make between a problem and it's solution in the context of a programming language that is an abstraction of the computer model. In a simplistic way:

int i = 13; is a solution that responds to a need to store the value 13 for later use. But your problem bears no resemblance to this need when, for instance you are asked to count 10 numbers after 13. The mapping the author is talking about occurs between your problem (counting 10 numbers after 13) and the realization that you should store a variable with the number 13.

So... graphically:

Problem: Count 10 numbers after 13
Sub-problem: What is the programming language? What is the operating system? (answer these questions)
Mapping: With those questions answered, you learn that a good way to start is to store the number 13 in a variable.
Solution (this is not mapping): int i = 3;

Quote:

---

2. in C does the programmer really need to think totally in terms of machine (i m not really gud in C so this foolish doubt had to come) what about the modern C approaches like 'Objective C??

---

Yes. For any programming language, the solution to a problem involves thinking in that solution in the terms established by the programming language and often also the system the program will be running in.

thanx a lot frnds for ur help :)

yeah.. u all were rite.. here Bruce was advocating the OOP, he was showing the difficulty faced by the programmer when solving a problem in a procedural language and the progress of abstraction...he later on adds:

Quote:

---

The object-oriented approach goes a step farther by providing tools for the programmer to represent elements in the problem space. This representation is general enough that the programmer is not constrained to any particular type of problem. We refer to the elements in the problem space and their representations in the solution space as “objects.” (Of course, you will also need other objects that don’t have problem-space analogs.) The idea is that the program is allowed to adapt itself to the lingo of the problem by adding new types of objects, so when you read the code describing the solution, you’re reading words that also express the problem. This is a more flexible and powerful language abstraction than what we’ve had before. Thus, OOP allows you to describe the problem in terms of the problem, rather than in terms of the computer where the solution will run. There’s still a connection back to the computer, though. Each object looks quite a bit like a little computer; it has a state, and it has operations that you can ask it to perform. However, this doesn’t seem like such a bad analogy to objects in the real world; they all have characteristics and behaviors.

---

he says that

Quote:

---

This is a more flexible and powerful language abstraction than what we’ve had before. Thus, OOP allows you to describe the problem in terms of the problem, rather than in terms of the computer where the solution will run

---

IMO this shows that programming in a procedural language (such as C) the programmer has to deviate from fully dedicating his time on the 'problem at hand' and make him consider the machine behavior while modeling the problem....

so i want to ask tht in OOP languages like c++ is it true that we really dont have to bother ourselves describing a problem in terms of the computer where the solution will run?? or m i missing something here??

thanx for ur help :)

It's merely how you go about it. In C++, you think more in terms of objects and how they interact.
But regardless of language, the problem of design always pops up, in one form or another. You won't escape that.

Quote:

---

Originally Posted by capt.jack

IMO this shows that programming in a procedural language (such as C) the programmer has to deviate from fully dedicating his time on the 'problem at hand' and make him consider the machine behavior while modeling the problem....

so i want to ask tht in OOP languages like c++ is it true that we really dont have to bother ourselves describing a problem in terms of the computer where the solution will run?? or m i missing something here??

---

This is what I meant earlier by propaganda and politics. I agree with this:

Quote:

---

This is a more flexible and powerful language abstraction than what we’ve had before.

---

OOP and C++ provide you with more possibilities to consider. But that does not mean

Quote:

---

Thus, OOP allows you to describe the problem in terms of the problem, rather than in terms of the computer

---

What's the purpose here? Is Bruce trying to help you "Think in C++" or is he trying to sell you products? I don't see anything to do with the former. This is like reading a GM exec describe their latest vehicles by contrasting them with Ford.

Complete drivel:

Quote:

---

The object-oriented approach goes a step farther by providing tools for the programmer to represent elements in the problem space. This representation is general enough that the programmer is not constrained to any particular type of problem. We refer to the elements in the problem space and their representations in the solution space as “objects.” (Of course, you will also need other objects that don’t have problem-space analogs.) The idea is that the program is allowed to adapt itself to the lingo of the problem by adding new types of objects, so when you read the code describing the solution, you’re reading words that also express the problem.

---

Did you learn anything about "Thinking in C++" from this? Like what? Skip the crap, honestly.

Nb, I totally believe it is very important to think in the terms of the language you are using. That means understanding how it works. This kind of prose is not an explanation of anything. It is not even an explanation of the history or philosophy behind C++. Altho Bjarne Stroustrup does sometimes wax prosaicly away along similar lines, AFAICT he has not claimed that he sat down at Bell Labs in New Jersery contemplating how to come up with something that "allows you to describe the problem in terms of the problem, rather than in terms of the computer" (altho OOP does not begin with C++ anyway). It is true that you can and should think of "a problem" or task in terms of objects, but the exact same thing could be said of functions or even variables. This is just tripe and hyperbole.

Bruce seems to have a salesman's prerogative and it infects his writing in a very negative way. There are people like this associated with every language I've ever taken an interest in* and they are a complete drag and deserve to be ignored. Beyond banal. You are wasting your time with this. It is not teaching you anything but dumb ways to look at the world. And, in fact, instilling prejudices and ignorance in C++ newbies that they then deploy like Missionaries -- having never even used another language, because people like Bruce have convinced them that is wrong. The worst connotations of the word "geek". Pure mindless liturgy. Garbage. Skip to the next chapter fer chrissakes!

* except C, actually, for whatever reason (probably they are around somewhere :p). People like Linus Torvalds have said they don't like C++ and "it is a stupid language" (after being hounded by the idiot disciples of Bruce, I believe). Fine. That's how you feel. One sentence. Not page after page after page of BS.

Thanx a lot frnds :)

@MK27

Quote:

---

Nb, I totally believe it is very important to think in the terms of the language you are using. That means understanding how it works. This kind of prose is not an explanation of anything. It is not even an explanation of the history or philosophy behind C++. Altho Bjarne Stroustrup does sometimes wax prosaicly away along similar lines, AFAICT he has not claimed that he sat down at Bell Labs in New Jersery contemplating how to come up with something that "allows you to describe the problem in terms of the problem, rather than in terms of the computer" (altho OOP does not begin with C++ anyway). It is true that you can and should think of "a problem" or task in terms of objects, but the exact same thing could be said of functions or even variables. This is just tripe and hyperbole.

---

Thanx for the insight mate :)

Quote:

---

What's the purpose here? Is Bruce trying to help you "Think in C++" or is he trying to sell you products? I don't see anything to do with the former. This is like reading a GM exec describe their latest vehicles by contrasting them with Ford.

---

hahaha, u nailed the point here :p... i will definitely skip to the next chapter :)

Thanx a ton for ur insights on C++... i believe rather than Bruce himself, frnds from this forum are helping me to 'Think in C++' :)

Quote:

---

People like Linus Torvalds have said they don't like C++ and "it is a stupid language" (after being hounded by the idiot disciples of Bruce, I believe)

---

jokes apart....did Linus really said that abt C++??

Yes. Linus is prejudiced man who thinks C++ is evil. No facts or truths whatsoever, just pure prejudice.

I don't think it's prejudice.

Linus is just and simply an idiot who happens to be a good programmer too.

Quote:

---

Originally Posted by capt.jack

jokes apart....did Linus really said that abt C++??

---

Yep. It was in a mailing list I believe -- the post circulates around. He actually is a little more foul mouthed about it :p

Actually, it looks like he's said this a few times, here's something I found by googling:

Quote:

---

"It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C."

---

I think originally this stemmed from a few people insisting the kernel would be better/easier to do in C++ and acting all bewildered that other people would not want to do that. The real reason that is not the case is because 1) C is more easily portable, and 2) C++ applications require considerably more memory. This was probably a wise decision and the linux kernel would never have had the success it's had -- eg, in the embedded world -- if it were written in C++.

Anyway, I'm sorry about giving Mr. Eckel's quotes a hard time, but honestly: I just see that stuff as leading to a lot of pointless diatribes by C++ users who insist on belittling everyone else, usually because it is the only language they use seriously and hence have no perspective, thus seem to believe everyone else is dumb for not being the same way. That kind of arrogance is not good for anyone. I think Linus is pretty funny there (and responding to an existing situation), but in truth this is a very very silly battle.

C++ is great and it does provide advantages over C, but it is not without flaws either, and it's a mistake to understand it as "obsoleting" C, or fall into the trap of understanding non-OO programming as somehow awkward or arcane.

IMO, the great thing about OOP is it makes it easier to stay organized when doing complex things. I guess that could be seen as a "crutch", but it does not have a downside so who cares. But again, doing without out it is not as painful or difficult as it might seem, if you enjoy programming, have an open mind and a positive attitude.

Quote:

---

Originally Posted by MK27

C++ is great and it does provide advantages over C, but it is not without flaws either, and it's a mistake to understand it as "obsoleting" C, or fall into the trap of understanding non-OO programming as somehow awkward or arcane.

---

The problem is that there is nothing wrong with C++ obsoleting C. C++ can be written entirely in "C style".
The problem is just that there are hurdles to overcome:
- C++ is usually thought of as an OOP language and people who write pretty much just C with it tend to get slammed.
- Economics reasons, because companies are cheap and just don't want to create a C++ compiler for most embedded systems.

So right now we have two similar languages that tend to create a war between people and to cause problems with each other's standards sometimes too.

Anyway, I would call it prejudice because Linus simply dismisses C++ without even considering its advantages over C in situations. Someone who doesn't use the right tool for the job simply because one hates is what I'd call prejudice. Linus simply hates it.
(And I wonder if the popularity of Linux Kernel is due to that it's written in C. I'm not sure.)

Quote:

---

The problem is that there is nothing wrong with C++ obsoleting C. C++ can be written entirely in "C style".

---

Everything is wrong with it as long as there are separate standards. "C style" doesn't have to mean anything other than in syntax. And lots of things look like C syntax.