Stroustrup Says C++ Education Needs To Improve 567
simoniker writes "Over at Dr. Dobb's, C++ creator Bjarne Stroustrup has given an in-depth interview dealing with, among other things, the upcoming C++0x programming standard, as well as his views on the past and future of C++. He comments in particular on some of the difficulties in educating people on C++: 'In the early days of C++, I worried a lot about "not being able to teach teachers fast enough." I had reason to worry because much of the obvious poor use of C++ can be traced to fundamental misunderstandings among educators. I obviously failed to articulate my ideals and principles sufficiently.' Stroustrup also notes, 'Given that the problems are not restricted to C++, I'm not alone in that. As far as I can see, every large programming community suffers, so the problem is one of scale.' We've discussed Stroustrup's views on C++ in the past."
I'm just glad they're teaching C++ actively again. (Score:2, Interesting)
One semester later I dropped out and never looked back to computer science again as a career choice. In fact, though I bounced around between community colleges for a few years after, I never finished school.
Let me restate this: I'm just glad they're teaching C++ actively again. I wouldn't wish my experience on anyone.
more to it (Score:5, Interesting)
The language is overly complex. The key advice any C++ expert is "restrict yourself to a specific subset of C++". That's the bulk of the difficulty. If C++ were simplified to include only that subset, you'd have a lot less need for training,
Re:I completely agree (Score:5, Interesting)
As for programming pedagogy, I think we'd do a lot better if the faculty of CS departments would migrate away from using Java/C++ as the introductory programming model because so much of what gets said initially just goes in one ear and out the other. I will admit to not remembering at all how typedefs or templates in C++ work, and I can't say it's harmed me much.
Python would be a much better choice in my view for a variety of reasons (and I say this though I'm a Perl nut!), or hell, if you teach them Lisp they'll be horribly screwed up for the rest of their lives but at least they'll understand how registers and OOP work.
In short, novice programmers are not going to learn anything useful if you use C++ as the prescriptive model for how a well-written computer program should look -- they're just going to hit the bottle earlier in life.
Education, even at Universities, needs to Improve (Score:5, Interesting)
I work in another department and sadly, without formal CS experience, I'm a better programmer than many (if not most) of the CS department's graduates. I don't think, however, that this problem is unique to my school. I've visited other US universities where the situation is very similar.
In fact, I recently took an informal survey of about a dozen CS seniors and found that none (yes, none) of them knew what K&R, the "white book", or the "Art of Computer Programming" were.
Re:Maybe the real problem... (Score:2, Interesting)
It reminds me of this: http://thedailywtf.com/Articles/It-Had-Too-Many-Functions.aspx [thedailywtf.com]
Re:Education, even at Universities, needs to Impro (Score:5, Interesting)
My university course spent about half an hour on pointers in a 3 year course. Most of that half hour was factually wrong: the slides were full of code samples that wouldn't compile or would always crash.
They did, however, spend two terms teaching Hoare logic. Or rather, they spent one term teaching it, and then repeated the same material in another term with a different lecturer, because their communication was so poor they never realised they had duplicated their teching.
Friends at other universities reported similar stupidities, though not always on the same scale.
C++ is a rather complex language, but simplifying it won't help. The problem is that low quality education is rampant.
Re:Maybe the real problem... (Score:1, Interesting)
One only has to take a look at issues like const correctness and all the different ways one needs to declare "constness" in or out of the presence of pointers and reference variables to realize that Stroustrop gave birth to a monster that should have been aborted.
I've developed in C++ for 20 years now, and I've developed in SmallTalk, Common Lisp Object System, and Java.
Stroustroup should be embarrassed. C++ is complete shit and just gets shittier.
Anonymous Coward because I am currently involved in working a massive C++ system for the Army consisting of probably 200 developers -- and it's complete shit -- not because the developers are stupid and not because the Army is stupid and not because 200 developers is too many -- but because C++ is complete shit and a house is only as good as its foundation.
Re:Maybe the real problem... (Score:4, Interesting)
It will take a lot of effort for someone to make good clean code, fast and efficient, easy to read, easy to update, well commented and bug free. C++ is only a good language if you have the tolerance to code that carefully over a long time.
For real life upper level languages the the job done faster better and easier.
For terms of Teaching Computer Science C++ isn't a good language at all. The problem is the students are focused more on getting the damn thing to compile finding where they missed the ";" vs. Understanding the logic and concepts being taught. I knew C before I started college so doing C++ wasn't much of a stretch, so I got more out of my education then some of the other students who didn't have the background their view is If it compiles then it is done.
Coding a C++ compiler... (Score:1, Interesting)
Re:more to it (Score:5, Interesting)
A simple example: given a vector of ints, calculate the average value, using standard idiomatic C++. Let's give it a try:
A simple task, and a clean implementation, using the standard library as much as possible. No fancy language features used - no template metaprogramming, no pointers, no virtual inheritance. The kind of stuff a new C++ programmer might write after reading Stroustrop. And yet, it gives wrong result for certain input data. Now, who'll be the first one to spot and explain the problem here, preferrably without actually running it? Bonus points for explaining why we need "istream", "ostream" and "iomanip" headers here in addition to "iostream" (and we do, if we want this to be portable).Re:more to it (Score:3, Interesting)
This isn't to bash C++; it's still a useful language when you want raw speed of C but with some more decent abstraction mechanisms. It's just not the right language to write high-level stuff in, and it shows now that a lot of GUI applications, which were previously largely written in C++, are being done with C# or even Python.
Strostrup is the problem (Score:5, Interesting)
The big problem with C++ is Strostrup. He's in denial about the fact that the language is fundamentally broken. But he's still influential in C++ circles. Thus, no one else can fix the mess at the bottom.
The fundamental problem with C++ is that it has hiding ("abstraction") without memory safety. This is the cause of most of the world's buffer overflows. No other major language has that problem. C has neither hiding nor memory safety, so it is still vulnerable to buffer overflows, but they're to some extent visible at the place they occur. Pascal, Modula, Ada, Java, C#, and all the interpreted "scripting languages" have memory safety. C++ stands alone as a language where you can't see what's going on, and the compiler doesn't have enough information to check subscripts.
The reaction of the C++ standards committee has been to try to paper over the problems at the bottom with a template layer. That didn't work. The template classes just hide the mess underneath; they don't make the language memory safe. There are too many places that raw pointers leak out and break any protection provided by the templates. The template language itself is deeply flawed, and attempts to fix it have resulted in a collection of "l33t features" understood and used by few, and too dangerous to use in production code.
The fundamental cause of the trouble comes from C's "pointer=array" equivalence. That was a terrible mistake, borrowed from BCPL. The trouble is that the compiler knows neither which variables are arrays nor how big the arrays are. You can't even talk about arrays properly. I mean, of course,
int read(int fd, char* buf, size_t len);
That's just trouble waiting to happen. "read" has no information about how big "buf" is.
C++ added references to C, and should have added syntax like
int read(int fd, char& buf[len], size_t len);
to go along with it, so that arrays became first-class objects with sizes. But it didn't. There are some other things that have to be done to the language to make this concept work, but this is the general idea. This is the elephant in the living room of C++, and Strostrup is in denial about it.
Every time you have another crash from a buffer overflow, every time you install another patch to fix a buffer overflow, every time you have a security break-in from a buffer overflow, think of this.
So long its not Matlab (Score:5, Interesting)
Granted, Engineering always went for things that CS considered "brain dead" -- Basic, PC's, DOS, Windows. But Matlab is more brain dead than most.
What happened is that a lot of the current generation of Engineering profs cut their teeth on FORTRAN -- their Intro to Programming was in FORTRAN, whatever industrial job they had before getting a PhD had them compute things in FORTRAN. Few of them were ever comfortable in it and most of them spent hours in the computing center debugging programs dumped to massive punch card decks.
When Matlab came around, it was numerical Nirvana. It had this massive numeric library that you didn't have to write your own Q-R linear equation solver or SVD subroutine, and you didn't have to go searching for this stuff either, it was all there. It had a command prompt to performed immediate execution along with reasonably friendly error messages. And it acquired a thoroughly feature-full graphics package.
Don't get me wrong, Matlab is a very capable numerical applications language and even turns out to be one of the better Java scripting languages of all things. But it really falls down in terms of extensibility of its type system, and as far as what Mathworks tacked on for object-oriented programming, fuggedaboutit. It is also the Swiss Army knife of software for a whole bunch of people, and forget about introducing them to a socket wrench and handle that can apply serious torque to a bolt when they think they can get by with the pliers tool.
While people who know what they are doing can benefit from the convenience of the numeric and graphics libraries, the immediate mode, the verbose error handling and rare instances of complete crashes, if you don't know what you are doing (i.e. you are just learning), it can lead to as many hour-gobbling skull-cracking debug sessions as anything else. Our required Numerical Methods course is in CS, it uses Matlab, our faculty is complaining that the students are complaining that they hate the course because they are spinning their wheels trying to get programs to run (in Matlab of all things), and we have guys in our department we want to teach Numerical Methods (in Matlab, of course), in the context of a watered-down Intro to Engineering offering.
What the community needs right now is a Python distro with enough of a numerics and graphics package rolled in to do 90 percent of what is in Matlab (Are the Python people still hashing out that Numerics/Numpy divide? Is there an engineering graphics library that is Numerics/Numpy compatible? 99 percent of what you do in Matlab is that you have a Leatherman Tool of a 2-D array type (Matlab, Matrix Lab) along with all of the libraries being compatible with that type.) CS departments could teach their Intro to Programming along with their Numerical Methods courses using that Python distro, and we can save a generation of engineers from brain damage.
Linus Torvalds on C++ (Score:4, Interesting)
For the record, I'm inclined to agree with Torvalds. The main problem with C++ is its insane levels of complexity and its unerring eye for adding subtle and difficult-to-diagnose problems once things like multiple inheritance get factored in.
Re:more to it (Score:5, Interesting)
v.size() has vector<int>::size_type as its return type. Depending on which specific type, either that type will be converted to int, and all is fine, or the result of std::accumulate(v.begin(), v.end(), 0) is converted to an unsigned type, then divided, and then converted back to int. In the latter case, when you have a negative sum, the division gives the wrong result.
I think the <istream> and <ostream> headers are required because the types of std::cin and std::cout might otherwise be incomplete, meaning operator<< might be undeclared. I know the <ostream> header is also required to that std::endl is declared. I'm not seeing what could be in <iomanip> that's of interest of your program. Could you explain that last one?
Give it up Bjarne (Score:4, Interesting)
Few could tell you why you necessarily want to make your destructors virtual, why not doing "delete [] array" is not necessarily a memory leak, where must references be initialized, why it's good practice to use (at the time) the new cast notation... the list went on.
It's been a decade, I've started to forget all that material. I followed the ANSI committee, read most issues of "C++ Report" and wrote some of my best code during my days at MS. Unfortunately I can't say I found many people who could relate with verve for putting out great code. (All you trolls, this is about a programming language, not about any specific product or company, go outside, run 'til your heart feels like it's going to give out so your thoughts gravitate elsewhere... better yet, let it give out)
Sayonara C++,
-M
PS: C++ has become niche Bjarne.
Why I quit using C++ (Score:3, Interesting)
I talked to another individual about C++ and what he hates with C++ is that you are taking too much time thinking about infrastructure and not solving problems. Whereas in Java you think more about solving problems and less about infrastructure.
Re:C++ has issues (Score:5, Interesting)
you have my full attention. Please, support your assertion that Java and C# suck rocks.
C++ can be fast at execution time but the development time is prohibitive in many applications where you need to be agile and actually ship code in a hurry. I try not to get hung up on all the esoteric points of different programming languages, although I am quite amused to read other's comments. Yet, I will hazard a post on this topic.
I learned C++, not all of it to be sure, but the portions 85% of us might need in a given project. It may be intellectually stimulating to code an app form a "purest perspective" but many of us have to earn a living and produce a lot of code in short order. C++ does not fit this bill. Most applications just have to work and work today, not next quarter. Then we have to extend the app after a few months. Since C++ is quite a bit harder to read and I have to learn code I did not write in short order to perform this maintenance, I enjoy Java and C# apps a lot more than ones coded in C++.
Please, tell me why Java and C# suck compared to C++ in the practical world. Nearly all of us are not writing low-level, time-critical code. Most of us write apps for business transactions. I happen to write business software that is widely distributed and the C++ performance boost is nullified by the latency of remote calls to distant servers.
Please, tell me the advantage of writing an app in a year vice 6 months.
There are many languages because there are many problem domains. C++ is not the best language. There is no best language, period.
Nearly all serious desktop software
Finally, it has been my observation most "serious" code is no longer constrained to the desktop.
Re:Maybe the real problem... (Score:4, Interesting)
Re:more to it (Score:2, Interesting)
I find the contention that because C++ can be complex that it should be restricted a little defeatist. It's analogous to saying, because most people don't use, or understand, math past introductory college algebra, why even teach higher-level mathematics.
Re:more to it (Score:5, Interesting)
Re:32 year programmer -- use C++ (Score:3, Interesting)
True. Some, however, are hideously worse than others.
Pointers are a powerful tool, in the very few cases where you actually need them. Otherwise, they're just a buffer overflow or segmentation fault waiting to happen. (And there are languages which can't have either.)
That is still useful, to some extent. However...
Really? In what way is that valuable? I can see how it would be interesting, but I can't imagine how it would make my programs better in any measurable way.
And slower to compile, for no good reason. And still might have some syntactical surprises. If you use 'C' constructs, why not just write C?
All programmers, good or not, do stupid things from time to time.
There was a study done once. I don't remember which languages were covered, but I do remember that some were very low-level, and some very high-level.
What they found is that the ratio of bugs to lines of code remained constant across all languages. Therefore, a higher-level language, which results in fewer lines of code to perform the same task, will likely result in a less buggy program -- not to mention a much more maintainable one.
Come back when you've done anything significant in LISP, or any language which supports closures.
Yes, especially in programming, it's better to focus on making things easier for an expert to use, rather than making the learning curve easier. Unfortunately, C++ is neither, and most experts will tell you to use a subset of the language. In today's world, the main place where C++ is invaluable is for code which must perform well, especially when you need enough of it that writing it all in assembly is out of the question. But as someone else posted, the proper subset of C++ to fill that role is C.
Is it because it is just a language? (Score:5, Interesting)
Reading the threads, many people are discussing the relative merits of the other programming languages/environments - Java/C#/Python/etc - but what do all of those have that C++ does not have?
More complete environments.
When you install a C++ compiler, you get a C++ compiler and the standard library. When you install Java or C# or Python you get libraries to support simplified Networking, IO, Database access, GUIs, Memory Management, Threading and more.
Now it is possible to find all that for C++, but they are all separate components that the developer needs to decide on and download. And the number of choices for each is large. Do you use wxWidgets or FLTK or GTK+ for GUI, for example.
The other environments actually reduce your options, and for projects on a timeline the less time you spend on determining what you need to accomplish the task, the sooner you finish. Yes you can bring in replacement libraries in Java or Python or C#, but few people do. The folks that wrote those libraries did a pretty reasonable job on them, and since they are bundled with the standard installers, unless there are really specific needs, there's rarely a reason to replace them.
Look as an example of this at the Mono project. It is an attempt to provide the C#/.Net environment outside of Windows, but it does not have as much traction as .Net on Windows, why? in part because the .Net frameworks are more complete on Windows than in Mono. I not many .Net developers that use WindowsForms in every project. Without that piece of the eco-system already available, their project would take much longer. Mono basically provides C# for Linux, just another programming language.
I've watched over the years as some folks tried to assemble Java-like libraries for C++, but they didn't really take off.
This appears to me as why C++ has the reputation of being so hard to build applications in. The developer has to do so much extra work just to get to the point of assembling the program that the Java or Ruby or C# or Python crowd gets out of the box. Is this the fault of C++? Not the language, but perhaps it is something the steering committe should address. As someone pointed out in an earlier thread, the C++ standard group likes to make the comment that a particular given feature is not part of the language. Perhaps they should rethink that stand.
As point of background, I started working with C++ when it first appeared as a pre-processor that created C code that was compiled by a C compiler (when you had to use the keyword Overload). I later moved into Java and have made a good living doing Java development. Recently though I have gotten deep into programming in 3D graphics with OpenGL. I'm doing it both in Java (using jogl) and C++ (direct gl calls as well as engines). This is one area where there is not a clear choice for any platform, but because in the Java world I have the Networking and Threading, I was able to put a system together much quicker than I could in C++. Of course the Java approach has it's own problems because of the sheer volume of objects created/destroyed (imagine a 3D model made of Vector3D objects), so I end up using C++ approaches using float[] arrays (also an object, but only one).
Sorry for the ramble. Anyway, the point is, I personally think C++ would be more acceptable if it really was an eco-system and not just a programming language.
Re:Strostrup is the problem (Score:4, Interesting)
Yeah, array/pointer ambiguity is a key "broken" feature of C++, although at the same time it's exactly the kind of thing that makes it possible to use the same language for code running on a microcontroller and for a full-blown GUI.
Not really. I'm not asking for array descriptors. I'm not proposing to change the run-time representation of arrays. What I'm talking about is a generalization of array declaration syntax.
Until C99, array declarations always had to have constant array sizes. C99 introduced on-stack arrays, so in C99 you can write:
int fn(size_t n); /* on-stack array, sized based on fn parameter */
...}
{ float tab[n];
This was the first syntax which allowed a run-time variable in an array definition, and it was a big help, because it saved a malloc call inside of number-crunching libraries. (Numerical Recipes in C had this problem, and FORTRAN didn't.).
The next logical step is to allow that syntax in more places, like function parameters. This doesn't require passing an array descriptor. The programmer gets to specify the expression that defines the array size. So there's now a way to talk about array size that the compiler understands. Checking becomes possible.
Of course "sizeof" and "lengthof" should be extended to such arrays, so you can write:
int status = read(infd, buf, sizeof(buf));
Giving up pointer arithmetic is too much to ask C and C++ programmers, but restricting pointers to iterator syntax (valid values are NULL, a pointer to an element of the array, and one past the end of the array) makes them checkable. There are checking iterator implementations, so this is possible.
Once the compiler knows what's going on with arrays, subscript checking can be optimized. This is well understood. In particular, subscript checks within for loops can usually be optimized ("hoisted" is the term compiler writers use) so that there's one check at the beginning of the loop, and often that check can be folded into the loop termination condition. So the checking cost in matrix-oriented number-crunching code is usually zero.
There's more to this, and it isn't painless to remove this ambiguity, but if we had a "strict mode", where the checkable forms have to be used, there's a transition path.
If all code running as root had to be in "strict mode", we'd be way ahead.
Re:Ruby? (Score:3, Interesting)
You can still use the === operator, or the kind_of? method. And I'm fairly certain metaprogramming is supported.
That would still be runtime. I want it to be compile time, so that I don't pay a runtime overhead for something that could be precomputed, and so that type errors and other such trivia is out of the way before I begin testing. It's like getting a free peer review :o)
I've just found that static type checking is about all that's missing, and it isn't incredibly useful, especially when you're doing unit tests.
I think we just have to disagree there. Unit test doesn't always save you from odd corner cases. Strict and static typing helps there.
I'd assumed they did? After all, Ruby is from Japan...
It is kind of ironic, but until recently ruby's unicode support sucked.
I'm feeling a bit lost in this jargon... Can you give me some specific examples?
Hmm. I hate giving examples in slashdot code. For specialization, std::hash is a nice example. std::hash is specialized for all object that want to support hashing. So if you have a class that can't or won't hash, the compiling fails. In ruby you'll fail at compile time. In Java, you'll get a weird behaviour, as i recall. Overloading is simple... instead of a function starting with a bunch of test to find out what sort of argument you got, the correct function will be inferred by the type. So operator/(double) is a completely different method than operator/(complex).
When these are done for me, via things like Eclipse plugins, I don't worry too much about how complex they are under the hood, so long as they work.
Try getting that to work properly for C++. KDevelop is the best, and far from perfect in my experience.
For what, though?
Again, for those compile-time checks. In C++ I can return a constant reference and *know* that it won't get modified. Or call a constant member and know that the method doesn't modify the object. (Like the conventions of ! and non-! in ruby, but more general).
The existing constants are difficult enough to override without at least a warning, and I think that's really all you need. The same could be said of the private/protected methods -- there is a bit of a mess with the usage of 'send', but in a language which truly supports reflection and metaprogramming, private/protected is effectively only a warning anyway, as there's always a way around it.
I agree, but constants variables are just the beginning. It's the constant methods and return values that are truly valuable.
Ruby is at least as strong as C++, I'd think, due to how easy lambdas are. This seems to be about DSLs again, right?
Dynamically, ruby is stronger. Statically, C++ is stronger.
The syntax for calling functions, and for passing them blocks, is simple and clean enough that it almost feels like defining your own language directives. Yet it's all still valid Ruby, which means it's usually readable by anyone who understands Ruby, and it's easy to mix and match.
I love that featu
Re:Maybe the real problem... (Score:3, Interesting)
To fully understand what Bruce means, read this [yosefk.com]
Comment removed (Score:3, Interesting)
Re:Give it up Bjarne (Score:3, Interesting)
Either you are doing low-level system programming in which case C++'s OOP abstractions wont help you anyway.
Or you are doing high-level coding in which case C++ doesnt help you because its abstractions are so leaky, they arent making stuff easier but unfortunately even more complex (manual management of virtual/nonvirtuals, memory/resource management, etc.).
C++ always was a kludge, its only raison d'etre was that many other languages weren't there yet and others made the migration for C coders too uncomfortable.
In Hindsight, its a shame that Objective-C didnt play the role C++ did, for example.
Re:32 year programmer -- use C++ (Score:3, Interesting)
Really? In what way is that valuable? I can see how it would be interesting, but I can't imagine how it would make my programs better in any measurable way.
Well, in those days, with absurdly small limits on program size, you absolutely needed to know how many bytes your function would take. It sometimes meant being more than the 2K eprom. That requirement of knowledge make for better engineers, IMHO.
C++ has its flaws, absolutely. However, if you use "C" constructs, it is as efficient and as readable as C.
And slower to compile, for no good reason. And still might have some syntactical surprises. If you use 'C' constructs, why not just write C?
Well, C++ has some programming advantages that C does not have. Better type semantics and checking, default parameter values, etc. If it is as efficient and is as predictable in implementation as C, but has additional features that help you write code, why not use it? The C++ compiler can actually make "C" type programming safer with no cost.
Unfortunately, C++ is neither, and most experts will tell you to use a subset of the language. In today's world, the main place where C++ is invaluable is for code which must perform well, especially when you need enough of it that writing it all in assembly is out of the question. But as someone else posted, the proper subset of C++ to fill that role is C.
"C" isn't a proper subset of C++. The "class" construct makes all the difference. Using classes to represent logical hierarchies is very important to good software design.
bullshit (Score:3, Interesting)
Alan Kay didn't criticize C++ for being multi-paradigm or for being low-level. Alan Kay criticized C++ because C++ classes and the C++ type system are so mind-numbingly limited and poorly designed. No duck typing. No "become". No reflection. No meta-programming. Instead, you get a tar pit of source code dependency management, potential memory management errors, and other traps.
Can we please learn from this?
Well, you certainly could stand to learn a lot, but I suspect that you won't bother.