Stroustrup Says C++ Education Needs To Improve

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."

Comments

I'm just glad they're teaching C++ actively again.

[Anonymous Coward]

When I attended college back in 1998 (Purdue), they decided to blindside everyone by teaching Visual J++ instead--Microsoft having "generously" donated the college discs containing the software. I'll never forget those fateful words from the professor: "I don't know this language myself, so I'll be learning it with you as we go." Let's not forget my favorite: "Java is the future of everything."

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.

I completely agree

[betterunixthanunix]

I completely agree with Stroustrup. Too many people these days have little or no exposure to C++, and never learn how programming in the absence of garbage collection works. It is especially problematic in our research labs, where computationally complex problems must be solved with very fast code, but the people writing it get completely confused by pointers and memory management. Worse is when a proof-of-concept is distributed, with horrible bugs and completely incomprehensible code.

Re:I completely agree

[schmidt349]

Yeah, but that doesn't sound like the sort of problem that gets fixed by learning C++, which has a nasty habit of adding loads of complexity in all the wrong places. If you want tight, fast code and your project doesn't need OOP, use C.

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.

Re:I completely agree

[lexarius]

Agreed. Also emphasize that, while Python is not as efficient as compiled languages, you can come back later and rewrite important parts of it in C. Then you can teach C with an emphasis on high-performance computing, rather than the typical "here's how we ask for user input, here's how we copy strings" emphasis typically taught in C courses that I've seen. Eventually, you could then show them how to add in assembly code to get at special-purpose processor operations not exposed by C. Probably do this over the course of a few semesters though.

Hell, who am I kidding. Just teach them to code in brainfuck. Or maybe INTERCAL. Normal languages will seem much nicer after that.

Re:I completely agree

[bsane]

The O'Reilly books are an example of the problem here.... their C++ books are the worst O'Reilly books I've ever read. It wasn't until I picked up 'The C++ Programming Language' by Strousup that I realized my mistakes and what C++ was really capable of.

I agree with the premise that C++ is a great language, that is poorly understood, and often mis-used. Education would seem to be the answer to that.

Re:I completely agree

[gbjbaanb]

I agree too, to quote TFA: "Conversely, there is now a generation who is firmly convinced that a program is only well-designed if just about everything is part of a class hierarchy and just about every decision is delayed to run-time."

I'm not sure if the problem is bad education or the lazy coders who expect everything to be easy (ie done for them) so they don't have to really think about what they're doing.

Even MS's clever chaps have this problem - "lets have C# and GC so no-one need think about memeory ever again" they cried. Then they realised that objects are more than just memory so you do have to worry about destruction of the non-memory resources held by an object (eg file handle, etc). Then they realised they were getting problems writing code that interacted with the OS, so they introduced reference counting objects that they could put in their "deterministic" finalisation objects that they could put in their Garbage-collected objects.

Re:I completely agree

[laffer1]

I'm going to have to disagree. The C++ Programming Language is useless to actually learn the language and often times it fails as a reference. If all the ego was removed from the book, it might be useful for something. Compare it to K&R. You'll notice a difference in tone. I realize not everyone likes K&R, but aside from the chapter on pointers I feel it is a very concise book that allows one to pickup the basics of C very quickly.

I am not alone in my opinion. Consider the difference in rank on amazon. Many third party C++ books have better ratings. In fact, I'd argue C++ is such a large language that one needs more than one book to provide adequate information. I don't think The C++ Programming language should be anyone's first book on C++, but it could be an extra backup reference.

As for the O'reilly book, I agree it is not complete but there are a few useful items for reference. Absolute C++ is a better book. Even the deitel C++ how to program book is better and I don't think much of deitel books after having to use three as text books.

Maybe the real problem...

[bfwebster]

...is that C++ is a rather complex and brittle language. :-) ..bruce..

P.S. Feel free to flame away at me, but not only have I developed professionally in C++, I've actually rescued a C++ project by (among other things) drafting C++ coding standards and guidelines for the 30 or so developers working on it.

Re:Maybe the real problem...

[mathimus1863]

"...is that C++ is a rather complex and brittle language. :-) ..bruce.." That's not so much a problem as it is the nature of computers. Computers and the logic that runs them is complex and brittle, thus why it is important that developers understand a lower-level language like C++. If you don't understand the underlying system for which you are developing, you won't be efficient or effective at doing what you're attempting to do.

It reminds me of this: http://thedailywtf.com/Articles/It-Had-Too-Many-Functions.aspx

Re:Maybe the real problem...

[ubernostrum]

Computers and the logic that runs them is complex and brittle, thus why it is important that developers understand a lower-level language like C++.

...and several previous generations of programmes roll over in their graves at the thought that C++ is a "lower-level language".

The thing is, C++ is huge. Just to have a solid working knowledge of the core language, you need to master whole rafts of things that have nothing whatsoever to do with the low-level operation of the machine, because even the core is a labyrinth of obscure corner cases that make language lawyers drool, and which, if expressed in pseudo-code, would be a bunch of gigantic switch statements with a couple dozen levels of ifs nested inside each case. Now, add the STL on top of that, and add common third-party bits like Boost on top of that, and you're left with a monstrosity. To really understand programming at a lower level, you need at best only a small subset of C++, and unfortunately for C++ that subset is properly called "C".

Re:Maybe the real problem...

[wrook]

I wish I had mod points. While I agree with the grand (grand?) parent post, it didn't really provide any information (not sure why it was modded +5 interesting...). This post really explains the issue faced by many would-be C++ programmers. It's a long learning curve to write modern style C++ code. Not only that, but many people don't even realize *why* they would want to program this way. The bash out some horrendous code that nobody on earth can maintain.

C++ is also complex in and of itself, but there are good reasons for almost every piece of complexity in the language. Though severely dated the ARM is still a useful place to learn why the language is like it is. Despite it's complexity, I still think C++ is a very handy tool to have in my toolchest for certain types of problems. However I find myself turning to it less and less over the years.

Re:Maybe the real problem...

[jellomizer]

C++ is a process of reinventing the wheel over and over. The performance gains of doing things in C++ is usually lost because it wears down the programmer, and leads to sloppy coding. Higher Level Languages as part of the core language comes with many useful functions that are programs relatively good efficiency. Lets say Pythons List Data type where you can do a Sort on it or a concatenate, or get a sub list off of it, and more too. Yes you can do the same functionality with C++ but you need to make it yourself and build the Data Type and add the functions to do it, or get a library that may not work on an other platform or needs more libraries to work. But what will normally happen to a C++ Developer they will make a less efficient hack to the data type they actually want, just to save time. So unless you are really obsessed with performance in your code C++ will often lead to slower application and it will take much longer to code anyways. Higher Level Languages let you focus on getting what you need done and a degree of trust on what you are going to do will do it fast enough.

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.

Re:Maybe the real problem...

[shutdown -p now]

The thing is, C++ is huge. Just to have a solid working knowledge of the core language, you need to master whole rafts of things that have nothing whatsoever to do with the low-level operation of the machine, because even the core is a labyrinth of obscure corner cases that make language lawyers drool, and which, if expressed in pseudo-code, would be a bunch of gigantic switch statements with a couple dozen levels of ifs nested inside each case.

Absolutely. This is fairly easy to check, too; here's the most recent draft for C++0x, and it's already 1200+ pages! And they haven't even included everything they want to get there yet (such as concepts, which alone will add a lot more; a full list of what's not yet there, but is going to be, can be seen here). Now, how do you think, how many developers are going to understand it well enough?

Re:Maybe the real problem...

[Profane MuthaFucka]

Mostrosity? Have you looked at java.com lately? That website is a tangle of twisty little API's, all alike.

Re:Maybe the real problem...

[mollymoo]

There's a big difference between a sprawling standard library and a sprawling language definition.

Re:Maybe the real problem...

[jgrahn]

C++ is a process of reinventing the wheel over and over. The performance gains of doing things in C++ is usually lost because it wears down the programmer, and leads to sloppy coding. Higher Level Languages as part of the core language comes with many useful functions that are programs relatively good efficiency. Lets say Pythons List Data type where you can do a Sort on it or a concatenate, or get a sub list off of it, and more too. Yes you can do the same functionality with C++ but you need to make it yourself and build the Data Type and add the functions to do it, or get a library that may not work on an other platform or needs more libraries to work.

Have you ever used C++? Python's lists correspond (roughly) to C++'s std::vector, and the Python list sort() method corresponds to C++'s std::sort(). No need to reinvent any wheels here.

In case you just meant that there is no exact match for the Python list class in C++, then that's true. But that is true for all languages but Python. Also keep in mind that Python (which I like and use regularly) buys its incredible powerfulness and simplicity by being one of the slowest languages around. One of C++'s design goals was to never be so slow that the user has to resort to another language, and that prevents it from having much of Python's convenience.

Re:Maybe the real problem...

[shutdown -p now]

Your logic is flawed. It assumes ...

No, it does not. I wasn't comparing C++ to anything (and there are more complicated industrial languages out there: Common Lisp comes to mind), merely pointing out that its sheer size and complexity is more than most can handle.

That developers actually learn the language from the ISO standard rather than books.

They don't, and that's part of the problem (because the books are inadequate; and the books are inadequate because any book that'd cover all the subtleties won't be much shorter than the Standard).

That developers have to relearn the whole language when C++0x comes out.

They will, when they run into code written using new C++0x features that they'll have to understand, debug and maintain. That's the problem: in theory, you can only use a subset of the language, but in practice, there's no standard subset, so as long as you use third-party code, you'll get it all eventually, and will have to understand it all as well. If you want a standard subset, that's Java (or C#).

Re:Maybe the real problem...

[pyrrhonist]

..is that C++ is a rather complex and brittle language.

To fully understand what Bruce means, read this

Re:Maybe the real problem...

[bfwebster]

To be honest, I would have been tempted to score my own post as flamebait, though it was not intended as such. Let me quote from myself back in 1995, in the Bibliography section of my book Pitfalls of Object-Oriented Development (M&T Books, 1995):

The Design and Evolution of C++, Bjarne Stroustrup, Addison-Wesley, Reading, Mass., 1994. This is a good book to have when you reach a point in your C++ studies that you want to throw things through windows. In the first place, it allows Stroustrup to explain the thinking and debates that provide insight into various aspects of C++. In the second place, it's softcover, which means it will bounce off the window when you throw it.

Elegance is that term of art in software engineering that we use to describe a piece of architecture, design, and/or coding that accomplishes what it needs to (and often a good deal more) with a minimum of complexity and a maximum of clarity. In all my years of dealing with C++, I have never heard anyone call it "elegant", and with good reason. ..bruce..

Re:Maybe the real problem...

[maxwell demon]

The C++ standard contains the complete standard library definition. Note that there are complete books just about the standard library (and some even just about the STL subset). And C++0x adds more to it (more STL classes, a random number generator framework, a threading library, regular expressions, ...).

more to it

[g2devi]

That may be so, but there's more to it. It's only been recently fully implemented and a few years ago Stroustrup himself commented that he's constantly surprised that some things (e.g. template recursion) are even possible in C++.

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:more to it

[JohnFluxx]

Sometimes you need the more complicated parts of C++ - It would be a very bad idea to simplify c++ to the lowest common denominator.

For example, most people don't use the SSE stuff or even know about it. You can, for example, make a vector with 4 numbers in it and multiply it with another vector with 4 numbers in it. The result is that the four multiplications are done simulatanously.
Most people won't use this functionality and thus don't even need to learn it, but when you need an algorithm to run fast, it is essential.

Re:more to it

[smilindog2000]

I couldn't agree more! Much of the worst code I've ever had to deal with is C++ code written by smart guys who don't know what parts of C++ to use. How about mixing double inheritance from template classes, with smart pointers and garbage collection, when all you're writing is quicksort? Smart guys can take a 100 line problem and turn it into a 10,000 line C++ solution.

I focus instead on restricting programmers to the tools they need, so they focus their creativity on algorithms instead of coding methodology. I've even codified it all, as an extension to C, rather than C++. Works great for team programming. I had a guy last week write two IC placers: simulated annealing, and quadratic placement, in 5600 lines of hand written code, debugged and working. He did it in 6 days while supporting a difficult client, without working weekends or evenings. I'd estimate his productivity at 10X to 100X higher than average.

Re:more to it

[Zeinfeld]

The key advice any C++ expert is "restrict yourself to a specific subset of C++".

Yes, that subset is called C.

Seriously, at this point it is time to call a halt to C++ education. Treat it like COBOL, Fortran or any other legacy language that still has demand for programmers but is long since past utility. It is a good idea for students to understand that they have to keep current with programming languages and not expect to be employed as a programmer if they can only code in one. But that does not mean we should start by teaching an obsolete language.

You don't need to tech kids to write in C++ for them to learn how bad an idea lack of GC is. Just give them some existing code and tell them to chase buffer overruns and memory leaks.

I would not code in any language that does not have a garbage collection feature, period. When I coded C in the 90s I wrote my own garbage collector using macros and some extensions to the memory allocation routines. More importantly I would not allow anyone else to write code without GC because none of them were capable of doing it right.

Second, do not use the null terminated string handling. This was one of the key coding requirements that Tim Berners-Lee set out in libwww. All string catenation was checked. It is one of the reasons libwww was so widely used, it was buffer-overun error proof.

I would certainly specify C for use in a low level O/S platform project, but not C++. I think the language is Algol 68 to Algol 60, worse than the original.

Above that point I would use either C#, Java or objective C. From an education point of view they are interchangeable.

C# is at least as fast as equivalent C++ code. The code generator used is identical. You can switch in your own GC if you choose.

Re:more to it

[shutdown -p now]

Unfortunately, even if you keep away from the more advanced stuff such as template metaprogramming, there's still plenty of surprising (in a bad sense) behavior in the most basic C++ constructs (mostly inherited from C, but exacerbated by C++ pretense at high-levelness, and with some new stuff thrown in for good measure). Pointer arithmetic, unsigned types, silent implicit narrowing conversions, PODs vs non-PODs (which in turn separate into aggregate types and everything else) and the subtle differences in initialization of those, ability to delete void* and pointers to incomplete types (and the wonders of virtual destructors), etc... The language is a mess, really. It is very powerful, and the existing code generators are very good at optimizing stuff, but writing in C++, or any subset thereof, requires a very good understanding of subtle details.

A simple example: given a vector of ints, calculate the average value, using standard idiomatic C++. Let's give it a try:

#include <algorithm>
#include <iomanip>
#include <iostream>
#include <istream>
#include <iterator>
#include <numeric>
#include <ostream>
#include <vector>

int main()
{
std::vector<int> v;
std::copy(std::istream_iterator<int>(std::cin), std::istream_iterator<int>(), std::back_inserter(v));
int avg = std::accumulate(v.begin(), v.end(), 0) / v.size();
std::cout << avg << std::endl;
}

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

[gbjbaanb]

You don't need to tech kids to write in C++ for them to learn how bad an idea lack of GC is. Just give them some existing code and tell them to chase buffer overruns and memory leaks You don't need to tech (sic) kids to write in C# for them to learn how bad an idea of GC is. Just give them some existing code and tell them to chase memory leaks and finalisation issues.

There, fixed that for you.

Re:more to it

[shutdown -p now]

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,

Yeah. That subset could be called something then to distinguish it; say, "Java". And then you could have a slightly larger subset with more advanced stuff, like pointers and value types; let's call that something more C++-like to reflect it: hm, how about "C#"? And sure enough, once you do that, it's much easier to teach people that, and they write more readable code, too.

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.

Re:more to it

[Chapter80]

I agree. C++ served its purpose in the language world. It was a great FIRST STEP toward object oriented programming, but it has outlived its usefulness. Stroustrup should take pride in his great contribution, and not be discouraged because C++ has been superseded by other, better languages. C++ provided a bridge from the world of no objects in C, to the world of objects. But now that there are languages that are designed with objects in mind from the ground up, it's only academically interesting (and of little practical value) to learn C++ except to support (or port) legacy applications.

Re:more to it

[johannesg]

The "restrict yourself" stuff is stupid. It's like saying "tie one hand behind your back while programming". Can you think of *any* other profession where professionals are advised not to use their best tools?

The correct advice would be, "use precisely what you need and no more".

I have been programming in C++ for a very long time, and I have needed *every single tool* that some of you nay-sayers would say was unnecessary. And that's needed in the sense of "the best solution was achieved using these tools", not "I padded my CV by adding unnecesary complexity".

Re:more to it

[gbjbaanb]

Oh, I thought the new American spelling of Java was indeed 'C#'. Perhaps its just a Seattle dialect.

Re:more to it

[twistedcubic]

Did I mention using the right tool for the job? Use perl for this example.

You guys are weird. Someone gave incorrect, convoluted code (in C++) for doing something, and you criticize C++ for this???

Re:more to it

[truedfx]

I'll admit I had to run the program, and even then it took me a while to see it.

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?

Re:more to it

[boilednut]

Granted C++ is a complex and feature-rich language; but, the majority of that complexity is not imposed on you -- it there to be used at your discretion. C is a subset of C++; so, it's quite possible to write essentially C code with only the elements of C++ added that you consider useful. For example, templates are a powerful and labor-saving C++ mechanism for writing a family of classes that share a common interface but whose data-members don't have a common parent; however, it's quite possible to do something similar in C++ using the old-hat C constructs of structs and unions.

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

[shutdown -p now]

I know the header is also required to that std::endl is declared. I'm not seeing what could be in that's of interest of your program. Could you explain that last one?.

Ironically, it's my mistake - std::endl is also a stream manipulator, so I figured it is properly supposed to be in "iomanip" as well, and didn't bother to double-check (let's face it, in real world we usually just include "iostream" or other stream header as needed, and that's it - the rest gets dragged in, even if the Standard doesn't guarantee that it will). But you're absolutely right, std::endl is in "ostream", shame on me. And I've been coding fancy C++ stuff (with templates, STL, and all that) for five years now... *sigh* I guess it sort of serves to reinforce the point I've originally made :)

Re:more to it

[shutdown -p now]

No, my concern was with Standard compliance. If you merely want this code to run on any existing C++ compiler, half of those includes could be safely removed - just "iostream" would suffice. There's just no guarantee it won't suddenly stop compiling tomorrow on gcc 4.5 ;)

Re:more to it

[shutdown -p now]

Did I mention using the right tool for the job? Use perl for this example.

Why would one in a sane mind want to use a language explicitly designed around string processing for number crunching?

Re:more to it

[maxwell demon]

And yet, it gives wrong result for certain input data.

Well, the first problem I see with this code is that it uses integer division. The fact that "/" on integers gives an integer division isn't just a problem of C++, but of many languages (Pascal did get it right by using a separate operator, div, for integer division, and reserving / for float division). Thus if you enter the numbers "1" and "2", instead of the correct answer 1.5 you'll get 1. To get floating point division, you must have at least one of the types be a floating point type. This could e.g. be done by replacing v.size() with double(v.size()) or (preferrably, because it avoids a type cast) (v.size() + 0.0). Of course, the variable avg shouldn't be int either, but a floating point type.

Another problem of the code is related to the fact that v.size() is an unsigned type, which will give unexpected results if the sum on the left is negative (but then, this problem wouldn't occur if the correct floating point division was used). This is due to the rule inherited from C that mixing signed and unsigned in arithmetics will cause the signed value be converted to unsigned. This can also give other surprising results; e.g. v.size() > -1 will always evaluate to false.

The code also has other problems, like missing error handling for I/O errors and for empty sequence (i.e. no numbers given at all, which will result in division by zero). But that's hardly a language problem.

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).

We don't. Only "iostream" (for std::cin and std::cout) and "ostream" (for operator>, but istream_iterator for input (the fact that istream_iterator internally uses operator>> is irrelevant here; it's the job of the "iterator" header to make sure everything needed in the implementation of the iterator is included; indeed, on a compiler implementing export, might only be included in the corresponding .cc file of "iterator" (and thus not even indirectly in your own translation unit). Moreover "iomanip" isn't needed because you don't use any of the manipulators defined there (you need "iomanip" only for iterators which take arguments).

Re:more to it

[dookiesan]

Yikes. Using a 'for' loop you could have actually made the entire thing shorter (I think).

Education, even at Universities, needs to Improve

[Lord Byron II]

I'm continually amazed that the CS majors at my major US accredited university can't program using pointers, object oriented techniques, or parallelism. I think that there is an attitude among the professors that this material is difficult, so it shouldn't be worth a lot of points. As a result, the students don't bother to learn it.

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.

I got my B.Sc. in Comp. Sci in the 1970s and ...

[Anonymous Coward]

I think COBOL and Fortran education needs to improve. Nobody knows how to use it nowadays. These kids and their OO languages... HEY! Get off my lawn.

Re:Education, even at Universities, needs to Impro

[IamTheRealMike]

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:I'm just glad they're teaching C++ actively aga

[thetartanavenger]

Where are they teaching it actively again? I'm a student on computer science at the moment and all they teach in any depth is Java. The only reason I know c++ is my desire to learn it, despite the fact that various parts of my course have recently required a fairly in depth knowledge of c++.

My favorite lecturer quote, "Oh, I don't really do any coding at all".

He should go work for Microsoft ...

[Pinky's Brain]

"The standard will be finished in late 2008, but it takes forever to go through all the hoops of the ISO process."

They have a solution for that ...

Re:C++ has issues

[IamTheRealMike]

C++ isn't going anywhere. Nearly all serious desktop software outside of Mac-land is written in it because the alternatives (Java? C#?) suck rocks. Large amounts of high performance code is written in C++. I don't know where you got the idea that people who care about performance use C from, that's flat wrong in my experience. I agree that D is a very nice language. It will make great strides in the next five yeras. However, maturity counts for a lot.

Re:I'm just glad they're teaching C++ actively aga

[cbart387]

Where are they teaching it actively again? My school is. In fact, C++ is the primary language you learn on. There's some Java classes to expose you to it and even brief exposures to some other misc. languages (ADA/LISP/PROLOG). We also program in C for some of the classes geared towards UNIX system programming. It's a nice balance because with Java EVERYTHING is an object and it's likely to confuse freshman. Heck, it first confused me with these static mains coming from a C/C++ background. At least with C++ you can start with just functional programming to get the basis of what is variable/function/const etc and save objects till the second semester. From my experience that seems to work pretty well.

In other news...

[192939495969798999]

Profs. Einstein and Hawking are upset that people don't know more phyiscs, James Gosling is upset that people don't code better Java, and Picasso is upset that more kids don't take art class.

Java put you on Skid Row?

[Latent Heat]

Let me get this straight, that some wieners at Purdue decided to teach Java instead of C++ in their Intro to Programming course, and that you had a wiener of a prof who was teaching you Java without adequate experience, this all put you on the path to dropping school, dropping your CS major, and taking courses at community college without finishing a degree?

I will grant you that if you or the parents are shelling out the Purdue tuition, maybe their CS department should find a better professor for their intro course. I am sorry to hear that this experience dissuaded you from completing a CS degree, and there is probably a lot more to your personal story than can be shared on Slashdot.

But I would like to communicate to others out there that you will have a few good teachers in your educational career who are really inspiring, a vast group of average teachers, and a number of who you consider to be really, really bad teachers. The "bad" teachers are that way (in your opinion) for a number of reasons -- they may be "nice guys or gals" who don't have enough preparation or smarts to teach, they may have admitted to you gaps in their preparation that you have taken upon yourself to hold them in disrespect for, or maybe they assign too much HW and work you too hard.

If one is going to take a passive approach, show up to class and demand, "Here, educate me", that is a good way to fail at getting a degree and also to fail at every other opportunity that presents itself down the road. If one is going to take an active approach, working as hard as one can at learning from all teachers, the good and the bad, supplementing gaps in instruction with self-study, working coding jobs, group study, one is going to be successful at college and everything else.

To suggest that a person can have one "bad" prof means that they are on the street drinking methyl antifreeze out of a jar wrapped in a paper bag, this suggests a very passive approach to not just education but life in all its aspects.

Re:I'm just glad they're teaching C++ actively aga

[GringoCroco]

>> you can start with just functional programming to get the basis of what is variable/function/const
That's imperative programming.
You get functional programming with lisp, scheme, python, ocaml, haskell.

I've written some educational C++ articles

[MichaelCrawford]

They're at GoingWare's Bag of Programming Tricks, and are more in depth than most online tutorials.

The articles are:

• Sermon at the Soup Kitchen: On C++ Software Quality and Institutional Resistance to Change
• Pointers, References and Values: Passing Parameters, Returning Results, and Storing Member Variables with Musings on Good C++ Style
• On Refactoring C++ Code
• Pointers to C++ Member Functions

I'm no Stroustrup, but I've received quite a bit of praise for writing these.

Re:I'm just glad they're teaching C++ actively aga

[cbart387]

I'm full of errors today. I wasn't thinking of the primitives (double,int,char etc). I should have said something like 'first-time programmers have to use objects whereas C++ you can get away with keeping a procedural-oriented mindset. Therefore, you can limit what is introduced. Is that better? ;)

Re:I'm just glad they're teaching C++ actively aga

[skroll82]

"My favorite lecturer quote, "Oh, I don't really do any coding at all"." That's not a big deal. Computer Science is not about coding in particular, but understanding the practices to design and implement solutions to a problem. Computer Science is more about applied math then writing in language X. I learned some of the most important concepts in a class that was all done in pseudocode. Understanding how to approach a problem and solve it efficiently is more important then learning a language. In fact, once you know how most things are working, with a few basic concepts such as pointers or how a computer interpret an instruction listing, you should be able to pick up almost any language fairly easily. If you are not capable of learning things on your own without being handheld through a set of power point lectures, even if you knew C++ instead of Java you aren't going to be worthwhile in the real world anyways. You are destined to be a code monkey.

Re:I'm just glad they're teaching C++ actively aga

[Anonymous Coward]

Hello Gentlemen,

I'm a first year programming student at an Ivy League school and I've just finished my Visual Basic classes. This term I'll be moving onto C++. However I've noticed some issues with C++ that I'd like to discuss with the rest of the programming community. Please do not think of me as being technically ignorant. In addition to VB, I am very skilled at HTML programming, one of the most challenging languages out there!

C++ is based on a concept known as Object Oriented Programming. In this style of programming (also known as OOPS in the coding community) a programmer builds "objects" or "glasses" out of his code, and then manipulates these "glasses". Since I'm assuming that you, dear reader, are as skilled at programming as I am, I'll skip further explanation of these "glasses".

Please allow me to make a brief aside here and discuss the origins C++ for a moment. My research shows that this language is one of the oldest languages in existence, pre-dating even assembly! It was created in the early 70s when AT&T began looking for a new language to write BSD, its Unix Operation System (later on, other companies would "borrow" the BSD source code to build both Solaris and Linux!) Interestingly, the name C++ is a pun by the creator of the language. When the first beta was released, it was remarked that the language would be graded as a C+, because of how hideously complex and unwieldy it was. The extra plus was tacked on during a later release when some of these issues were fixed. The language would still be graded a C, but it was the highest C possible! Truly a clever name for this language.

Back to the topic on hand, I feel that C++ - despite its flaws - has been a very valuable tool to the world of computers. Unfortunately it's starting to show its age, and I feel that it should be retired, as COBOL, ADA and Smalltalk seem to have been. Recently I've become acquainted with another language that's quite recently been developed. Its one that promises to greatly simplify programming. This new language is called C.

Although syntactically borrowing a great deal from its predecessor C++, C greatly simplifies things (thus its name, which hints at its simpler nature by striping off the clunky double-pluses.) Its biggest strength is that it abandons an OOPS-style of programming. No more awkward "objects" or "glasses". Instead C uses what are called structs. Vaguely similar to a C++ "glass", a struct does away with anachronisms like inheritance, namespaces and the whole private/public/protected/friend access issues of its variables and routines. By freeing the programmer from the requirement to juggle all these issues, the coder can focus on implementing his algorithm and rapidly developing his application.

While C lacks the speed and robustness of C++, I think these are petty issues. Given the speed of modern computers, the relative sluggishness of C shouldn't be an issue. Robustness and stability will occur as C becomes more pervasive amongst the programming community and it becomes more fine-tuned. Eventually C should have stability rivaling that of C++.

I'm hoping to see C adopted as the de facto standard of programming. Based on what I've learned of this language, the future seems very bright indeed for C! Eventually, many years from now, perhaps we'll even see an operating system coded in this language.

Thank you for your time. Your feedback is greatly appreciated.

Re:I'm just glad they're teaching C++ actively aga

[RockoTDF]

Keep in mind that Computer Science is *not* coding. It's a subfield of mathematics that deals with the theory of computation. The lecturer might have been a theorist.

Sadly...

[Kingrames]

When trying to point the blame, his pointers went everywhere, and his program terminated abruptly.

Re:I'm just glad they're teaching C++ actively aga

[ericferris]

Too bad this was posted as AC, it deserved some funny mod points.

Strostrup is the problem

[Animats]

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.

Re:Strostrup is the problem

[vectra14]

Wow, how were you modded "Troll"? I'd mod you up if I could.

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. But yes, for most things it would be incredibly useful to have proper arrays with index checking and so on. Most templated solutions that I've seen (Boost?) are just butt-ugly and make the code that much more difficult to understand.

I think anyone that's used C++ a lot (this is probably a truism for all things) develops a strong love/hate feeling towards it. So it goes.

Re:Strostrup is the problem

[ceroklis]

I think the main problem of C++ is that people who know C assume they automatically know C++ as well. They don't. You might want to read up on this std::vector thing.

Re:Strostrup is the problem

[Animats]

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);
{ float tab[n]; /* on-stack array, sized based on fn parameter */
...}

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:Note to Bjarne, please stop!

[gbjbaanb]

Seeing as you're counting the STL in that list of features, I trust you do the same for Java or C# - how many do they have if you count the innumerable library features they support?

So long its not Matlab

[Latent Heat]

The trend we need to fight is not teaching programming using Java, C, or C++, but defaulting to Matlab as a programming language of choice. This is what is happening in Engineering colleges and other non-CS places at the U.

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.

Re:So long its not Matlab

[William Stein]

> 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.

Good idea. This is what both Sage and the Enthought Python Distribution are
shooting for.

> (Are the Python people still hashing out that Numerics/Numpy divide?

No that is done. And the lead developer of Numpy -- Travis Oliphant --
now gets to work full time on Python scientific computing, as an
employee of Enthought.

> Is there an engineering graphics library that is Numerics/Numpy compatible?

There is Matplotlib for
matlab like numpy graphics, and Chaco for more dynamic 2d graphics. MayaVi and Sage both provide powerful 3d graphics.

Re:I'm just glad they're teaching C++ actively aga

[mcvos]

For quick prototyping, use Python or Ruby. Or even Perl, if you really can't help yourself.

Yes, the lack of top-level functions in Java is well-known criticism (at least from the Python/Ruby crowd), but personally I've never had any problems with that, mostly because I don't use Java for quick scripts. The constant need to cast everything is a much bigger problem, IMO.

Linus Torvalds on C++

[Scareduck]

After agonizing over a problem that in theory should have been made simpler by operator overloading (I'm trying to do some numerical integration using a multi-precision library), I typed "c++ sucks" into Google. Lo and behold, but Linus Torvalds agrees with that sentiment:

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

...

C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes:

• infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny)
• inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.

In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic "object model" crap.

And the ridiculous thing is, this wasn't written ten years ago when C++ was still going through the ISO standardization process — it was written last year!

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:I'm just glad they're teaching C++ actively aga

[LizardKing]

Err, are you saying that you *have* to use an IDE to generate a class to run a Java app? The equivalent of your C++ main would be:

public class Test {
public static void main(String[] args) {
// ...
}
}

Why do you need an IDE to write that?

Give it up Bjarne

[betelgeuse68]

I spent 2-1/2 years at MS and if it is one thing that disappointed me it is how indifferent most developers were about learning C++... which prevented them from writing great code. Afterwards, I worked with some *NIX snobs in a dotBomb and all they ever did was trash C++ (somehow Java was "great" though).

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.

Re:Give it up Bjarne

[Sweetshark]

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. This exactly highlights the problem of C++:
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.

Why I quit using C++

[SerpentMage]

I look at your example and think, Huh? I used to code C++ (about 4 years ago) and since then shifted completely to C# and Java. And if I need some low level code I will write it in C.

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

[SageMusings]

Real Mike,
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:I'm just glad they're teaching C++ actively aga

[kisielk]

Really? I always thought the Laplace transform was invented by.. well.. Laplace? I'm pretty sure he was a mathematician, along with Euler, Fourier, and friends.

Re:32 year programmer -- use C++

[SanityInAnarchy]

Nothing is perfect, no language, no computer, nothing.

True. Some, however, are hideously worse than others.

With the [java | .net] proponents focusing on ambiguities in C++ or (gasp) pointers.

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.)

Practitioners found it both necessary and valuable to know and understand "how" their programs actually worked.

That is still useful, to some extent. However...

We needed to know how macros in the assembler worked.

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.

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?

The root cause of bad C++ is bad C++ programmers. It is not COBOL and it will not protect you from doing something stupid.

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.

Stop wanting everything to be "easier" to learn, some things become "easier" with learning.

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?

[dwarfking]

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.

Computer science is about concepts, not syntax

[Capt. Skinny]

I'll never forget those fateful words from the professor: "I don't know this language myself, so I'll be learning it with you as we go."

Isn't the whole idea of a Computer Science education to learn the underlying concepts of programming, not just the syntax or semantics of a particular language? The programming language used is merely a vehicle for conveying those concepts. The professor who was "learning [J++] with you as we go" was referring to the specifics of the new programming language, not the concepts that he was going to teach in the course. Presumably (unless he was unfit for his position), he knew those concepts well and was able to convey them to the class using whatever syntax and semantics were thrown in front of him.

The quote I'll never forget came from one of my professors during an advising session: "I'll often get calls from IT managers asking if we have any graduating students who know COBOL. I always tell them that ANY of our graduates could know COBOL - and ask if they are hiring someone for their intellect and understanding of programming concepts, or for their knowledge of a particular language."

Re:Maintainability

[Hal_Porter]

All of our C++ apps, without exception, require a nanny process to kill em when they hemorage too much memory. You have to make sure that you match up calls to new with calls to delete, free to malloc and so on. C++ only leaks when it is written by sloppy, disorganized people with a poor eye for detail.

It's hemorrhage (US spelling) or haemorrhage (UK spelling) BTW.

Re:I'm just glad they're teaching C++ actively aga

[JamesP]

"Oh, I don't really do any coding at all"." That's not a big deal.

That is BS

It is ok for, I dunno, a discrete math prof., or maybe an algorythms professor not to code. It is NOT OK for a C++/JAVA/etc teacher NOT TO code.

It is ok if a cellular biology professor is not a practicing MD. It is NOT OK for a surgery professor to not know how to open people up and not to work with that (with the rare exception of 'I can't operate anymore with a bionic hand' kind of stuff).

Re:I'm just glad they're teaching C++ actively aga

[harlows_monkeys]

I'm still astounded that a Computer Science curriculum includes any in-depth teaching of a programming language. Does the physics curriculum include courses on car repair? Does the biology curriculum include courses for the female students on how to land a good husband? Does the Literature curriculum include an in-depth study of calligraphy?

OK, I'm exaggerating a bit for effect, but seriously, most of computer science doesn't even require a computer, let alone an in-depth knowledge of any particular computer programming language. Some universities seem to have CS curriculum that would be more at home at DeVry's than at a university.

When you read Knuth, are you sitting in front of a computer? Gack, I bet that's what the kids nowadays do. The right way to read and study Knuth is sitting in a very fine leather chair, in front of a fireplace with fire, with a large dog sleeping at your feet, a drink in one hand, and classical music playing softly--and it should take along walk across a moor to reach the nearest computer.

Re:Ruby?

[SanityInAnarchy]

Where ruby is lacking is in the static department. Static polymorphism, static typechecks, metaprogramming and that stuff.

You can still use the === operator, or the kind_of? method. And I'm fairly certain metaprogramming is supported.

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.

Just wish they had used unicode as the compiler language, then we could have gotten real less-than-or-equal operators :)

I'd assumed they did? After all, Ruby is from Japan...

It is nice that it really only uses ASCII for the language itself, though. I should add that to my list.

Indeed, but only dynamic. Not overloading, specialisation or anything like that. :(

I'm feeling a bit lost in this jargon... Can you give me some specific examples?

For big projects, code completion, class summaries and refactoring support is very nice.

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.

Real constants and constant functions would be nice, though.

For what, though?

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.

Rather, I'm thinking of stuff like "you write a grammar, and the compiler+library builds the parser from that."

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?

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.

This is a point very C++ is extremely strong, though far from perfect. In practice, it requires the compilation part of the language to be Turing complete.

In other words, LISP.

Duck typing does not require the typing to be implicit. I want the compilation to fail if and only if the type passed does not meet the required abilities.

I'd argue that the sanest way to do this is to just make the typing implicit.

C++ does this with templated methods.

Which still means that you have to put everything (somehow) into the type system, in order for the template to match, if I understand it. It also means that you have that extra template syntax in order to give you something that I think should be on by default.

Yes, but it relies on a virtual machine. I do not like that requirement, and I don't think it is strictly necessary.

Why don't you like that requirement?

It is merely that if I have a function that adds to numbers, I should be able to make a function that computes a number + 4.

In the simplest case, I suppose you can define such a function explicitly:

def add(a, b)
a + b
end
def add_four(x)
add(x, 4)
end

But I suspect that's not what you want. I suspect you're talking about bind variables, which Ruby can do. (Even JavaScript can do those.)

That is, you want something like:

a = generate_add(4)
a.call(3)

And this can be

C++ is an ugly hack

[Giant Electronic Bra]

On an already ugly programming language, or at least one which is at best obsolescent from a technology perspective.

Having 25+ years of experience in the field my opinion is C++ is aweful. No amount of hacking around the edges of it is ever going to fix that. Due to the very nature of the language defect rates are exceedingly high. Even with modern development, test, and debugging tools building software in C++ is an endeavor which requires an inordinate amount of expertise, mostly in how to avoid doing most of the things the language allows you to do because 99% of them are bad ideas. Instead of learning to program well, most instruction in C++ has to be focused on how to work around its hodgepodge of misfeatures. Personally I wouldn't even consider allowing anyone with less than 5+ years of experience touch a commercial C++ application.

The whole stankin' mess should be retired. The sooner the better.

Re:I'm just glad they're teaching C++ actively aga

[dark404]

Where are they teaching it actively again? I'm a student on computer science at the moment and all they teach in any depth is Java. The only reason I know c++ is my desire to learn it, despite the fact that various parts of my course have recently required a fairly in depth knowledge of c++.
As background, I have worked with Java, C, and C++. I've also dealt with functional languages (Lisp, Haskell), scripting languages (perl, php, python), and a bunch of other stuff. In all my experiences, my response to C++ is pfft, I can live without it. If I want to get into the guts of the operating system, muck with the kernel, or do something nasty by hand in memory, I'll use C, if I want to write an application I'll use Java. C++ is a terrible language for application development, it combines all the worst aspects of OOP with all the worst aspects of C style memory handling, but brings no advantage to the table!
I'm tired of all this chest beating of wanabe's complaining oh they teach me java, but I am such an uber geek I want to learn C++! Computer Science education doesn't teach you to program in JAVA, it teaches you computer science, in the course of that you learn to program, not to program in X, but to program. Any computer scientist worth their salt can program just as easily in one language as another, and can pick up any other language just as easily.
The only big mental shifts come between procedural languages vs oop languages vs functional languages, etc. Everything else is syntactic sugar. Choose the language which best fits the problem at hand.

Re:Ruby?

[EsbenMoseHansen]

Where ruby is lacking is in the static department. Static polymorphism, static typechecks, metaprogramming and that stuff.

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.

Just wish they had used unicode as the compiler language, then we could have gotten real less-than-or-equal operators :)

I'd assumed they did? After all, Ruby is from Japan...

It is kind of ironic, but until recently ruby's unicode support sucked.

Indeed, but only dynamic. Not overloading, specialisation or anything like that. :(

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).

For big projects, code completion, class summaries and refactoring support is very nice.

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.

Real constants and constant functions would be nice, though.

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

myth

[nguy]

C++ is based on a concept known as Object Oriented Programming

That's actually a myth.

Or, as Alan Kay, the guy who invented object oriented programming, said: "When I invented OOP, I did not have C++ in mind."

(He was trying to be diplomatic.)

Re:myth

[Pseudonym]

The difference between C++ and most OOP languages is that C++ is basically a procedural programming language which has support for classes and objects integrated into it.

Wrong.

C++, like every sufficiently useful programming language, is a multi-paradigm language. It is dominantly procedural, this is true, but it also has language support for OOAD (which is not the same thing as OOP, as you correctly pointed out), generic programming, generative programming and facilities for adding embedding different kinds of of DSELs in convenient library form.

Anyone who says "C++ is object-oriented" are, much like those who refer to the non-existent language "C/C++", probably using C++ incorrectly.

Re:C++ has issues

[quigonn]

Hello Mr. n00b, you can fulfill agile requirements in any programming language. And, no, "shipping code in a hurry", as you put it, is not agile, absolutely not. It's more the Dilbert version of agile development.

Re:Sad...

[Zeinfeld]

The GC point is very simple. My experience is that less than 5% of C++ programmers can write code that does not have memory leaks and buffer overruns. So even though I can write code that I memory leak free, I typically have to rewrite other people's code written in C or at the very least spend time working out if they have a clue or not. With Java I can at least know that they will not deplete resources.

And anyone who is saying 'learn to use the leak detection tool', testing programs for correctness is a total lose. You can never test every state of anything but the simplest programs. A good GC will guarantee that there are no memory leaks without needing to test. Better code safety and better performance as well, memory leaks are the most common cause of performance problems that I see.

Re:I'm just glad they're teaching C++ actively aga

[mcvos]

I've been a professional Java programmer for 2 years now, and the more I use it, the less I like it. Java behaves like an advanced scripting language, and it's great as long as the programming tasks stay reasonably simple. But beyond some hard-to-define point, where I'm right now, Java just doesn't cut it. Too many pitfalls, too many workarounds.

In my experience there's no language that's more suitable for gigantic software projects with millions of dependencies than Java. Admittedly I don't have much experience with Python and Ruby yet, and while I see those two as advanced scripting languages, other people keep using them to build large software projects in less time than it takes in Java. But compared to C++, maintaining very large projects is much easier in Java.

If you can try to define your point, pitfalls and workarounds, perhaps someone here can give you some advice. On the other hand, all large, complex projects have their pittfalls and occasionally require workarounds. It simply comes with the software engineering territory.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Education, even at Universities, needs to Impro

[RzUpAnmsCwrds]

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.

Why the hell should they? Is knowing the title of a C book that's out of date (OK, the second edition is better, but K&R usually refers to the original edition) important?

Perhaps you don't understand what CS is. CS isn't about C - in fact, it's not even about programming at all. CS is about the theory of computation. Things like programming language theory and computational complexity theory are subsets of CS.

CS doesn't include coding practices, use of source control, project/time management, or software testing. All of that is part of software engineering.

The problem is that people expect CS programs to produce functional software engineers. And while functional software engineers certainly need a strong grasp of theoretical concepts (such as a basic computational complexity theory and common algorithms), what they really need is software and systems engineering experience.

Re:32 year programmer -- use C++

[mlwmohawk]

We needed to know how macros in the assembler worked.

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

[nguy]

The difference between C++ and most OOP languages is that C++ is basically a procedural programming language which has support for classes and objects integrated into it.

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.