What's the name of this school? I need to ensure I don't send my kids to one that doesn't teach the difference between a procedural programming language and an object-oriented programming language.

Ummmm, Java is interpreted. Or rather, it's compiled into byte-code which is, in turn, interpreted by the JVM. The line between interpreted languages and compiled ones is becoming far less clear these days. All the .NET systems work along the same lines too.

FWIW, MY high school tried to teach BASIC, but all they had for an instructor was a math instructor who didn't really understand computers. When I wrote an assignment using gosub blocks (no subroutines in real BASIC), it confused him and he marked it as wrong. When I went to college, we learned Pascal, with Fortran and COBOL as side dishes, on our big iron VAX/VMS mainframe cluster. "C" was a new fangled thing that they finally offered bundled together as a "UNIX/C" class for the shiny new Sun workstations.

I'd say that's a pretty significant amount of change for less than 20 years. So I wouldn't be so sure that C++ won't be dethroned in the next 20. After all, nobody EVER thought COBOL would go away. :)

MAIN.
DISPLAY 'I hear that!'.
STOP RUN.

Funny. Last I checked C++ fully supported procedural programming, given that it was designed as a multi-paradigm language and is (essentially) just a superset of C. :P C++ is usable for procedural code, object-oriented code, and even functional code.

With the exception of exceptions (pun not intended… but I giggled anyway), C++ is nothing more than a layer of syntactic sugar over C that makes it easier to wrote OOP-style and functional-style code. Absolutely nothing stops you from writing equally object-oriented code in C. Take a look at glib for a popular example of doing OOP in C. Heck, C++ originated as a veneer over C. Much like the C#-clone Vala is just a veneer over C.

This is vastly different from languages like Java, C#, Smalltalk, Ruby, etc. which are true object-oriented languages. In such languages you have to emulate procedural programming using methods and objects in the same way that you have to emulate object-oriented programming in C using functions and structs.

So which school did you go to? :p

*sigh* You stated… "teaching C++ is more or less the same as teaching C", which is utter garbage. And of course you can implement an OO design in any language, but why on earth would you? I can hit a nail into the wall with a coffee mug too. It's about using the right tool for the job, and I would hope schools are educating students with that in mind.

No, I did not. That's twice now you've attributed that quote to me and twice now that you're wrong.



I firmly disagree with you. I think David (the person you're actually quoting) has it right, albeit a bit oversimplified.

I've seen classes where the instructor tries to teach C++ as something wholly different than C, and pretty much every one of those students comes away confused and incapable of using the language properly. Teaching C++ is IDENTICAL to teaching C, followed by teaching how to use OOP in C++, followed by teaching the more advanced C++ facilities. The actual concepts of OOP should be taught separately with a more appropriate language (before learning C++ of course).

Teaching C++ as anything other than C with extensions is teaching people to use the wrong tool for the job. There are far better languages than C++ for most every need; C++'s true strength lies in the fact that it is just C with a lot of useful crap added on to it. Failure to comprehend that point is exactly what leads people like Linus to think C++ and its users are stupid. If you don't comprehend C, then you _do not_ comprehend C++. That C++ makes it easy to abstract away the details of C does not remove them. C++ IS C, and it isn't possible to teach C++ differently than C without teaching it wrong.



The reasons vary, but they exist. The better reasons essentially boil down to sometimes needing the low-level nature of C but needing a very different model of OO than the ones offered by C++ or Objective-C.

I think he means that the procedure for teaching the two languages are pretty much identical. Granted, C++ will be a little bit more, seeing as you have to teach STL, using templates themselves, references, methods, etc. But you can take the initial steps of learning C and change them to match C++. So I don't think it's garbage at all. Just because one language takes those extra few steps doesn't mean you don't take the previous steps to get there.

Yup, the quote nesting messed me up.


Nope, but it's pointless to argue further. We're both entrenched in our beliefs on this one, although I think we at least agree on the importance of teaching the programming paradigm, and then the programming language(s) that support it.

From experience, it's because so many new grads have learned C++ as an extension to C that it gets misused, and the resulting software is too ugly and costly to maintain. The embedded software industry has largely shifted back to C from C++ because of this.

Well the school I attend, The New England Institute of Art, offers game programming and other majors under the Bachelors of Science: CSI department. All using C++.

It doesn't really matter, but if you must know, it's a small school on the west coast of the US called Stanford University, you may have heard of it.
EDIT: and why teaching C++/Java instead of C means that the difference between procedural and OO programming are lost is quite the mystery to me… a very quick look at the curriculum would reveal how incorrect that is. :shrug:

Everything you can do in C, you can do in C++. That was one of the core design principles. Therefore, if you truly know C++, you can do anything a C programmer can do. That's pretty much the very simple end of the story. As Elanthis has said, C++ is C with many encapsulation mechanisms built-in. It's perfectly possible to do object oriented programming in C. People who think that OOP means the language having a "class" keyword are either plain wrong or merely ignorant (and I mean that in the best possible way, not as an insult).



Igabod, I'll write up some thoughts on that question and post them shortly.

My point is getting lost, so I'll try to make it one more time. Although C++ is a multi-paradigm programming language, it's feature set is geared towards the object-oriented paradigm, that's its most common application, and it's in that context that (I feel) it should be taught.

We bring in new grads, and it often takes a while for them to adjust to a purely object-oriented paradigm when using C++. Perhaps the real issue is that there's not enough emphasis on the different paradigms in the curriculum, and courses that focus just on design and modeling, ideally using UML tools, could be beneficial.

Then you need to start hiring graduates from a different university (or look at some from out of the area). I think that you believe that its feature set is geared towards the object-oriented paradigm, but I think personally that is a wrong assumption. C++ was designed to be fully backwards compatible with C, but to also allow for easier object-oriented design than C does. But I do believe that your last statement is correct: there is not enough emphasis on the differences of paradigms (as well as the use of modeling tools such as UML). I personally don't like UML and it my university you don't really get to use it until you delve deeper into software engineering (which tends to be at the graduate level).

As for the original topic, I see no reason why anyone creating a MUD engine now (as in today) would choose C over C++. I don't think there is a reason. If you really want to code in C (object-oriented with function pointers, et al) then its more than possible; C++ IS C.

As for C++ being geared for OOP… well… kinda. The folks who designed the C++ language were the same folks who were pushing OOP as the silver bullet of the software world, much the same way the folks at Sun working on the Sparc CPU were also the folks pushing for its 1 cycle-per-instruction set as the silver bullet of hardware. The sparc folks were wrong, as was shown by the fact that CISC CPU's perform better because of the time it takes to load instructions into memory…. when each instruction does more, more fit in the cache, and they take less space on disk. It remains to be seen if OOP *really* is more efficient to use.

Part of the problem is that far too many people put blinders on and pretend that C++ is a "pure" OOP language, like Smalltalk. It's not. Sure, given the right circumstances, encapsulating things in objects lets you re-use code far more efficiently than having to cut-and-paste in a functional language. However, I've just as often seen people waste HUGE amounts of time building enormous class hierarchies, and refactoring their code endlessly to try and cram it into those "bubbles", and think they could have written a handful of functions and been done three weeks ago.

Again, right tool for the right job.

There's no reason to use C instead of C++ these days, unless you're working on legacy hardware where no C++ (cross)compiler exists. There's also no reason to insist that using C++ means forcing *everything* into objects. Teaching OOP in isolation is as much of an Epic Fail as ignoring it entirely.

How about instead, we teach kids how to solve problems, and show them which tools are likely to be used in the marketplace when they graduate? Let THEM decide if they want to join the C++ .NET legions, or go poking around the fringe with ruby, python, or whatever comes up next? Stop teaching languages and start teaching programming. :)

Here here. Or is it Hear Hear. I dunno. Hear here? You get the idea. :P

Noplex put it well: C++'s feature set lets you do more nicely what you can already do. You can write object oriented software in almost any programming language. If the language has the right structural concepts, that just makes things easier.

Incidentally, in my experience, students write far superior code in C++ than they would in C, because the abstractions let you go quickly and structure your code more easily. Any abstraction that helps add structure and ease of thinking is good.

Recall that just because you have the "class" keyword floating about doesn't mean you actually have object oriented programming. You could use classes simply as an encapsulation device, without worrying at all about the "OOP" aspects of inheritance, virtual methods, and so forth.

But Quix is of course fully correct: the point is not to learn a given language, the point is to learn how to program. You know that you are a truly good software engineer when syntax becomes nothing more than window dressing. People who only "learn C++" or only "learn Java" are not learning to be computer scientists. (Now, of course, you could always learn the concepts and use a given language as an example, but you need to be careful to not get too bogged down in a specific language. And of course, again, you also need to not stay with your head so high in concepts that you don't actually learn to write code…)