Who's Afraid Of C++?

The reason computers -- never mind programming -- are so obscure to most people is a learning curve which appears dangerously steep stands between the ordinary user (who knows how to use a mouse, and which button turns on the monitor) and writing even "Hello, World." Prolific reviewer chromatic reviews here Who's Afraid of C++?, a book intended to flatten that curve.

Who's Afraid of C++? author Steve Heller pages 486 publisher AP Professional rating 8 reviewer chromatic ISBN 0-12-339-97-4 summary In his unique approach, Steve Heller presents programming concepts and information as a conversation between teacher and student.

The Scoop Breaking with traditional lecture-on-paper format, Heller demystifies computers, programming, and C++ for absolute beginners. That's right -- he recruited a full-fledged novice user, capable of little more than e-mail and word processing, and turned her into a decent programmer while reviewing this book. (She became Mrs. Heller shortly after that.) Any computer owner with time, the ability to follow directions, and the willingness to learn could also become a programmer.

The resulting text is more of a collaboration, or a commentary. Steve, the author, presents his information and then Susan, the novice, interrupts to ask questions. The big gamble is that her questions are the same that the average reader would ask. It largely pays off, only occasionally belaboring a point. (To be fair, it could also be called 'reinforcing a point.')

What's to Like? Heller's writing is informal, but precise. Some might find it chatty, but beginners will find it more comforting than raw technical prose. His flow of topics makes sense (and does not copy the "Chapter two is everything to know about types, and chapter three is all about flow control" scheme other introductory teaching books steal from K&R). Little prior knowledge is necessary. Before actually programming, the book explores raw hardware, answering such questions as "What happens when you execute a program?", "What's a register and why is cache important?", and "How does source code turn into a running program?"

Chapters tend to explain only one issue in detail -- how to use functions, for example, or the basics of a class. Heller states his objectives up front, and sticks closely to them. Each chapter has two sets of exercises, one in the middle and the other at the end. Answers follow, along with more dialogue. It's not enough simply having one correct bit of code, without someone to explain why it is correct, and why some common answers aren't complete. This decision pays off.

Though discussing weighty technical matters, there's a sense of general friendliness. With well-chosen metaphors (datatypes are kinda like odometers), occasionally goofy examples (a pumpkin-weighing-contest control program), and plenty of conversations when things get heavy, C++ isn't so scary after all. Credit Susan for much of this. If you find yourself thinking along the same lines as you study, you'll make it.

What's to Consider? The book covers about half of a reasonably paced introductory Computer Science course. It also predates the ANSI standard and the STL, though a fair treatment of the latter would easily double the size. Readers who finish the book and the exercises will be fully capable of producing their own useful programs, but will need additional information on common libraries, algorithms, and more object-oriented programming. They'll also have avoided some of the traps awaiting the unwary novice, as Heller practices a fairly tight methodology.

More technical readers already familiar with programming and at least one C-based language might find the pace slow and the extra explanations unnecessary. Heller's target audience is definitely the neophyte, not the experienced developer. The latter might question the subject matter covered. Why build a vector class instead of using C-style arrays? Why not C-style strings? I suspect the author is more concerned with helping his students avoid the kind of pitfalls C++ was designed to work around. It may not be the traditional approach, but it's valid and it will produce decent programmers, who can learn C++ on its own merits.

The Summary Steve Heller's pulled off quite a feat -- producing a book that assumes very little, yet produces people who understand programming. There's not as much information presented as in a "Learn the Language in X days/weeks/hours" book, but it's more accessible and better geared to a true beginner. For a gentle and effective introduction to programming and C++, give this book a try.

The CD-ROM contains complete source code of all program listings, as well as the excellent DJGPP compiler (yes, it's for DOS).

Read this book online at www.steveheller.com or purchase it at Fatbrain.

Table of Contents

1. Prologue
2. Hardware Fundamentals
3. Basics of Programming
4. More Basics
5. Functional Literacy
6. Taking Inventory
7. Stringing Along
8. Down the Garden Path

1. Tying Up Loose Ends

Comments

Is that line trademarked?

[(void*)]

I can see it now: a whole line of educational guides ala IDG's "Dummies guide" series:

• Who's afraid of Unix?
• Who's afraid of Relativity?
• Who's afraid of Motorcycle Maintanence?
• Who's afraid of Sex?

Yes, let the money roll!

It is irrational fears week!

[BilldaCat]

C++ is SCARY.

There's a Reason Why.

[ReconRich]

Hopefully this book addresses (suitably) the reason why people have good reason to fear C++. In many ways it is a language in which you must know everything before you know anything. The complexities of how constructors/destructors interact when returning objects (for instance) is very confusing and one of the reasons why it often takes many years of C++ programming before a programmer is truly competent. If this book effectively addresses educating people in the "hard stuff" its good. If not, well its not.

-Rich

this reminds me of another book...

[EnderWiggnz]

it was called "The cartoonist Guide to Computers" - i cant rememeber the author right off....

My cousin that went to lehigh gave it to me when i was 12. apparently, the book was being used by lib. arts students to get a grasp of the technical courses.

It was presented in a humorous, light, yet incredibly informative way... It traced the history of computing, from abacuses to differential engines, and made the whole thing very interesting.

And, it had a good level of detail in it. It wasnt a gloss over the topic and pretend they've covered it. It went into boolean and gating fairly extensively.

Not bad for a cartoon book.

Sounds good

[seizer]

Beginning to program is a wildly confusing experience - or at least, it was for me ;-) This book sounds like it'll help people along greatly.

However (there's always a however):

There is absolutely no substitute for the hacker-type mindset - the obsessive compulsive (say it ain't so) need to explore a system for yourself, to produce programs which should be beyond your capabilities - and which were, until you put your mind to them. If someone doesn't have that raw curiosity and the need (the NEED) to know everything about a system, then they're never going to be anything more than a "quite good" programmer.

--Remove SPAM from my address to mail me

Initial steps into programming

[Dungeon Dweller]

It's not the initial step into programming that is difficult, it is mastering it. Give me an hour, a good library, and a reasonably intelligent person who has a fairly open mind and high school trig, and I'll have them writing simple games. That doesn't mean that they'll be analyzing algorithms in big-O notation and parsing b-trees. I think that the biggest pitfall for users is viewing computers in the wrong light (Impossible machine) and being unwilling to apply any basic knowledge (when I was a kid, we were booting atari's up in computer labs in my elementary school, and writing programs in BASIC. I know that this happened all across America. Now, you ask someone to type in a password, and it's too much for them to handle, and click on the "send" button, why does it have to be so hard?

<cough> I'm sorry?

[Biff Cool]

With well-chosen metaphors (datatypes are kinda like odometers)
Ignoring that this is a simile and not a metaphor, does that make a lick of sense to anyone? Datatypes are kinda like odometers? Fingers are kinda like distributor caps. I thought I knew C++ but obviously I missed something in my studies

How is a raven like a writing desk

Conscience is the inner voice which warns us that someone may be looking.

You've opened a Pandora's Box

[TheNecromancer]

I hope you people realize that this topic is just going to start a verbal war between the C++ purists, the Perl purists, the Java purists, the Pascal purists, ad infinitum.

IMHO, it doesn't matter what language you program in(I progam in several, including C++), the important point is that you understand the basic tenets of programming, and can use these concepts to program in any language! If this book can help people learn that, more power to them!

Re:You've opened a Pandora's Box

[JoeWalsh]

IMHO, it doesn't matter what language you program in(I progam in several, including C++), the important point is that you understand the basic tenets of programming, and can use these concepts to program in any language!

I agree with you. I want to point out another problem, though. In addition to the problem of thinking like a programmer, I find that it's harder to get people interested in modern languages because it's generally much more difficult to do fun graphical things with them.

Take the first language I learned, for example: Atari BASIC. I learned it using the slim little book with the silver cover that came with the Atari 400 my parents bought me. After reading that little book (I don't have it with me, but it was about 100 pages long, with large type and many illustrations), I was able to use BASIC to draw on the screen. I could use FOR...NEXT loops to cycle colors among many lines to get a neat effect. I could actually move a dot around on the screen using my joystick.

That felt powerful. To make a program that responds graphically to my input was just mind-blowing at the time. I quickly wrote a little game, and - WOW - I felt like I could do anything if I just put in the time.

Compare that with today's computer books. Friendly or no, the books teach you how to write little boring text-based programs, for the most part. Maybe they teach you how to use a RAD tool to make a WIMP interface, but still the program itself is just a "get some text input from the keyboard, process it, and output some text" program. That is boring!

It'd be nice to write some graphics routines for C that are as easy to use as the old Atari BASIC graphics commands (SETCOLOR; COLOR; PLOT X,Y; DRAWTO A,B) and input commands (if not joystick, at least some info on using a keyboard to do game input).

Take those commands and some basic housekeeping code, then distribute them with a book on learning C. The book could still focus on the processing and structure stuff, but if something was thrown in there that would give the person some ability to make something fun and exciting after learning just a little bit.

That's a tremendous incentive for neophyte programmers, in my opinion. It not only gives them some warm fuzzies when they see it, it's also a lot more exciting to show someone else than any of the text based stuff.

Re:You've opened a Pandora's Box

[jilles]

Programming is about much more than a language. Haskell is indeed nice, but quite useless to learn if you don't intend to use it.

Assuming we have a complete newby at hand who wants to become a skilled computer programmer, there are several things we need to teach him:
- What is a computer, how does it work in general. Toying around with assembly can be usefull at this stage. It's also important to learn about bits & bytes and other computer jargon.
- As soon as you got a clear image of how a computer works, it is time to learn a language. Prerably, a simple language is chosen (e.g. basic) but if necessary you can also take something more advanced.
- Standard libraries. This is the part that takes the longest. To avoid that you reinvent the wheel it is essential that you know your tools. If your are doing C++, knowledge of the STL is essential. When doing Java you need to be able to find usefull classes and components in the various frameworks

Of course you can do these things in parallel. A good programmer can switch languages easily. I know I can learn C++ pretty quick since I understand all of the underlying principles. I have programmed before in other languages (C, Java, Basic etc.) and know that my biggest obstacle in learning C++ won't be the language but learning to use the stl efficiently.

In addition to the above, it is also usefull to learn about different styles of programming. Most novice programmers start by learning how to do procedural programming. At this point in time, however, there is really no excuse for a good programmer not understanding OO. If you want to laugh, try examining the first Java code of people who used to code in C or basic. I had the privilege of doing so some time ago. The poor fellow had crammed his entire program into a single class. He used the class variables as global variables and was simply applying the tricks he had used in pascal before. Also he was mostly ignoring the classes provided by the Java API. Strangly enough his program sort of worked.

After mastering & understanding procedural and OO programming you might look a bit further: generative programming, functional programming and logic programming good starting points. Also it is usefull to learn about program design methods. If you are doing OO, look at "Design Patterns" and learn how to use UML (not just the class diagrams).

Further expertise can only be gained by practice. There's no way you can do all of the above in a few weeks or even months. Books such as discussed in this article are a nice starting point for anybody new to programming, to bad it is limited to C++.

Coding
class IMAMonkey {
public static void main(String ps[])
{
System.out.println("I'm a coding monkey");
}
}

can be done by pretty much anybody but fully understanding what it does and why it is written down like that takes a bit longer.

Re:You've opened a Pandora's Box

[jilles]

I half agree,

I learned Gofer myself in the first year of university (very similar to haskell). Though it is a very fun language to learn and use, I don't think of it as essential material for programmers. The programming community for functional language is quite small (for various reasons), and unless you are actually going to use it I wouldn't recommend spending much time on it to beginning programmers.

I also think it is a mistake to think that programming is still about algorithms. I can't remember the last time I implemented something like quicksort. All these things are available in a reusable form these days. Although it doesn't hurt to about algorithms, I think things like program structure and design are much more important.

Needless to say that I think that CS students, who are not just code monkeys, should know how to work with other languages than just Java/C++. Haskell is a good choice, but also prolog, lisp, etc. might be sufficient. The idea is not to teach those students a particular language but to learn them different ways of solving problems. It is also a great way to learn to understand the limitations of certain programming languages (C for instance). The more languages, the better. Each language has particular features which are interesting to learn about.

Re:You've opened a Pandora's Box

[Arandir]

Then just write a turtle graphics class/library for C++, and Voila!

UCSD Pascal, that old standard of beginning programming before Turbo Pascal hit the scenes, had turtle graphics as a library, and it did wonders for teaching programming (I was a proctor at UCSD). Instant visual feedback is a powerful teacher.

So go write a turtle graphics class for C++ and get teaching!

This looks like a good thing =:-)

[drenehtsral]

I remember when i was learning to program (somebody shoot me, i say that a lot, and it was only 13 years ago) there were a lot of books like that (although often using basic or pascal) and i got all of them out of the library again and again until i'd sucked them dry of information. They were informal, not too intimidating, fairly friendly, and most of all, they weren't snobby. SOme even had cool cartoons =:-)
This has been missing in the age of the booming tech economy and the whole "professional image". I think the world needs this sort of a thing, so that novices can begin to experement, because it's fresh minds that generate a lot of the innovation, and i think that extending a bridge to users is a good thing.

Learning at the lowest levels first?

[thogard]

One of the early books I read involved describing an ALU as a bunch of boxes that could add other boxes. It was written in the early 1960'sand had lots of drawings taht look like departmental mailboxes and how data access worked with index registers and the like. Today most people would consider it a waste of time but I'm not sure. I know how computers operate down to the gate level. I can optimize things well enough. Most of the books I read in my early programming days wouldn't even be considered programming books by todays standards but they worked well for me. I guess thats why I get to explain to the new CS grads why we don't do some things some ways since the computer doesn't like doing trillions of calculations when it has other thigns to do too.

Re:Learning at the lowest levels first?

[drenehtsral]

Hehehehe =:-) I think they had that book at the public library. I remember getting it out when i was a kid (or at least a book that had a similar explanaion method...) I think the one i was thinking of was a book that one was supposed to teach onself FORTH with. I gave up on that mainly because my FORTH interpreter on my Franklin Ace was hardly what you would call stable.

I still remember the little boxes hopping along the conveyer belt towards the ALU where they would be shelved until an operator came along =:-)

Learn C++ in Five Minutes!

[bgs006]

Hey excited Netizens! Wanna learn a difficult programming language in just five minutes?! Wanna earn gobs of money from desperate start-ups who will throw any sort of bribe at you to work in their tiny, cramped, dungeon-like cubicle!? Well stop wishing and start learning with my new seminar!

I know what you're thinking: there's no way I can learn C++ in five (count 'em) five minutes. Well stop being such a doubting loser. Here's what you do:

Step One: On the qualifications section of your resume, write, "I know C++." Feel free to put other things, such as "I speak thirteen different languages," "I've slept with Pamela Lee Anderson", and of course, "I am omnipotent."

Step Two: Get Hired!

Step Three: When your manager approaches you to actually work on a C++ project, immediately run to your nearest Asian immigrant and pay him 50 cents an hour to do the project for you! Don't feel bad, your manager did the same thing to get in his position!

Step Four: Watch as the money, women and strange magic powers are bestowed upon you.

It's just that simple!

-Bgs006
LostBrain

Re:Learn C++ in Five Minutes!

[Signal 11]

Step Five: Get introduced to RealWorld(tm).

Step Six: Asian dude goes to work for SGI, pulls six figures. Your project is delayed. Senior Engineer asked you about progress, realizes you're full of it, informs senior management, shafting follows.

Step Seven: Get desperate, spam hundreds of newsgroups with "make money fast!" schemes to help you get out of debt.

Step Eight: After changing several ISPs and diffusing three different mailbombs, reality dawns on you - there is no fast way to do anything.

Step Nine: go back to school, get a degree, do things the way everyone else does.

Step Ten: get a job, life, girlfriend, family, wife, kids..

Step Eleven: Retire, spend 3 years in retirement, die.

What's a "steep learning curve"

[ChrisWong]

That phrase always bugs me. The obvious first take would be to graph the independent variable (time) on the X axis, and learning on the Y. But then that would give any "hard" subject a shallow learning curve. Someone once tried to explain it to me by using a Z axis, muddling everything up even more. Is there an official interpretation, or did an economist invent this graph?

Re:What's a "steep learning curve"

[jemfinch]

The X axis is the usefulness of what you can do in the language; the Y axis is is the amount of knowledge of the language you have learned thus far.

A subject with a steep learning curve, therefore, is a subject where much learning is involved to do relatively simple tasks.

Jeremy

Re:Real Challenge is turning CLI graphical :P

[eellis]

Imagine connecting a few icons with a wire to pipe stuff between them, then filling in parameters in a popup window for each of the icons.

What, you mean like LabView ? It's a graphical programming language - mainly intended for controlling lab equipment, but surprisingly general purpose.

Edric.

Larry Gonick

[FascDot Killed My Pr]

He's written a bunch of other "Cartoon Guide to..." books as well. The best are his history books (two books each split into around 8 "volumes").

Book 1 is "big bang" to "the fall of Rome" (as I recall). Book 2 backs up a little bit and changes geography to look at the history of China. I'm expecting Book 3 any time now since it's been several years since the last book appeared.

Book 1 was mostly familiar to me--the same-old "first the tribes, then the Greeks, then the Romans" stuff (although told in a very entertaining way). Book 2, though, was totally new: We don't get much non-European history here in the US. No wonder we don't understand "those Chinese".
--
Compaq dropping MAILWorks?

Education good!

[JMZorko]

I am completely, 100% in favor of educating more and more people regarding the power of the personal computer, even programming -- heck, _especially_ programming. Books like the Dummy books are absolutely brilliant -- they pull back the curtain and show the reader what's really going on. It also shows them that they can do it, that they're not the 'dummy' they maybe thought they were.

The power of the personal computer; the power to develop their own solutions, should not be confined to the rarified realm of programmers and engineers. _Everyone_ can benefit from this, and the more this information is brought out into the open, the better. I recently bought a friend of mine a "Visual BASIC for Dummies" book. He was, at first, a bit fearful of it, but once he started, he started really enjoying it. HE called me once about a bug, and when I showed him what the problem was (i'm certainly no VB expert, I work in C++ primarily), he immediately _understood_ it, saying something like "Of course! I checked everything else but that." One could see his esteem growing; it made me feel really good.

Regards, John

Re:C++ as a teaching language/programming obscure?

[keffy]

Personally, I think C++ is a bad teaching language because computers don't think in objects. They think in memory locations and in blocks of code

Computers "think" in both. They also think in registers and opcodes. They also think in electrons.

All of these are abstractions at some level of what's really going on. There's no inherent reason why your favourite level of abstraction (memory locations and code blocks) is any better a place to start learning than the object level -- and a few reasons why it's worse. The way people think is closer to the object level (though still quite far).

And discrete math?! Honestly, I think you could make a better case for cooking classes. The practical experience of trying to follow well-written and poorly-written recipes will help a novice programmer out a heck of a lot more than a detailed understanding of set theory ever could.

I agree.

[Dungeon Dweller]

Too many programmers get stuck in a mode of not actually knowing what's going on with their programs. They come to a university and get smacked in the face with actually having to UNDERSTAND THEIR OWN CODE. The object oriented paradigm is useful in its own right, but learning how to manipulate objects is not learning how to program. Ada is a good intro language because of many factors. For one thing, you have to know what you are doing to do it. If you don't, you're not going to do it. It teaches scope properly, and gives a new programmer a good feeling for how the code flows and what is actually going on. I have heard Ada decried on here as being "cumbersome," if you are a good coder, it isn't, because the only things that you have to do extra in Ada, are the things that you should be doing in C/C++. In other words, the only thing that you have to do extra in Ada, is be good enough to write the program that you are writing.

I've read it. In fact I started out with it.

[Narcopolo]

And I have to say it's very good. I think that C++ is actually an excellent language to begin with, as people tend to think in objects. The book is very good at showing instant results, in fact it starts out with strings. This lets people see immediately practical uses for what they are doing, and feel some accomplishment.
Most of the C books I've read don't even try to get to strings until halfway through, and make it a rather complicated introduction by making you understand data types and arrays first. Mr. Heller's point is that, with C++ at least, you don't really have to know what's going on with strings to use them, and that it's easier to understand the fine details of things once you've become familiar with them through usage. He does that a lot in the book.

My C teachers and classes have always seemed extremely dry after being introduced to C++ by Steve Heller. If anyone is curious about learning to program, I wouldn't hesitate to recommend this book as a starting point. There's also a follow-up book, "Who's Afraid of More C++", also working with Susan.

Mr. Heller also seems rather accessible be e-mail, but please don't hold him to that because I said so.

-N.

Steep learning curves...

[vanwestr]

...are exactly what you want! Ideally, your learning curve is a theta function: zero time goes by and you have full knowledge. Where did this phrase (and its negative connotations) come from? A shallow learning curve means learning forever and never knowing anything! Sorry... slightly off topic.

Re:Steep learning curves...

[anatoli]

You mean delta function, don't you?</nitpicking>
--

Re:Steep learning curves...

[anatoli]

Oh my. You are right. Delta is derivative of theta. How dumb of me.
--

C++ is a horrible introductory language

[schala]

It's so horrible, in fact, that I can't even think of a worse one. You've got all the worst features of bad languages rolled into one -- a massive amount of confusing syntax, (extremely!) complicated semantics, almost always utterly unhelpful error behavior, and an extremely high barrier to entry even to get programs to compile, much less run, to say nothing of them actually working correctly.

While it is certainly an extremely powerful tool, it is also a gigantic hodgepodge of different programming paradigms. You can be object-oriented, you can be procedural, you can have it look like assembly code; this is flexibility, but only with a corresponding reduction in accessibility.

Now, I don't really know if there is a perfect language for introductions to programming. The much-maligned Pascal is a good language for learning structured programming, which makes it a good step towards C and then C++. Functional programming is easier to pick up but requires a certain amount of intellect to grasp the ideas of abstraction that it relies upon. (I happen to think that since understanding abstraction is critical to being a good programmer, everyone should do some functional programming.) For that I would choose Scheme in one of its reduced flavors. Scheme also has the advantage of having simple syntax, though it seems a bit unnatural to non-engineering types. For object-oriented instruction, I think Java is a good choice, for a bunch of reasons, which I won't enumerate since they will be obvious and I'm tired of typing.

It makes me cringe when I see a new "Learn C++ in 24 hours" title on the bookshelf, because I know those texts will screw people up. Learning to program is a challenge enough without having to learn C++ at the same time.

-m

Re:C++ is a horrible introductory language

[sethg]

You've got all the worst features of bad languages rolled into one -- a massive amount of confusing syntax, (extremely!) complicated semantics, almost always utterly unhelpful error behavior, and an extremely high barrier to entry even to get programs to compile, much less run, to say nothing of them actually working correctly.

Don't forget the linker....

Non-inline function definitions belong in the .cpp file ... unless they're template definitions, in which case they belong in the .h file ... unless they have the export keyword, but I don't know how many compilers support that. Constants are defined in the .h file, but static variables and have to be initialized in the .cpp file. And every file has to be wrapped in #ifdef ... #endif to prevent it from being #included twice.

And when you're dealing with the Microsoft compiler, the compiler sends as little information to the linker as it can get away with ... so link-time errors, rather than providing clues about where to hunt for the problem in source code, refer to object files, pre-compiled header files, and munged function names. (Is g++ more helpful in this respect?)
--

Re:C++ is a horrible introductory language

[Thagg]

I wonder if the book teaches the correct pronounciation of C++; it's not "see plus plus" but "see double-cross" [original, I believe, by Rob Pike) thad

Re:C++ is a horrible introductory language

[Hard_Code]

It makes me cringe when I see a new "Learn C++ in 24 hours" title on the bookshelf, because I know those texts will screw people up.

It scares me how much stuff might actually be running out there written by people that actually thought they could "Learn C++ in 24 hours". *SHUDDER* "Learning" C++ is a labor of *years*.

Re:C++ is a horrible introductory language

[Arandir]

And you advocate Java as an introductory language instead?

Java is so close to C++ that they might as well be different dialects of the same language. Java is a bit more "pure" OO while C++ is a bit more "down in the guts", but overall, they would be identical for new programmers.

C++ would make a great first language. First, they need learn only one language, instead of one for beginners, another for intermediate, and finally C++ for advanced. Two, the potentially confusing stuff in C++ can be left for later. They are not required to program. Classes can be introduced after mastering structured programming, and templates, STL and generic programming can be introduced after learning OOP. Third, teaching students to use proper coding styles makes any language easier.

I think this arguing against C++ as a beginners language arises out something other than it's difficulty. No proper programming language can be taught in 24 hours. There may only be 24 hours of lecture time, but this does not count the weeks spent on homework and labwork.

"Practical C++ Programming" is a great book for learning C++, even if one is not a programmer. Coupled with a comprehensive C++ reference, it would make a nice text for a beginning programming class.

Re:C++ is a horrible introductory language

[cburley]

Anyone ever wonder if Yoda wrote Lisp?

Wonder not do I.

Wrote Lisp Yoda did not.

Yoda Lisp did write!

Yoda character Lisp program generated by!

"No try is there. Only do."

;-)

Re:C++ is a horrible introductory language

[X]

Nothing against C++, but equating the tool is laughable. Syntactically, they are similar, but if you've used both, you'll know that they are different. If nothing else having non-pointer based objects, no garbage collection, and templates significantly changes how one does programming.

Realistically, if they were so similar, Java wouldn't have had much of a chance of being successful.

Re:C++ is a horrible introductory language

[X]

Ease up on the language wars eh? Every language has it's pros and cons. C++ wouldn't be my first choice as a teaching language, but there are worse options. Hell, there was a time when Ada was popular. Fortran 77 was also popular.

Everyone want's to tout their favourite language (and your advocacy of Pascal is a good example), but in reality, programming languages are not the essence of what you teach to programmers anyway. Heck, most of my comp. sci classes in University would introduce a language to you during the first week, expecting you to be able to use it well enough to cover the material in the course. This was really not a problem, because in the end design techniques don't necessarily require you to excercise esoteric language features (they're mostly there to frustrate developers and compiler designers ;-).

For the complete novice

[aleksey]

I agree with many other posters who've suggested that perhaps C++ is not the optimal language for teaching complete novices. And apparently so do quite a few smart people at Rice. That's why they wrote How To Design Programs. It's a rather good beginner text, IMO.

Optimization

[Dungeon Dweller]

Higher level languages produce slower programs. While I like Python and do all of my web scripting in Perl, if one truly wants to get the most out of their programs, they will optimize in assembly. Faster processors are not a good excuse to blow simple, good computer science out the window.

Re:C++ as a teaching language/programming obscure?

[roman_mir]

By learning Assembler, Prolog, Lisp and C++ all computer language concepts and paradigmes would be covered, but what about really understanding such paradigms as data structures, networks, ai, multiprocessing and scalability?

Re:C++ as a teaching language/programming obscure?

[Mendax Veritas]

One should be able to program in the `problem domain' rather than the `solution domain', and object-orientated languages such as C++ are a step towards being able to do that.

Nonsense. C++ mostly differs from C in two ways: (1) trivial syntax, like writing object.method(...) instead of method(&object, ...); and (2) excessive complexity (the various gotchas related to constructors, function overloading, exceptions, templates, etc.). There is very little that C++ gives you that wouldn't be done better with a good module system plus true polymorphism (neither of which exists in C or C++; their idea of "modules" is limited to static functions and C++ namespaces, and C++ polymorphism is badly restricted by its association with class inheritance. Templates are a better example of C++ polymorphism, but they can be inefficient if you don't know how to use them well, and require recompilation every time you need to apply them to a new type).

If you want to see what can really be done in the way of helping programmers to think about the problem rather than all the annoying details of the solution, look into languages like Smalltalk, Erlang, and OCAML, all of which are vastly better than C++.

Complete Idiot's Guide to Multiprocessing called..

[TeknoHog]

..Who's Afraid of the Big BeoWulf?

;-)

Re:Can someone give 1 good reason to use C++ over

[Biff Cool]

Scalability

Conscience is the inner voice which warns us that someone may be looking.

Really?

[Dungeon Dweller]

You really think that you couldn't get someone to type.
void main()
{
seed(time);
random();
...

yeah, chunky pseudocode, but like, I think that I could get a monkey to type something akin to that in an hour if I was sitting with them.

Re:Can someone give 1 good reason to use C++ over

[Remote]

I think I can give you one. When you program in C++ you can do anything you can do in C plus (no pun intended) a lot more. You can write functions and/or tools in a style that touches and feels the hardware. Then you can objectify things so as to have much cleaner (thus safer) code in upper levels.

This is one approach, the one I regretably followed. I just mentioned that way of doing things because you sound a bit like a die-hard C programer, and maybe you'll feel more comfortable with this small subset of C++. The best path of course would be to think different (tm) from the very beginning, using the STL and programming generically when there is a need.

But the real good reason to use C++ in my opinion is its power and flexibility (that multi-paradigm thing, if you like long words). I don't think there is any other language that can be so easily adapted to one's personal needs or the needs of a given project. Even if your need is to be close to the machine. And the tradeoffs are small too. With today's compilers (I use Borland 5.0 and GNU gcc) there is little difference in the code produced. Some (very credible) people claim that in some circumstances C++ will produce even smaller and faster code than C, but I haven't been able to duplicate that experiment. :)

This is all pretty obvious and well discussed in many places, there must be someone arguing the same thing, even as I type, so maybe I missed the point in your question.

C++ is NOT the best langage to learn on

[Dacta]

Why on earth would anyone try and teach a newcommer to programming something like C++? It's my view that any langage based on the C syntax is not suitable for beginners.

Pascal, Python, maybe Java are all great languages for a beginning programmer.

I'm sure that it is possible to teach some people C++ as their first language. I'd argue that they could have learnt something like Pascal in less time, and have a better understanding of it. C/C++ syntax is too weird for a beginner, and you need to understand too much about memory & pointer to do anything useful. I mean... no native string type in C? How stupid is that when you think about it?

Re:C++ is NOT the best langage to learn on

[seanson22]

If you proceed from the assumption that the best first programming language is that which is easiest to learn, then Pascal and Python and Java are wonderful ideas. If your goal is to understand programming and its relation to the inner workings of the computer, then C, no matter how long it takes, is going to be far superior in that aspect.

Re:C++ is NOT the best langage to learn on

[kali]

Why on earth would anyone try and teach a newcommer to programming something like C++? It's my view that any langage based on the C syntax is not suitable for beginners.

Why, exactly? The C syntax is used by C, C++, Java, and Perl, which are arguably the most common languages in use today. Why would you teach beginners something that they would never use, rather then something they would use everyday as programmers? What syntax do you find easier to understand?

Pascal, Python, maybe Java are all great languages for a beginning programmer.

Umm... Java is pure C/C++ syntax.

C/C++ syntax is too weird for a beginner, and you need to understand too much about memory & pointer to do anything useful.

This is simply not true. I worked as a TA for an intro programming class taught in C++, and they never even mentioned pointers. The only discussion of memory was when I would explain to the students why their programs crashed when they went beyond the bounds of an array. Otherwise, they were perfectly functional without any such knowledge.

Of course, to be competent in C++ requires a thorough understanding of memory issues, but we're talking about beginners here.

I mean... no native string type in C? How stupid is that when you think about it?

You're absolutely correct, it is stupid. However, since the topic here is C++, and C++ does have a native string type, what the hell is your point?

Re:C++ is NOT the best langage to learn on

[JoeWalsh]

It's my view that any language based on the C syntax is not suitable for beginners.

I've tried to teach many people to program. The first time I was called upon for this was when I was 13 and one of my mom's friends had purchased a Commodore VIC-20 thinking she and her husband could automate their business with it. My mom sent me over to this woman's house to teach her how to program BASIC so she could automate the accounting system. Yeah, that was just tons of fun. Fortunately, she gave up after a few sessions. And I got some nice home-made cookies out of it, so it wasn't a total loss for me!

Anyway, I've been informally teaching people to program, with varying degrees of success, ever since. In all this time, perhaps the most important thing I've learned is that the biggest hurdle potential programmers face is learning to think programmatically. Or, as someone else said, to think like the computer.

It doesn't matter whether I was teaching someone to program in BASIC, Pascal, C, or Java, the stumbling block was the same. I'm not a professional instructor, so I wasn't able to get some people over that hump. But those who did get over it found that, within a short while, they didn't need me to teach them anymore. They could pick up the rest on their own. (Of course, those who didn't get over the hump didn't need me anymore either, so either way I was out of a job!)

I believe C++ would be just as appropriate for this as anything else, but as with BASIC and a host of other languages, people who only know C++ tend to have a harder time understanding how the computer works. C++ adds a layer of abstraction that, while useful to the experienced programmer, doesn't help neophytes to learn other, non-object-oriented languages.

Still, I'll probably add the book in question to my collection of "how to program" books. I'm always interested in seeing how people try to teach one another (unless it's a "learn X in Y hours/days/weeks" book or any title that insults the purchaser's intelligence ("...for Dummies," "Complete Idiot's guide to...", etc.) - I avoid all of those titles like the worthless detritus that they are).

Re:C++ is NOT the best langage to learn on

[Kinthelt]

It's my view that any langage based on the C syntax is not suitable for beginners.

It's not exactly the syntax of C that is difficult for beginners, moreso it is the low-levelishness of C that makes it hard to learn. Beginning programmers need to learn how to formulate a plan and write it out (make algorithms), they do not need to worry about shooting themselves in the <insert body part here>.

Pascal, Python, maybe Java are all great languages for a beginning programmer.

Pascal was supposed to be a teaching language and does the job very well, I agree. Never used Python, but I've also never heard anything bad about it. Java is very nice with its inability to do serious harm, its garbage collector is helpful too.

I'm sure that it is possible to teach some people C++ as their first language.

Believe it or not, it's possible to teach C++ like Pascal. You just need to avoid everything that resembles C. Introduce the for, if, while, String class, cin, cout and basic math functions, and you're in business.

Re:C++ is NOT the best langage to learn on

[Hard_Code]

Why would you teach beginners something that they would never use, rather then something they would use everyday as programmers?

Because the point of *teaching* is for the student to *learn* the general concepts. That's why there are such things as intro courses. Because shoving info into the brain != learning.

Umm... Java is pure C/C++ syntax.

Um...wrong. Sure, superficially, a lot of the common flow control and scoping constructs use the same tokens, like braces and parenthesis, and some of the operators are the same. But that is where it stops. Method, variable and class declarations and definitions are very different. Java has no operator overloading or pointers, so all those operators go out the door. It has some unique keywords and operators and concepts. There is no such thing as structs or memory allocation, and besides a handful of primitives, everything else is a full-fledged object.

This is simply not true. I worked as a TA for an intro programming class taught in C++, and they never even mentioned pointers. The only discussion of memory was when I would explain to the students why their programs crashed when they went beyond the bounds of an array. Otherwise, they were perfectly functional without any such knowledge.

And likewise you can "learn" to drive without knowing with the lines on the road or signs mean. I would really like to be present to see how exactly C++ was taught without the mention of pointers or memory, and whether the "teaching" was actually resulting in learning and understanding, or just rote copying by the students. IMO to learn and use C/C++ *correctly*, an understanding of memory allocation, and pointers is fundamental and prerequisite. Arrays and objects themselves don't make sense in a C++ world without mention of memory allocation and pointers, and I can only guess that students were just blindly trusting the instructor that things worked the way they did instead of understanding. Learning C++ as a beginning language is like learning to drive a normal car, on a tank. Sure, in *general* things will be the same: you still need to know how to accelerate and decelerate and turn. But all the mechanisms will be different: you will have complicated levers and guages; and you will randomly blow up or smash stuff without understanding.

Of course, to be competent in C++ requires a thorough understanding of memory issues, but we're talking about beginners here.

Still, IMHO, the risk of being distracted by confusing high-level stuff, and the "scare" factor, indicate to me that C++ is not the ideal beginning language. I played with BASIC and officially "learned" on Pascal. Sure I don't use those today, but Pascal was really useful in easily cementing the general concepts.

Re:C++ is NOT the best langage to learn on

[shren]

Perl? Perl?

Unless you already happen to be a programmer, Perl syntax makes zilch sense and gives you horrible habits if you ever want to learn any other language. It's not a good place to start. I love perl, but it's just not a starting language.

Re:C++ is NOT the best langage to learn on

[Karellen]

It's not stupid. It's just doesn't make sense as far as C goes.

C is simple and closely tied to most computer architectures. All C language constructs and operators are designed to be directly implementable in only a few instructions on most CPUs. Hence the basic data types. char, int (various sizes), float (various sizes) & pointers. All CPUs pretty much implement them directly, and not a whole lot else.

Anything else is implemented by (standard) library functions.

You want to implement a string type? That's a job for the library, not the core language. (as it is in C++). How to do that in C? Without C++ classes, and the safety they allow you to implement (destructors, copy constructors) how would you do it in C?

C was written to fulfill a specific purpose. And did it well. And to _not_ have a native string type was (IMO) an _intelligent_ decision based on what C was designed to do, and how it was designed to go about doing it.

K.

Re:C++ is NOT the best langage to learn on

[aphrael]

Umm... Java is pure C/C++ syntax.

Er ... a *simplified* c++ syntax, i'd believe. But there are all sorts of things you can do in c++ that you can't in Java. For example:

template
int & bar::operator +(int& ref) { /* */ };

I got your C++ right here-THE LARS-O-MATIC

[Lord Kano]

/*This is my Lars-O-Matic gibberish generator
©2000 Lord Kano

Although this code is GPLed, I request that if you make any modifications based upon it, please give me a little credit
for writing the original code.

This code was written to be as easily portable as possible. It was written on an old Power Mac 7300/180, but it should
compile and run under just about any OS.

The LarsSpeak array is comprised of real phrases from Lars, as well as a some that I made up but still sound LarsLike.
*/
#define __LARS_ULRICH DickHead
#define ___METALLICA Sold_Out_Commercialized_Whiny_Babies
#include
#include
#include
#include
#include

using namespace std;

string phrase[19];//Array of Lars Speak

//function prototypes

void setphrases(void);//Fill the phrases array with Lars Speak
void larsspeak(int);//Send to the screen, int times, an example of Lars Speak

//end function prototypes

int main(){
srand(time (0));//seed the random number generator with the value pulled from the clock.
setphrases();

char ch;

string filename;
string *fn;

fn =

while (filename != "quit"){//Repeat this loop until the user enters quit at the following prompt

cout > filename;
cout c_str());//Open the filename the user specified at the above prompt

if (!mystream.is_open()) {
if (filename != "quit") {cout "FILE NOT OPENED ERROR!";}//If we can't open a file that was specified by the user, first check to see if we were told to quit, if not give an error.
goto here;
}

while (mystream){//get each character sequentially
mystream.get(ch);
if (ch == '\n'){//if the character is a newline, LARSIFY
cout " ";
larsspeak(1);
goto here;
}

if(mystream) cout ch;
if (ch == ' '){//if we encounter a space
if (!(rand() % 4)){//once out of every four times, LARSIFY
larsspeak(1);
}
}
here:;
}

mystream.close();//when we're done, close the file for good measure.
}

return 0;

}

void larsspeak (int i){
for (int x = 0; x i; x++){
cout phrase[(rand()%19)];
}
}

void setphrases(void){
phrase[0] = "um, ";
phrase[1] = "oh, ";
phrase[2] = "well, ";
phrase[3] = "James says, ";
phrase[4] = "according to my lawyer, ";
phrase[5] = "like, ";
phrase[6] = "uh, ";
phrase[7] = "ya see, ";
phrase[8] = "I mean, ";
phrase[9] = "I know how to get onto AOL, and I will say that I have used AOL a couple of times to check some hockey scores, but I'm no expert at this stuff, ";
phrase[10] = "ya know, ";
phrase[11] = "OK, ";
phrase[12] = "basically ";
phrase[13] = "and this is really the simplest way of saying it, ";
phrase[14] = "I think ";
phrase[15] = "well, it's like this,";
phrase[16] = "for one reason, and one reason only, ";
phrase[17] = "I'm sorry, all of a sudden your mind goes blank, ";
phrase[18] = "like I said before, ";
}
//Thank you

A less horrible introductory language..

[TeknoHog]

At the risk of starting a flame war, here goes: Python.

The syntax is very intuitive: blocks are denoted by indentation, nothing has to be declared. It is very easy to just start hacking on an idea without knowing much Python, learning from the docs while proceeding.

Although not a 'real' compiled language, I'd recommend it as the introduction to ideas of programming. After that, learning other languages is more or less a matter of syntax only. Plus, it great for all kinds of scripting.. :-)

Re:A less horrible introductory language..

[4of12]

I'm trying Python out right now trying to teach my 11 year old nephew programming. (Meanwhile, yes, at work, I struggle with C++ and hope to get it to "do what I mean" in a few months...sigh)

The nice thing about Python is that it's so easy and intuitive that I can teach it as I learn it, not being a proficient Python programmer by any stretch of the imagination, but having plenty of background in C.

There are two things I'd like to see, though:

• a nice fat stack of simple-minded viewgraphs that even an 11 year old can understand (the usual intro's are slanted towards folks with programming experience in another language, like C.) So far, the closest I found was Josh Cogliati's page
• a nice easy way to get some graphics done so I would not be limited to text applications. An earlier poster mentioned this as well - that

  excitement(Basic, Atari, 1980) > excitement(Python,Windoze, 2K)

  Like many kids, the games he plays on his computer these days are so flashy, boomy and interactive that his first attempts with a programming language can not hope to compete with "Joystick controlled maneuvering of a skateboarder with sound effects and moving, pseudo 3D scenery."

Any suggestions for addressing either of these 2 issues would be most appreciated.

Re:A less horrible introductory language..

[Karellen]

One thing I've never liked about what I've read about Python - indentation (whitespace) is part of the semantics. That just makes me shudder.

If I indent a line of code with a tab, and another line of code with 8 spaces, are they part of the same block? Or do I have to use 8 tabs to have the same indentaion as 8 spaces? What if I'm using an editor that has tabs every 4 spaces instead of 8?

IMO C/C++/Java's {/} sytax is much better, and Pascal's begin/end isn't far behind (if a little long-winded)

What does perl use?

Re:A less horrible introductory language..

[TeknoHog]

Just use one kind of indentation. I can't imagine anyone wanting to type 8 spaces at each line.. ;-) besides, as oinkoink pointed out, there are good editors with autoindentation (I personally use jed).

IMHO indentation is more intuitive than {} or whatever. When I read a long text (not necessarily code) there are often paragraphs that are indented for clear distinction from main text. This is how human perception works - large variations are more obvious than single punctuation marks. Imagine Ayer's Rock being separated from the surrounding desert by 12-pt {} only, instead of 'indentation'! 8-)

Re:A less horrible introductory language..

[ChadN]

Python has a "tabnanny" feature which helps make sure that tabs and spaces aren't mixed ambiguously. A decent editor (like Vim or Emacs) will keep this sorted. You can also specify that tabs are other than 8 spaces (command line or .pythonrc). I've written thousands of lines of Python, for a large application, and this has never been an issue (contrary to what another poster has said, Emacs CAN be reliably used to adjust block indentation; just specify a block and indent, instead of line by line.)

Finally, there are tools provided in the standard distribution to autostrip #} and #{ block identifiers (which the Emacs mode recognizes). So think of the block identifiers as optional. The indentation requirement is not onerous to those who accept it, and is actually a plus.

I find Python to be a very elegant solution for many of my needs (GUI, signal processing, and mathematical exploration), and people in the lab can understand much of my code, without EVER having looked at a Python tutorial or reference (all except the GUI stuff :).

Re:If only he had chosen a _real_ language

[Mendax Veritas]

I can't stand Perl, so I won't try to defend it. However, Grim Metamoderator is correct that C++ isn't really a good OO language.

I still want to address your points individually, though, because a lot of what you're saying is not really Perl-specific and, I think, represents a very limited understanding of programming.

1. "Perl is slow." Well, that depends. For many tasks, Perl (or Python, etc.) is fast enough. Then again, for a very complex application, it can be very challenging to get good performance out of C++, because one means of controlling complexity is to develop high-level abstractions and then write most of the program using those abstractions. If the abstractions are poorly chosen, or poorly implemented, performance suffers badly. This is not a point in C++'s favor, since it forces you to do a lot of annoying, low-level dirty work yourself (thread interactions, memory management, etc.). Anyone who thinks C or C++ is necessarily fast ought to spend a week using Windows 98 on a slow Pentium. In contrast, a well-designed higher-level language (e.g. Erlang or OCAML) supplies you with a set of well-implemented abstractions proven over many years of use in a wide variety of programs.

2. "Perl makes inefficient use of resources." Same argument as #1, really; CPU cycles (speed) being just one example of system resources.

3. "Perl is hard to maintain." Well, I can't help but agree with that one. Then again, I think C++ is pretty hard to maintain, too. Its simplistic static type system and association of polymorphism with class inheritance tends to result in extremely brittle designs that don't age well.

4. "Perl is unnecessary." I don't think it's just Perl you're objecting to here; it sounds like you think every program, including simple shell scripts, should be written in C++. I have to say that sounds kind of crazy to me.

5. "C++ programming is a valuable skill." Well, that's true today, but who knows -- five years from now, it might be yesterday's language, replaced by whatever hot new language (or paradigm) comes along. It's happened before, you know.

Problem is with colleges

[Sebastopol]

Object-oriented programming design is a great way to organize a problem into manageable, scalable abstractions. Everything you learn in college about the virtues of OOP is well founded, would anyone here disagree?

The problem is C++. It's not a very good OOP. Would most people here agree its a pretty harsh hack of the C syntax? When compared to (IMO) the mother of all OOPs: LISP?

Students that never learned C++ on their own learn it in college, usually from a TA. Now I'm not knocking TA's, but they usually have zero practical experience with large projects. And to compound the problem, they learned their C++ programming skills from... ANOTHER TA! And so on. See the problem? (And the worst part is: would you want to hire someone who just learned how to code in C++ during their 2nd or 3rd years in college! Companies do. I want to hire someone who's been programming before they were pubescent!)

So not only is the OOP paradigm lost by lame C++ instruction (here's printf, write, fwrite, and 'cout ', gee, that makes sense...), the entirety of programming education is at risk by the lack of truly knowledgable instructors. And then these kids go out and program for a living! No wonder there is so mush bullshit buggy code in the commercial world.

Ok, sorry about the rant. But any attempts to teach any computer concept with C++ seems to me to be hopelessly flawed and will end up doing more harm then good. Teach with LISP from the top and C from the bottom, and assembly from the real bottom.

I agree with the 'problem' and 'solution' domain approach. OOP on top so that there is flexibility and scalability in the entire design; procedural C on the bottom for portability and high-performance.

C++ -- the great hack, the facilitator of even greater hacks -- has done horrors to the world that will take decades to undo.


---

Re:C++ as a teaching language/programming obscure?

[Mendax Veritas]

I take all your points about C++, but I don't feel that they really prove my original point to be `nonsense': to some degree, C++ is closer to the problem that C.

I really don't think so. C++ does have a few improvements over C, such as templates, exceptions, overloading, and the ability to declare variables anywhere in a function. But it also adds tremendous complexity and lots of nasty gotchas that make it actually harder to use (for anyone less than an expert) than C. It's true that for someone like me, C++ is preferable, because I know the language better than just about anyone I've ever met, and over the last dozen years I've developed a number of useful techniques for dealing with (and avoiding) C++'s problem areas. But it's a bitch of a language to learn well, which I think outweighs its advantages overall, especially when there are a number of vastly superior languages out there (again: Erlang, Smalltalk, OCAML, and probably others. You mentioned Haskell, which has its pluses but in its own way is nearly as hard to learn well as C++.)

Re:C++: The PL/1 of the 90s. B*L*O*A*T!!!

[HiThere]

Having used both PL/1 and C++:
PL/1 was lots easier to learn. What it did was more consistent. It's real problem was that the compilers were too large for the Apple II - CP/M generation of machines until fairly late in their cycle, but Basic, C, and Pascal could run on all of them. (And to go back a bit further, it wouldn't fit on a PDP/8.)
Of course it didn't help it that IBM owned the language, and wasn't interested in microcomputers.

I rather liked PL/1. I also like Ada95. Neither is bloated in comparison with C++. Both are rather logical and easy to learn.

OTOH, neither PL/1 nor Ada95 have a good adaptation to GUI's. Java does, but it's still v. slow (when last I checked a few months ago).

What currently seems to me as the best choice it to use Python or Ruby or some such and recode the time critical routines into C. C++ could probably be used here, but C is still lots more portable (there doesn't seem to be any rule as to how the C++ compiler mangles the routine name).

What the ACCU thinks of this book

[codemonkey_uk]

If you want a second opinion, the Association of C & C++ Users has reviewed this book twice:

• http://www.accu .org/cgi-bin/accu/rvout.cgi?from=0ti_w&file=w00201 1a
• http://www.accu .org/cgi-bin/accu/rvout.cgi?from=0ti_w&file=w00136 5a

The second of the two reviews is also a review of The C++ Training Guide by Steve Heller. There is also a review of both "Who's Afraid of More C++?" and "Who's Afraid of Java?" here.

Heller is a prolific author, but the ACCU only recomend his book on Motif.

Thad

You should start with C not C++

[MongooseCN]

One thing alot of new people don't understand is how linear programs run on a computer. C is very linear and would show this well. C++ will just make things more confusing for a new programmer.

C++ also seems to be turning into a buzzword now. "OOh its C, but its got a ++ after it, it must be better!" Well I have a new language called D+=2 clearly it's far superior to C++.
My question is, why don't people use C instead of C++? I find it hard to hide from myself that a program runs linearly and try to hide that fact behind classes, inheritance and all those other C++ features. A program can be designed and run better than C++ in C, but C++ has more hype running around it.
Giving a carpenter a nailgun doesn't make him a better builder than someone with a hammer. He can just screw things up faster.

Re:You should start with C not C++

[dingbat_hp]

C++ will just make things more confusing for a new programmer.

That's a good point, but I'd argue two cases against it:

• C is a hard language for beginners to learn. Manual pointer handling, 50 ways to shoot your feet off, confusing "=" and "==". None of these trivial language-specific coding issues are things that a learner of "programming" should be troubled with. These days there isn't even any need to - there are plenty of alternatives.
• C programmers make terrible C++ programmers. Ask anyone who works with, and designs in, a real OO environment. OK, obviously some C programmers make the leap, but the vast majority still think in C terms, and never get properly into the OO mindset.

C++ also seems to be turning into a buzzword now. "OOh its C, but its got a ++ after it, it must be better!"

Now ? That's a problem from ten years ago. I barely notice it these days -- in fact, few non-geeks still remember there was a C beforehand.

a program runs linearly

They don't.
Programs haven't run linearly for a decade; since windowing systems became commonplace. Machine code might still run linearly, but any macroscopic non-trivial "program" these days, even in VB, needs to worry about asynchronous events, let alone threading models. This is all horrible and complicated, and best handled by good class structure in a good run-time environment.

Re:Can someone give 1 good reason to use C++ over

[Temporal]

There are tons of reasons. Here's an interesting one:

In the program I am writing, dynamically allocated data deletes itself when you are done with it, the same way java does. You just have to use my smart pointer class in the place of regular pointers. They work exactly the same syntactically, but they keep a reference count for whatever they are pointing to and free it once nothing is pointing to it anymore. No more memory leaks!

Now, this is not ideal for all situations, but it is something you just can't do easily and transparently in C. In my project, it has been incredibly useful, as alot of the code involves distributing and re-distributing resources to many distant places, and it is not always clear who's job it is to free some memory. But with smart pointers, it is not a problem.

Also, when using smart arrays, I can stick in bounds-checking for debug builds, which is pretty useful.

------

And apparently this book gets you chicks too.

[devphil]

That's right -- he recruited a full-fledged novice user, capable of little more than e-mail and word processing, and turned her into a decent programmer while reviewing this book. (She became Mrs. Heller shortly after that.)

So, all I need to do is pick my target babe^H^H^H^H new user, get her to read this book, and she marries me? Man, a whole "Nutshell" series of books could come out of this...

How to Get Girls

[IHateEverybody]

Heller demystifies computers, programming, and C++ for absolute beginners. That's right -- he
recruited a full-fledged novice user, capable of little more than e-mail and word processing, and turned her into a decent programmer while reviewing this book. (She became Mrs. Heller shortly after that.)

So that's what I've been doing wrong! No more singles bars for me, from now on I'm teaching programming to cute female newbies until I find Ms. Right.

Re: Ada, and CS programs in general.

[harmonica]

Ada is a language to do /real/ software engineering, and it is used in many projects where human lifes depend on the programs. Usually, relatively many people with much experience work on those projects, producing very few lines of code (per time unit). For people to really learn it, they must spend a lot of time getting into software engineering plus all the other stuff you'll have to learn with any programming language. So, Ada may just not be what you're looking for. Doesn't mean it doesn't work for someone else. CS programs that merely teach PHP and C are a horrible idea to me. Any decent CS student will learn either one easily once they got the concepts behind software development. And hopefully they will have developed the skill to go around the usual traps created by C, assembly and all the other languages that don't offer advanced features.

With all due respect

[Dungeon Dweller]

With all due respect, someone who is clever with assembly will always be able to outrun an optimizing compiler.

Re:With all due respect

[scheme]

Hmm...you're wrong one a couple of points.

Register selection is very easy in most cases. Also, I can't think of a machine that has 10 registers,

That may be true for x86 and CISC processors but most RISC processors have significantly more than 10 registers. HP's PA-RISC has 31 integer and >10 floating point, the MIPS have 32 integer and 32/16 floating point, the SPARCs, alphas, etc. also have at least 20 integer and 10 floating point registers. Then there are more obscure stuff like the AMD29k which had 128 registers. The IA-64 architecture has more than 50 registers, I believe.

anyway the NP-Complete problems require N! time

NP complete problems are solvable in non-polynomial time hence the NP designation. c^n where c is constant is non-polynomial hence NP problems can have solutions that are O(c^n). NP-complete problems are a subset of NP problems hence there can exist NP-complete problems that take O(c^n) time.

How did I improve it? I used SIMD instructions (MMX). I was able to get a 4x increase in speed. *NO COMPILER COULD EVER DO THIS*.

Just because you've never encountered a compiler that can't do this doesn't mean that one doesn't exist.

The problem you've given is just an application of vectorizing the algorithm. Several fortran compilers exist that do this. However they were for architectures like the Cray which had SIMD instructions 15 years ago. SIMD is relatively new to the x86 and ppc architectures so naturally compilers for those architectures haven't been able to take advantage of this. Plus vectorizing compilers are hard to make.

Anyway, that's why you're wrong :)

And thats where you're wrong. :)

A little background on myself

[Dungeon Dweller]

Ok, I've been programming since I was about 4. If you count all of the scheme variants and such, I know about 50 different programming languages, and can list them by name. 2nd year at WVU has a programming language theory course in which students have to be fairly proficient in about 10-15 languages. All freshman engineering students are required to take a class in C++ and Matlab. The main reason for the Ada curriculum is textbooks and compilers related to the resolve project. Also, WVU is switching to a JAVA based curriculum in the next 4 years. I just happen to like Ada. If schools teaching C/C++ stuck with enforcing good programming practices, then I would say go for it. I would say go with C, though. C will let you get away with a lot of junk though, and many students could slide through their classes without really understanding the concepts. So, if you want staff checking to make sure that the students typecast, hell, go for it. As for me, I want my students to learn good computer science.

Oh yeah.

[Dungeon Dweller]

At WVU we don't teach "languages," we teach concepts. All of the perl expertise in the world doesn't make you worth a damn as a computer scientist if you don't learn the fundamentals of computer science. You need to learn the math, big-0 notation, algorithms, theory. These are the important things. If you want someone who is capable of writing mediocre programs, WVU is not the place for them, we want people capable of writing only the best.

Re:Oh yeah.

[Bedemus]

Well, I see I hit a nerve with my previous post, so I'll be brief, and hopefully this will sting a bit less.

Nobody said that you need to teach Perl, but rather that in the course of teaching the concepts, you use as a testbed for said concepts a language which doesn't obfuscate the concepts.

When a language causes your students to focus more on semantics of a language than on what they're actually accomplishing -- when a student spends more time trying to get the peculiarities of a given language's syntax down, rather than focusing on what they're really *trying* to do, then you've done your students a disservice. Much worse so, in fact, when in the end they've learned the semantics of a language that, while admirable in its structure, is not nearly so marketable as the same concepts taught using another language.

For instance, so long as an individual understands the concept of a linked list and how it can be employed to offer fine-grained control over an array of structures, does it matter that the user implements every array structure as a linked list rather than using a language that provides such basics as a builtin? I'm speaking abstractly here, really, the same argument could be employed for any number of other concepts.

In the end, while computer science may seem a complex science to you and some of your students, there is no reason to treat it as such a complicated subject. Programming, in fact, any act of creation, should above all be something enjoyed, either in the act itself, or after the creation is complete. Treating the subject as something so cut and dry (good_programmer = math + bigO_notation + algorithms + theory;) does a disservice to the occupation.

Finally, I and many others like me I'm sure find it insulting that you suggest that WVU wants only the people capable of writing the best programs. First, as worded, it makes it sound like you forget that your job is to take a person and make them the type of person who can program well. Second, your implication that a programmer who hasn't attended WVU (or any college, perhaps) is somehow *not* capable of writing a program to put your graduates/instructors to shame, is extremely narrow-minded.

There are individuals for whom such things come naturally, and your statements sound more like an advertisement or justification for your university's existence rather than any substantial reason why your program produces better programmers. Years of refinement or not, there is no best way to teach computer science to someone, no more so than there is any one best way to solve a particular programming problem.

Re:Dissing PL/I

[dingbat_hp]

Am I old or something ?

I've written a little PL/1, ported a _huge_ Algol 60 program to FORTRAN, and coded a fair bit in object Pascal(s), C++ and now a little Java. (CORAL, Eiffel and a few weirdies too.)

PL/1 was bloatedness incarnate. It was bloated in places that didn't need to be bloated, and added nothing for their being bloated. The whole thing looked like bad editing on the output of a roomful of skilled language designers; no one piece was bad, but there was no reason why there had to be quite so many ways to do something. No-one had stood up in the meeting and said "Why are we adding that feature ?".
A mil-spec Cadillac, if ever there was.

C++ is ugly, but it's ugly for a reason. It's an evolutionary answer to the problem "Take the One True Geek Language and stick objects onto it". It's still one of the world's all-time greatest Hacks, and I still hate it.

The idea of teaching newbies C++ as a first language horrifies me; not because it will produce bad C++ coders, but because it's a very slow way of teaching people advanced OO concepts. It's also going to drive away an awful lot of people who simply don't have the dedication to suffer through their thousandth bad pointer error.

Why not teach Java ? It has a good a claim to being a "competent teaching language" as most others, it gives immediate and satisfying results (unlike some scripting platforms), and it has commercial relevance.

Re:C++ as a teaching language/programming obscure?

[Samrobb]

C++ programmers won't use a pointer even when it's the best solution.

Please - stop generalizing. I'm a C++ programmer; I first learned C++, not C. I'm perfectly comfortable with pointers, and willing to use them when it makes sense. I'm also perfectly willing to write a perl script, or a VB test harness, or a bit of assembly if I need to. I can work in C if need by, though I prefer the C-subset of C++ for a number of reasons. I've seen poorly written C programs; would you like me to take that as an example of exactly how suitable C is as a development language?

Languages are tools. If C allows you to express an idea simply and effeciently, then it gets the job done. C++ is better than C in expressing some concepts and ideas. Perl is better than either in other arenas. A good developer understands this, and works to identify the strengths and weaknesses of the tools, so that s/he can use the most suitable tool for a task. A poor developer learns one tool and winds up with a "All I have is a hammer, therefore everything must be a nail" mentality.

But I would not under any circumstance introduce someone to programming through C++. BASIC, maybe.

Any possible brain-damage that I perpetuate in my programs can be traced back to my BASIC heritage :-)

Async event handling

[dingbat_hp]

I'm curious as to what sort of apps you write, if you haven't yet found C to be painful ?

In recent years, most of us are writing desktop apps for windowing systems. These need to respond to mouseclicks, messages from other windows, system or network events, all sorts of things. Now this is still hard in an OO environment, but it's an absolute nightmare in C ! Anyone remember first edition Petzold, and the horrors of the Windows message loop ? Nasty, nasty days, and we had the program bugs and hangs to prove it.

Writing good GUI event handlers is still hard, but with an OO environment it only needs to be done once, by the environment author, then just subclassed by the application author.

Those of us not writing GUI apps are probably mainly writing back-end objects. I dont know where you'd begin, trying to serve one of potentially 50 different method calls, all from C.

No, no, not the comfy LISP !

[dingbat_hp]

There are problems with C++, certainly, but I hate to think of any problem where the solution is LISP !

I'd rather write Smalltalk than LISP, and that's saying some...

Obsolete version problem

[Animats]

This is an old book from 1996, and it describes C++ before the ANSI standard. That's not good. That was a bad period in the history of C++. The meaning of templates was still being thrashed out, exceptions didn't work right in most implementations, and horrible macro hacks from the pre-template/exception era were still in use. The language has improved since then. You don't want to learn, or teach, the 1996 version of C++.

As for the language itself, I have lots of criticisms; see comp.lang.c++.moderated.

Re:If only he had chosen a _real_ language

[drivers]

The poster you replied to is a pretty lame attempt at putting down Perl if favor of C++. He does a disservice to C++ by putting forth lame arguments.
I know C++ and Perl, and you are wrong about C++. When I first learned associative arrays, it was in Perl (actually it was in awk, which does it almost the same way as Perl, and from which Perl derived those features).
When I first learned C++ (in 1991), C++ was a very different language than it is now. However, as I have learned by reading Bjarne Stroustrup's "The C++ Programming Language, Special Edition", which is brand new, with the features that have been added to the language since then, and especially the Standard Template Libraries, you can create associative arrays in C++ quite easily. And you can create associative arrays of any kind of C++ object using STL.
I still think Perl would be my first bet for writing a CGI script (the guy you replied to is flamebait to say that Perl isn't good for anything), but judging from the comments in this forum, most of the detractors of C++ don't really know what the language is capable of.

start with assembly (not a joke)

[TheDullBlade]

The first serious learning experience I had with programming was in assembly language, and I can't imagine a better start.

First of all, it teaches you how memory really works. Many people who start off with BASIC or some other learning language have a lot of trouble with things like C pointers. After learning assembly, C makes perfect sense.

It's simpler than you might think. One of the things that catches people in most languages is the way that you have to define the machine you're working on: you make names for everything. In assembly, the names are optional. You have a machine, with registers and addresses, and you can know exactly what it does with those.

The syntax is also simpler. Instead of fiddling with blocks and declarations and definitions, you just have tags and instructions.

You don't jump in and start throwing strings around without understanding what the computer is doing with them, instead you start right at the ground floor, doing simple arithmetic.

It is immensely satisfying to manage even simple arithmetic when you're first starting out in assembly language, and rightly so. To do a simple thing like A=12+B/4-D in assembly requires that you learn to order your instructions in a sensible manner and manage the temporary results.

It is rewarding precisely because it is difficult. Once you've managed to do any simple task, you are drawn back by the challenge. Best of all, after a brief intro, you're ready to jump into Knuth's TAoCP, which lays a solid foundation for any future programming task.

(I wrote a utility for learning assembly language, called easynasm)

I reviewed this book pre-print, some years ago...

[Brand X]

I was teaching a small group C++ class in the mid 90s... around '95, I think... and Steve sent me a copy of the book to review for use. I found it rather simple, and I hope he's updated the details since then (Lot of strstreams, for example, in the original), but it was very good for the youngest students in the group (early high school), and cute enough to actually be readable for some of the less naturally geekish students. The little note that he and his student wound up getting married caused one girl to do a sort of Titanic-fan "awwww"... but it did keep her interested, which meant it was the only book of the dozen or so I had available for take-home study that was actually read. I recommended it second highest of the basic books, after the 28 days book (Jesse Liberty, I think), but the "advanced" part was weak.

CS's History

[Dungeon Dweller]

The history of computer science is the history of mathematicians who studied algorithms with a passion before there was a practical use for them. Much of the work of our ancestors is only useful now. The structure of programming languages is an algorithmic strength. As for the people who are all into optimizing compilers, great guys, but if I have the time and resources to do so, I will always opt to optimize as much as possible. As for you who want to program in natural language, hell, do it all you want, but don't tell me that your interpretted program that a program builder wrote with stock algorithms is running faster than mine written in C/C++ and then hand optimized, life just doesn't work like that. Try running java on a 8080, and then native compiled C code, in 6 months, when the java program finishes running, you can open the envelope that I sent you with the results of the program written in C, ok?

Ok, maybe

[Dungeon Dweller]

I can see your point. The original point of this thread was that the syntax of programming languages isn't mired in the past, it's pretty damn good. At any rate, I still think that it is important that a computer scientist understand what these concepts are, and be able to do it at least at a rudimentary level. Doesn't mean that you have to write a "Hello World" and then spend 6 years making it faster, just means that you should know what's going on in your computer.

Re:Ok, maybe

[David Greene]

Oh, I don't think anyone will argue that. It's always been my belief that more programmers need to understand what's going on under the hood. In my ideal world, every CS and CompE degree would require an advanced computer architecture course (covering pipelining, caching, speculation, etc.), a (maybe advanced) compiler course (covering memory/stack layout, function call conventions/linkage and ABI issues, as well as dataflow analysis and code transformation) and an OS course to tie them all together.

It's been a small dream of mine to put together a 3-course cycle from computer architecture->compilers->OS and have the students build a complete system from scratch. I think students gain the most insight when they see how all the different pieces they learn about fit together and work in a (maybe) harmonious fashion.

--

Interesting Idea

[Dungeon Dweller]

Sounds like an interesting idea. If I were in the teaching profession, I would pursue it.

Some real fun...

[PureFiction]

Throw in C++, advanced data structures and templates (what, you mean the STL hash map is a blazing beast of speed??)

Then ass a little CORBA. With POA's and dynamic factories...

Then add pluggable protocols for an ATM layer and QoS.

Tasty.. wrap your brain around that one..

LOL

I disagree

[Dungeon Dweller]

A programmer may have a certain touch, but without the tools of the trade, the algorithms, the formula, the background in theory, you will never cross the bridge from "hacker" to "computer scientist".

or Step Seven: Get hired elsewhere and repeat

[cpeterso]

.

Don't get this book.

[Restil]

I had the author of this book as an instructor in one of my C/C++ classes in college. He got canned after only one semester.

The very first words out of his mouth on the first day of class was "C is dead, so there's no point in learning it." His book included a copy of gcc, but for some reason I can't recall, nobody could get it working and he had to hand out another version on floppies. We had to use HIS book as the textbook, but the student bookstore wouldn't stock it and Barnes&Nobel didn't order enough books, so some of us had to wait several weeks to get it.

He didn't pace himself properly and ran out of material at about halfway through the semester, so he spits out an addendum, which we also have to buy, so he can keep talking. Half the book is filled with conversations of this Susan person and none of it adds anything to the content of the book.

You'll love this one. The day we had our first test, which had errors on it, but thats a different story, he was SO paranoid that someone would try to smuggle out a copy of the test (why I can't completely figure out), that he insisted on searching everyone's backpacks as they left to make sure nobody stole a copy. The fact that we turned in our copy when we left didn't make any difference. He could also have done what other paranoid instructors do that don't want their students cheating (or stealing tests) and just leave our bags at the front of the room. OH but that might make sense or something.

That was the last day I went to that class. I just dropped it after that because I was so sick of it/him. Apparently the real kicker happened at the end of the semester. When it came time to fill out evaluation forms, he naturally got a REALLY bad review, and some stupid idiot in the administration decided to tell him that before he gave out the final exams. So he goes into class telling everyone that he heard about the review and decided to give everyone a REALLY hard final exam as revenge. Most students ended up failing the class or getting low passing grades as a result. The school ended up giving everyone who wanted an option to do a small project to correct the grade in the class.

Don't buy this book. Don't send this guy any money. I don't know if he's changed any over the years, but this book is a piece of trash and it will NOT be money well spent.

-Restil

Exactly!

[devphil]

I was hoping my sarcasm was self-evident, but I forgot this is slashdot. Okay, next time I'll surround my jokes with tags...

I agree

[Dacta]

Still, I don't think a language like that (C) is good to learn on, which is what my point was.

Re:just little nitpick on NP

[scheme]

This is a common misconception. NP stands for non-deterministic polynomial. It it is possible to solve a NP problem with a non-deterministic algorithm in polynomial time, but there is no known polynomial time deterministic algorithm to solve them. Proving whether deterministic polynomial (P) is equal to non-deterministic polynomial (NP) or not is probably worth a Nobel prize.

Doh! I can't believe I screwed up like that since I've taken a few discrete math and theoretical cs classes.You're right of course. BTW, anyone who proves that P=NP or P!=NP will probably win a Fields medal since Nobels are awarded for mathematics.