C/C++, which one first

[Anonymous]

Yes, I just read lillo's thesis (not all of it, yet) about declarative languages. (prolog is declarative, i believe) Kind of interesting.

[na_th_an]

Declarative languages rock LISP (yeah, I know, this is a "functional language", but if fits in what I'm gonna say), PROLOG and CLIPS are simply awesome for some tasks.

I mean, you can create a simple AI which learns stuff from what you say and what it asks in no more than 30 PROLOG lines. Programs that modify themselves, programs that take programs as data and process and modify them... Nice stuff for high-level nerds

[stylin]

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 think we're getting a bit off-track. My initial point was that when those or any other concepts are used in a language that wasn't designed for them (speaking from the programmers' point of view) the burden of replicating the idiom begins to overshadow the code that matters. Your Lisp story parallels that idea a little.

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.

I fully agree, which is exactly why I'd recommend C++ over C for beginning programmers; I think C++ is a better overall learning tool, because it supports concepts in native syntax that make it easier for you to concentrate on design, rather than implementation (of not only OO details. For instance, std::vector let's the beginning programmer think more about what she wants to do with an array, while C forces her into dealing with the often complicated and - at that point - unimportant details about how to make it safe to use, further burdening her with debugging hell when she mis-uses it. I'll throw std::map and std:et in there for some over-the-top examples of something better done in C++, again, from the programmers' point of view).

na_th_an: C++ isn't that "far from assembly" itself, but talking about speed in a thread like this is, I think, a little off-topic.

[NecrosIhsan]

C++ isn't that "far from assembly" itself

It isn't? :???:

[stylin]

C++ isn't that "far from assembly" itself

It isn't? :???:

It isn't as far as a novice programmer should think about it.

[na_th_an]

I just see how people around here are learning C++ and... they are not learning OOP C++. They are learning "C plus classes" which, IMHO, is a bad thing. I can tell this from the code snippets that are posted around here all the time. You get procedural code with C++ syntax and shortcuts.

[NecrosIhsan]

I just see how people around here are learning C++ and... they are not learning OOP C++. They are learning "C plus classes" which, IMHO, is a bad thing. I can tell this from the code snippets that are posted around here all the time. You get procedural code with C++ syntax and shortcuts.

That's not necessarily a bad thing though. Most coders here are probably more used to procedural coding, so procedural C++ makes more sense to them. They may not be "taking full advantage" of C++, but realistically, who does? It's the end product that matters anyways...the end justifies the means.

[Radical Raccoon]

OOP is just an overrated term anyways. Basically it's still procedural (one thing happens after another).

Learning OOP and C++ are 2 different things. When I first started learning C++, I had to learn the syntax, classes, and then about pointers. Once you get that down, then understanding the concept of OOP becomes more easy and you begin to take advantage of it. That's probably why all you see is people learning "C plus classes." Because taking on the whole new language is big enough, learning OOP is further down the road. Anyway, procedural code with classes is still a nice thing IMO.

[na_th_an]

That's the #1 reason why there's so much shitty code to maintain everywhere.

I work developing new software, but of course sometimes I have to maintain, expand old software already in use. Well, people code like crap. That's the thing. If people learned OOP properly, my life would be ten times easier.

The problem in all these discussions is that people here always think about the latest bedroom game they are coding. I'm talking about big projects, with 20 people involved. Now tell me how good designed OO isn't a must. 'Cause it is.

My claim is that, if you want to master the procedural paradigm, go for a procedural language such as C, Pascal or BASIC. If you want to master the OO paradigm, then try Java or proper C++. Don't mix things.

Radical Racoon: you're wrong. OOP aint' procedural. You are mixing therms, I think you mean "imperative". Procedural comes from "procedures". In OOP you don't have procedures. You have things that look like procedures but are NOT procedures. See? That's the problem! People have the concepts completely messed up and that's why there's so much crappy C++ coding around.

I'm not telling you that you code bad, I'm just talking big words for big scale projects. I think that you, at home, can code as shitty as you want (heck, I DO!), but, at least, you must know how to do things properly.

[Radical Raccoon]

Procedures are subs, functions, methods, aren't they? :???:

The only difference (from my current knowledge) is that in C++ classes 1 procedure is created per instance (unless it's static) whereas only 1 procedure exist in procedural code the whole time and does not belong to any specific structure. But please let me know if there's more.

Still, I wouldn't blame that issue for the main cause of bad code. Bad code has many more other influences than just that (bad team coordination, source control, just plain sucking, etc.). Not that learning the proper concepts wouldn't help or anything, just saying.