Is C++ too dificult to be popular?

[porpoises]

I am reading an article talking about there are CS courses escaping C++ but teach java instead because it is too hard.

Is it ture? what do you feel about C++?

http://quantjob.blogspot.com/2009/02/sventh-thing-i-hate-about-your-cv-you.html

[DemonWasp]

First, C++ is popular. Or rather, using a bastardised mishmash of C and C++ is very popular.

Second, C++ is a difficult language not because of the concepts involved (it's fairly simple), but because correctly implementing a program - in particular, debugging that program - often relies on the programmer knowing exactly what's happening behind the scenes. You often need to know exactly what the compiler is doing, exactly what memory looks like, exactly how the syntax for X behaves, etc. This problem becomes exacerbated when you're dealing with multiple platforms, using different compilers and their various "quirks" (a generous term; I might also use "huge #$%!ups"). The difficulty stems from poor encapsulation.

Much of this is by-design: C and C++ were intended to be relatively low-level languages, barely shielding the programmer against the intricacies and insanities of the actual CPU. To my mind, this makes C++ sort of an odd duck: it's both low-level (close to hardware) and high-level (OOP); it doesn't appear to do either particularly well, C being better for low-level and pretty well anything except Turing being better for high-level.

That said, while C++ is difficult and perhaps not a terribly great plan in the first place (being split as it is between high- and low-level), it is full of the sorts of knowledge about computers that you just don't seem to find anywhere else. In the land of Java and other high-level languages, abstractions abound, and the code you write is more oriented towards a pseudo-machine that does exactly what the code says; the ugly reality of the CPU is managed by some sort of virtual machine layer. While that's way easier to actually write code in, it only teaches the learner about the system itself, not about anything underlying it. Learning Java teaches you about the JVM (a fairly decent piece of engineering in itself, putting aside what you may think of the language) and what a good set of library classes and functionality looks like. You learn nearly nothing of the machine, of the operating system, of how the network actually functions, etc; C++ forces you to learn all of this as prerequisites to using it correctly.

This is probably why schools have started turning to "easier" languages like Java: they don't force you to learn the immense mountain of information that C++ does. A student can focus on the data structure or algorithm at hand, in an environment free of the distraction and complication of C++, particularly in debugging C++ applications. The class moves faster and covers more ground, with students getting a better grasp on the material. Later courses can cover C++, once students know more about processors, compilers, operating systems, memory, cache, networks, disks and IO controllers and all of the other crunchy bits of the machine.

To be honest, C++ also really sucks at multithreading. Like, really really sucks. It should NOT be the language of choice for a class on, say, Concurrent Programming. I hesitate to recommend any particular language, having not coded any parallelised programs myself (I've been working on one at work, in C++, on multiple platforms...ask me how that's going!), but Java seems to do a pretty nice job of it.

[jbking]

I can understand the first programming language to teach someone being something other than C/C++ since they are languages where it is easy to shoot yourself in the foot if you aren't careful with pointers which can be a rather advanced concept compared to say writing a program to take in user input, perform some basic operations on it and output the results. I can also understand that there is some value in going into other languages and programming paradigms which is I think part of the point in the article, do we get exposure to various styles of programming in our undergrad years. I think for myself the answer is yes where at Waterloo I went from Pascal first year to Modula-3 for second year and C/C++ for 3rd year in programming courses x4y course names.

I think there was a variation on C++ called micro-C++ that was used for Concurrent Programming(CS 342) back when I was at Waterloo.

[porpoises]

I am getting very professional answers here. Thanks alot.

I wonder after your class in C++ can we take a job (or graduate job) requiring C++?

If a computer science student may think C++ difficult, how about a chem eng graduate like me try to teach myself in C++? I did coursework in Matlab, C, Forturn by the way.

How much skill needed to be like a proper software engineer?

I am a chem eng grad with some programming skills through coursework and thesis. since the job I was called by agency are all programming, i want to know how far i am away to turn into a software engineer. I am quite interested in programming aswell.

[DemonWasp]

You can probably pick up C++ on your own or in a class (as I did), but until you start working at a job where you're forced to really use it and deal with the full toolchain, you won't really know much about it. The toolchain here refers to the compiler, linker, archiver, loader, debugger, build tool, etc; they're a clever set of tools designed to make it less painful. Experience in C will help, as will experience with UNIX platforms (BSD, Linux, Solaris, AIX, whatever). In particular, experience with make or Jam is probably vital.

Knowing C++ is (WAY) less important than knowing how to program. I don't know how extensive your coursework is, but there's a good chance you never did much in the way of "real" programming. If you don't know what a Binary Search Tree, Breadth-First Search, AVL Tree, Trie, Queue, or Linked List are, that's a good indicator you've got most of your learning on the "process / algorithms / data structures / how computers actually work" side; if you know all of those, then it's more about learning specific tools.

Being a proper software engineer is pretty heavy; you'd need to take quite a few courses as there isn't much overlap with ChemEng in most universities. If you're interested in the topic (and have the resources - time and money) to do it, go right ahead. It's challenging, but if you're motivated it's a good kind of challenging.

@jbking: Yeah, I've heard of micro-C++. I'm hesitant to remark on it, having never used it, but I'm not a fan of C++ in general and I don't expect any homebrewed variant to improve the situation much. UWaterloo also offers a "languages" course in 4th year that exposes students to a variety of different languages and programming paradigms; I haven't taken it yet, but I intend to.

[wtd]

http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

[jbking]

After my class in C++, it is possible to get a job using C++ though it can depend a bit on how deep a knowledge is required. For example, if the job is building C++ compilers, then after one class you likely won't have all the pieces to do that. There will always be some on the job training, which can be trial by fire where you are given problems and have to figure things out on the spot in addition to more structured situations for learning how a specific company does things, and what I got back in 1998 at my first job after graduating was no different. I was using Visual Studio 6.0 involving MFC stuff that I hadn't heard of before on an O/S called NT 4.0 that took a few weeks before I was contributing code.

Anyone can get some of the basics of C++ down. There are simple programs that shouldn't be hard to write like reversing a string or testing if a number is prime or a few other things that most would call easy. The key is to able to absorb new knowledge and apply it in various ways. Algorithm starters like "Divide and conquer," "Dynamic Programming," and "Being greedy," are things that aren't language specific but can be useful for learning how to solve problems. Another side of things to learn is the Software Development Life Cycle which has a few main parts: Gather requirements, Analyse and design solutions, implement solutions, test and deploy. Don't worry if some of those don't mean much yet as you could google any of them to get oodles of things about them.

To be a proper software engineer, I don't know really as the engineer part has specific interpretations in Canada. My programming experience was years before university and years during university though I suspect it could be distilled into a crash course that one could take over the span of a few months if they spent enough time on the basics.

[Dark]

Picking up on C++ after java isn't all too bad.

[md]

Java teaches a LOT of bad habbits, but then so does just about any battery.

C++ is no harder or easier then C or assembler or any other language that's close to the hardware. In fact, C++ is slightly easier to pick up then C, IFF you have an understanding of OOP. 'Course, once you have a familiarity with any ALGOL type language it should be fairly easy to pick up another one.

[SJ]

Dark @ Wed Mar 11, 2009 3:36 pm wrote:

Picking up on C++ after java isn't all too bad.

agreed. to me, java feels like motherland, c++ is canada.
and c++ isn't "too difficult," the concept is pretty much the same as java, or heck, any language.

[rdrake]

I believe the argument that C++ is too difficult to learn after Java because Java won't let you hurt yourself at all. Sure it has absolutely ridiculous restrictions but it won't let you hurt yourself.

C++ in itself is a beast.

[md]

I think the larger issue is not what language you use (though Java is far from good for teaching this), but that students are not taught how to think or problem solve. Instead of having an understanding of how a bubble sort works or how to efficiently search an array, students simply copy and paste code (at the behest of profs even!) and hope it works.

I think in large part this is because students are lazy, and profs for the most part don't care if their students actually know how to program instead of just knowing how to copy and paste code into some semblence of a working program (and even that isn't usually required). Unfortunately I cannot think of a good way of both rewarding a prof for actually teaching well, and at the same time discouraging them from helping students by writing the code or showing them how to copy this bit from this program into this other bit in this second program. Or, worst of all, assign programming projects where you can pass with a 80% simply by having very good documentation and a good presentation - and no working code.

[wtd]

It's worth noting that C++ is a big, complex beast of a language. Learning it takes a lot of time and dedication and the ability to look past frustration to see long-term goals, and if you can't summon those attributes in yourself, you may wish to give your choice of careers a second thought. It will not be the last such challenge you will face, though it may be your first taste.

That said... C++ does not convey any particularly great programming wisdom that cannot be gleaned elsewhere. If you find it frustratingly difficult, you may wish to evaluate why you are learning C++, and if your efforts are not better spent elsewhere.

In short, you need to be able to deal with the kind of frustrations C++ can throw your way, but they don't need to come from C++.

[Prabhakar Ragde]

md @ Thu Mar 12, 2009 10:58 am wrote:

I think in large part this is because students are lazy, and profs for the most part don't care if their students actually know how to program instead of just knowing how to copy and paste code into some semblence of a working program (and even that isn't usually required).

Since I am feeling less cynical than usual today, let's put this in a positive way.

Students say, "What does learning a new language get me that I don't get with Java?", and since the answer (unless the new language is radically different, which in most instances where this question is asked is not the case) is usually something like "Java is too slow for doing this in production code," or "Not every workplace uses Java," there is an obvious incentive to put it off.

Professors say, "The important thing is understanding this concept and being able to translate it into some semblance of an implementation. Now, I can teach them the language in which this concept is usually implemented, but that will take time away from the real subject of this course. They already know Java. Let's use that."

When I learned computer science, we were hit with something like six or seven languages in the first four courses, and after that we were expected to be able to pick up the rudiments of programming in a new language by ourselves, so the professors could teach the concepts and yet ask us to use them in a language that made sense. Somewhere along the line that idea went away, and even those who are saying "Not just Java" tend to be okay with "Just C++", or "Java and C++".

[wtd]

I agree with everything in that post, and would encourage aspiring CS students to become polyglots. Programming languages are tools. Even if you have the most powerful hammer, you're no match for the person with a diverse toolkit.

As a corollary to this, if you're going to have a diverse toolkit, it is often helpful to choose tools that don't take a long time to learn to use. The quicker and easier it is to pick them up, the more tools you'll have at your disposal.