who likes .NET?

[laserlight]

I have yet to hear of a CS program that does not feature a course on object oriented design/programming as either the first or second course.

The National University of Singapore School of Computing's introductory programming course (the mainstream one, there's also one with Scheme as the programming language) CS1010 is not "a course on object oriented design/programming". Back when I was a tutor, it was taught in Java, and even then OOP was just one component: it was and is a course on programming methodology. The follow up to this module is CS1020, which introduces OOP, but is not "a course on object oriented design/programming" either: it is a course on algorithms and data structures.

[Neo1]

Since when? It was about learning Java vs C++ at first.

Java is (in my experience) usually used to teach OOP in most CS programs. C++ wouldn't be a good alternative for this purpose.

I do agree that OOP should be taught side-by-side with other paradigms. But if the course is dedicated to OOP, C++ simply isn't a reasonable language unless the students have had some prior programming experience.

[Elysia]

You can argue the reverse since C++ supports some features that Java does not (for example, multiple inheritance, and I think, virtual inheritance).

[laserlight]

You can argue the reverse since C++ supports some features that Java does not (for example, multiple inheritance, and I think, virtual inheritance).

Well, those could be left for later. Java's interface construct covers one of the common uses of multiple inheritance anyway.

[phantomotap]

C++ is a horrible entry language if your goal is to learn OOP, and just OOP.

Unless your goal is design techniques, which just happen to fall under the "OOP" umbrella, that C++ makes easier to get right than Java.

The point I'm making here is the need to play to the strengths of the language being used when decided which techniques to teach first.

Unfortunately, a lot of school curriculum are just ........ in that regard, but of course, that's not the languages fault.

The most important consideration here though is there are a great number of "OOP" techniques that do not depend on inheritance based polymorphisms. If you focus on the technique and not the implementation strategy the less the language forces on you the better in that taking the decision away from the programmer necessarily means they aren't learning when to use a particular implementation strategy.

The standard library is tiny compared to almost any other language

No. The C++ standard library is massive; it just doesn't include things like a "GUI" toolkit.

Certainly, it includes absolutely everything that is necessary to teach lower level programming classes in schools because they should only be teaching the basics of algorithms, data structures, and enough language constructors to start down the long path of proper design and implementation.

Using a "GUI", dealing with "SQL", serialization, and stuff like that are necessarily stuff that comes after the basics.

C++ makes you deal with a lot of things that has nothing to do with OOP, Java doesn't.

O_o

The C++ bit is absolutely true, and I'm certainly not arguing otherwise.

The Java bit, well, Java also makes you jump through hoops that aren't even slightly relevant to "OOP" techniques, but at some point you need to know enough about the language to practice implementing those techniques. Pure theory would get a newbie nowhere slow.

used in many other courses aside from just the regular OOP-course

Yep, and that's a shame, but as above, that has nothing to do with the flaws of the language. That's just bad teachers being bad teachers. It would certainly apply just as much if the school taught the misuse of C++, Python, or any other language.

*shrug*

Now I'm getting really depressed because the programs, curriculum, in the USA are so very awful. ;_;

i think Java is clearly superior to C++ for students who have had no prior exposure to any programming

Well, honestly, that is, I suppose, true, at least, in that Java almost entirely forces those types of implementation details onto the programmer whether they want them or not.

That's much the same thoughts that go into choosing Scheme or LISP when targeting functional programming strategies instead of using C++. There is no point in delving into the sins of C++ when those such languages offer the possibility of those strategies with far simpler details.

But then, appropriateness of the language and facilities of a language does still come into play, and universities get that wrong, but I do agree, that has nothing to do with the language.

The more important consideration though is whether a particular implementation strategy is valuable to understanding the underlying techniques, and with that in mind, the requirement for inheritance based polymorphisms is a silly one.

An "OOP course" does not belong in an introductory programming syllabus.

An "OMG! OOPS!" course doesn't belong anywhere in a syllabus.

At no level is it appropriate to send programmers down a path that suggests there is only one technique, one implementation strategy, or one true style available to solve any problem.

That sort of ........ makes programmers particularly stupid sheep.

However, the syllabus absolutely should include "OOP" techniques, and literally form the very first day.

Starting with a foundation of encapsulation and abstraction is an absolute win!

Sure, learning to solve problems should be the focus, but learning how to solve them using existing techniques should never be far away.

But if the course is dedicated to OOP, C++ simply isn't a reasonable language unless the students have had some prior programming experience.

This is wrong minded in a lot of ways.

The point being made is that dedication to "OOP" is a false start.

As for C++, no amount of Java is going to help you with C++ if you are stuck with the notions of inheritance based polymorphisms. If you pass over `iostream' related components, inheritance based polymorphism are used almost nowhere in the standard library; they are used, but they are an implementation strategy only and not a part of the public interface.

If you know the techniques themselves and not a particular implementation strategy, you can learn the sins of C++ and implement the techniques using whatever strategy is most appropriate.

Now, yes, the curriculum used by colleges is to blame in many ways for the implications students leave holding, but Java forces much of that on the programmer, and that is problematic if your goal is a "OOP" mindset, a dedicated "OOP" mindset, instead of a technique oriented mindset.

You absolutely can do that sort of teaching in Java, but you don't throw inheritance based polymorphisms at every problem, because they are a ........ fit for some problems.

Soma

[laserlight]

However, the syllabus absolutely should include "OOP" techniques, and literally form the very first day.

Starting with a foundation of encapsulation and abstraction is an absolute win!

Aye, but while those are under the "OOP" umbrella of techniques, they are way too general to be exclusively classed as "OOP".

[whiteflags]

I've gone to school my entire life in America and I have never heard/read/seen/been suggested the phrase "OOP is the best paradigm" or "this is the only way". As far back as I can remember, it wasn't even suggested that OOP was popular or anything.

[laserlight]

The C++ standard library is massive; it just doesn't include things like a "GUI" toolkit.

Certainly, it includes absolutely everything that is necessary to teach lower level programming classes in schools because they should only be teaching the basics of algorithms, data structures, and enough language constructors to start down the long path of proper design and implementation.

When it comes to learning about algorithms, one of the things I like about the C++ standard library is the stuff in <algorithm> and <numeric>, along with the fact that they come with complexity requirements. They were a nice starting point to get me to think about those algorithms.

[Mario F.]

I'm undecided. I would vote yes. But seeing Microsoft creating cyclic technologies and deprecate them a few years later, has gave me enough of a sour taste in my mouth. Since the talks of ending with XAML after the hundreds of hours I've put into mastering it, or the actual removal of XNA after having spent nearly an year trying to become comfortable with it, I think I had enough of Microsoft. No Microsoft technology can be something I like, if I can't trust them to give me a stable development environment I can trust for many years.

Been using C# for the past 3 years, almost exclusively. The language is solid and Microsoft implementation is maybe one of the best moments in their history. I consider Microsoft's C# a superior language. But C# relies heavily on Microsoft's own frameworks for rapid development cycles. And those frameworks have been historically completely unreliable. You are forced to study new syntaxes and new semantics, only to see all that effort gone to waste, sometimes 3 years after first appearance.

Absolutely ridiculous.

[phantomotap]

Aye, but while those are under the "OOP" umbrella of techniques, they are way too general to be exclusively classed as "OOP".

O_o

Well, yea, but there is absolutely nothing that can be exclusively classified as "OOP". Literally every technique that "OOP" covers has analogues in other programming paradigms. It is just one umbrella, and there are many umbrellas.

I'm not sure about your point.

I suppose you may just be defending "An "OOP course" does not belong in an introductory programming syllabus.", and that's a problem in and of itself because a lot idiots have deluded the meaning of "OOP" to the point it is almost meaningless so the defense is unnecessary if you are only serving to say "I intended some other definition of OOP in saying OOP should not be a focus.". I already knew that; there are at least three definitions of "OOP" being discussed; I wasn't interested in attacking your definition. I was just saying that particular idea of "OOP" doesn't belong anywhere in the syllabus; a newbie doesn't need to hear it; an intermediate programmer doesn't need to hear it; a master programmer doesn't need to hear it.

Well, that and the tools and techniques belong in every syllabus; sure, you don't have to use the "OOP" flavor of, for example, encapsulation, but the concept itself belongs in every programming syllabus decorations be damned.

I've gone to school my entire life in America and I have never heard/read/seen/been suggested the phrase "OOP is the best paradigm" or "this is the only way".

Fair enough, that's bad on me to imply, even without the intent, that it is a problem unique to "OOP".

Now, you must have been at a better school than any I've seen for while certainly I've never had a teacher tell me "OOP is the best paradigm." I've never seen one not cram one a particular approach into every aspect of the syllabus and this has always been related to the "OOP" paradigm.

Of course, I fully appreciate that this is the teachers fault; I wouldn't be a bit surprised to hear that a particular curriculum at a college offering a functional programming focus abuses, and thus teaches the abuse of, approaches related to functional programming.

They were a nice starting point to get me to think about those algorithms.

Indeed. I feel the same way. Well, in my case it wasn't the C++ standard library, but all the same, that type of code works wonders for helping programmers see problems in a very consumable way.

Heck, I never really appreciated abstraction in isolation until I started working with generics.

The first time I studied some template code using "SFINAE" to implement algorithms in terms of "best fit" components I fell in love.

You are forced to study new syntaxes and new semantics, only to see all that effort gone to waste, sometimes 3 years after first appearance.

;_;

I know how you feel.

I'm getting real tired of implementing new code that ultimately does the exact same thing every time Microsoft decides to move, eliminate, or not port forward existing API.

Soma

[laserlight]

Well, yea, but there is absolutely nothing that can be exclusively classified as "OOP". Literally every technique that "OOP" covers has analogues in other programming paradigms. It is just one umbrella, and there are many umbrellas.

I'm not sure about your point.

O_o

My point is that an "OOP course" does not belong in an introductory programming syllabus. You can call it an "OMG! OOPS!" course if you want, but we're just using different terminology, since you agree that OOP is just one umbrella.

[phantomotap]

My point is that an "OOP course" does not belong in an introductory programming syllabus.

O_o

Well, then yeah, as I said; defending your point wasn't necessary; I simply was not arguing with you.

Soma

[cfanatic]

O_OWell, now that you've mastered "Windows" application you can move to systems programming.

Systems programming is for pimply, pale-faced, long-oily-haired cubicle rats. Or some pudgy, pony-tailed, heavily-bearded individual with a penchant for toy trains. I am proud to say that I am neither.

EDIT: Only joking, of course.

Been using C# for the past 3 years, almost exclusively.

If I may ask, what do you use C# for? I picked VB because I read that it was the simplest .NET language. But I am curious about the differentiation and uses for the other .NET languages ie. C#, C++(with respect to Windows programming), F#.

[phantomotap]

Or some pudgy, pony-tailed, heavily-bearded individual with a penchant for toy trains.

O_o

I AM NOT PUDGY! >_<

I am just pleasantly plump. ^_^

Although, I do admit that a family of four could live in my facial hair.

Soma

[laserlight]

And you have a penchant for certain magic ponies rather than trains, from what I recall.