C/C++, which one first

[stylin]

[Simulating OO in C is] more about using techniques such as encapsulation and separating the interface from the implementation. These are widely used in object orientated languages, but are just as applicable to procedural languages.

Yes, I agree. But as you imply below, the needs of the situation dictate the practicality - therefore the applicability - of those techniques. That is, in practice, those methods aren't as universal as they seem, and their use as an aid in learning a language is questionable.

[programmers] should be capable of picking up the documentation and transfering over.

Of course they should, but is it wise to recommend techniques which obfuscate what the language was intended for (I'm talking specifically about OO in C)? IMO, when you're learning a language you should at least learn how to use it properly, if not effectively. In any case, I don't think the ability to go beyond what a language is inteded to do should be a 'pro' of whether or not it's a better learning tool.

neuro: Yeah, strings and dynamic arrays in general are good examples. You can pack a large amount of power in an intuitive, and potentially worry-free package.

[Radical Raccoon]

OOP is great. I don't know why anyone would want to do it all procedurally, unless you're using a compiler that isn't OO.

If C is any tougher to learn than C++, I'd say go with C++. That's what I went to from QB, and it was tough enough.

I would hope that FB doesn't become OO, because then it really wouldn't be basic anymore.

[LooseCaboose]

...but is it wise to recommend techniques which obfuscate what the language was intended for (I'm talking specifically about OO in C)?

I'm not talking about simulating OO in C, I'm talking about using code maintainability techniques such as encapuslation which were popularised by OO languages. For example a module in C could be used for maintaining lists of information. If the module allows callees to modify the list themselves via global variables then the program is not well encapsulated, changing the storage implementation will break all of the callee modules. If the module provides a set of functions for adding, deleting, etc then the implementation can be changed without breaking the functionality of other modules. Object orientation explicitly encourages this with classes and interfaces, it is a good idea is most languages though.

A large number of things that programmers need to understand translate to most languages: algorithm choice, the difference between value and reference types, understanding immutable types, knowing what static and dynamic structures are, etc.

The programming paradigms (procedural, imperitive, OO, functional, etc) can be a bit of a hurdle, but I would still expect a good programmer to be able to learn a new paradigm in a small amount of time and be able to apply their knowledge of programming to each language appropriately.

[NecrosIhsan]

You should learn whichever one is going to suit your needs. Personally, I find C to be a bit easier to understand than C++ ("C++ turns C code into error messages"), but there are quite a few niceties in C++ that simply don't exist in traditional C. You don't have to know C to know C++, in fact you have to "unlearn" a few things from C to grasp C++, but knowing both will give you a serious advantage in the professional world, should you decide to venture there with your skills.

[stylin]

LooseCaboose: variables, functions and typedefs are also examples of encapsulation, albeit rather simple/obvious ones. The issue is not that encapsulation is bad per se, but when you start over-engineering your code to the point that implementation detail (how things are done, structured) takes it over, it's a bad thing. That is, it detracts from what the code is supposed to do and forces you to deal with how it does it, and I was responding to na_th_an's post in particular, but any naive or impractical designs made to be realized in other languages can lead to this kind of situation (I'll include boost's implementation of functional programming in C++ as well).

[na_th_an]

I said "As a language, in the purity of the word". Of course you can do shitty code in C++ and awesome code in C++, I was just talking about language design.

And I concur with everything said by LooseCaboose. The point was, everyone thinks that using an OOP or a pseudo OOP language provides you the "good things" such as encapsulation, etc - and all I was replying is that: "you don't need an OOP language for that" and "using an OOP language doesn't imply that you are using that"

I'm coding in pure C for 8 bit computers right now. And you can do all that "good stuff" without the overhead C++ introduces naturally (as it is a higher level language than C - C is almost assembly if you want).

[Radical Raccoon]

C isn't object oriented? :o

[TheAdventMaster]

C isn't object oriented? :o

. . . ?

[Radical Raccoon]

C isn't object oriented? :o

. . . ?

That's the message I'm getting from this discussion.

[LooseCaboose]

C isn't object oriented? That's the message I'm getting from this discussion.

Correct. C is an imperative procedural language. C++ is an imperative object orientated language.

LooseCaboose: variables, functions and typedefs are also
examples of encapsulation, albeit rather simple/obvious ones. The issue is not that encapsulation is bad per se, but when you start over-engineering your code to the point that implementation detail (how things are done, structured) takes it over, it's a bad thing.

Like na_th_an said, you can over or under-engineer things in any language. If a large project is becoming difficult to work with because it is structured poorly then switching to OO is not going to magically fix the problem for example. I have seen lots of OO code that has been written by people that don't understand OO concepts.

I don't believe that OO is the magic bullet that alot of the programming world would have us believe that it is. Different projects suit different languages. As an example the 4th year paper in AI at my University has an assignment for building an AI system that can be done in any language. The lecturer showed some results from previous years: C versions usually took around 200-300 lines of code, a Lisp implementation averaged 30-50 lines and one year someone got full marks with a 9 line Prolog implementation. I think Microsoft has the right idea with .NET and the CLR (Common Language Runtime). Programmers can write different parts of a single program in multiple languages and then easily combine them. The problem is that most of the languages supported by .NET currently are imperitive/OO languages. One of my friends Masters degree is looking at making functional languages work on the .NET runtime.