Object Oriented Programming Language(OOPL)

[cambalinho]

if C++ isn't a real OOPL, what left?
with another words i want study(theory\concepts) the real OOPL. can you give me a link with these information?

[deceptikon]

Imperative, procedural, declarative, functional, object-oriented...there are many programming paradigms. C++ is largely imperative (inherited from C), supports OOP, and has been introducing functional aspects lately.

Try looking at Wikipedia for "programming paradigm".

[cambalinho]

sorry... i didn't get the mail notification :(
http://en.wikipedia.org/wiki/Programming_paradigm
thanks for all

[mike_2000_17]

When people say that C++ isn't a real OOPL, they mean one of two things:

(1) C++'s implementation of OOP mechanisms (inheritance, virtual functions, etc..) is not "pure" OOP, or not pure enough.

(2) C++ is a multi-paradigm language, and OOP just happens to be one of the main paradigms that it directly supports, but not the only one.

I fall in the second category, as most experienced C++ programmers do.

And I despise people who fall in the first category, we call them "OOP zealots". It's true that C++'s implementation of OOP does not fall perfectly in line with the rigid dogmatic definition of OOP (or how an OOPL should work), but any reasonable person would say that it's "close enough", and would probably also say "who cares?". And if I'm gonna be frank, people who attack C++ as not being a "true" OOPL are often just making pity "grasping at straws" arguments against C++, a language they love to hate. Don't listen to those fools.

In my perspective, OOP was the awesome new way to program back in the late 80s and early 90s. Some still see it that way, but they just haven't kept up with the times. Modern C++ code makes very limited use of classic OOP style. Yes, OOP is "classic", not new or modern. I remember, when I first learned to program, in the late 90s, OOP was already the classic programming style.

A big part of this issue has to do with the inertia in academia. There are still tons of professors teaching OOP as some kind of awesome new paradigm, and conduct their classes in "pure" OOP languages (Java or C#), as if they were asleep for the last two decades. In fact, this is probably the majority of professors in CS.

The truth is, OOP is an important, fundamental and classic programming paradigm that every programmer should be very comfortable with, just like procedural programming. But it's not a silver bullet, nor is it the "one paradigm to rule them all" so to speak, or nor is it the important that the language be "pure" OOP.

A much more interesting topic is "multi-paradigm software engineering". That's something you should sink your teeth in. That's what modern C++ is all about.

[cambalinho]

thanks for all to both

[rubberman]

"Pure" OOP language? Try Smalltalk... :-) I used it to prototype a lot of concepts that I implemented for production in C++ in the early-to-mid 1990's.

The rub was that for what was simple in Smalltalk, required a LOT of prep work to function with C++. About 6 months of intensive design and coding to be sure!

[cambalinho]

i have question: if properties and events are OOPL too, why the C++ don't have it?
(unless we do it)
i think it's basics of OOPL too

[deceptikon]

i think it's basics of OOPL too

And therein lies the problem. There's not a single "official" definition of what features a language must have to call it object oriented.

[cambalinho]

sorry what you mean?

[deceptikon]

I mean "OOP" is vague.

[mike_2000_17]

As deceptikon says, object-oriented programming has a very plastic definition. Whenever an "OOP" language incorporates a clever feature, some start calling it a fundamental part of the paradigm, to the exclusion of any language that doesn't incorporate the same feature, or not to the same extent or ease of use.

In some sense, there's a Borg-like assimilation effect at play. Holding OOP on a pedistal often implies that any other "clever" programming pattern or technique must be somehow made a part of OOP, both to reinforce the glory of OOP, and to deny that there are clever non-OOP solutions to certain problems.

If you precisely define OOP as a certain set of mechanisms (e.g., run-time polymorphism) and certain design patterns, then you have to live with the fact that it will only be an appropriate paradigm to use in some situations, but not all. Some people can't live with that idea. I've met some of them, you can see, in their body language, the strong physical discomfort when you demonstrate to them a good programming technique that does not draw anything from OOP or follow any of its doctrines.

At the end of the day, programming paradigms are just about the way you understand the code. And describing "the way you understand the code" is difficult to do in concrete terms. It's often difficult to describe it in UML diagrams too, due to their limited descriptive power.

I don't think it is useful to use the term OOP to mean too much stuff. I tend to reduce it down to just referring to code that employs run-time polymorphism (with base-classes, inheritance, virtual functions, and RTTI). In that sense, it's not a very interesting topic to me because it's just a basic classification of type of mechanisms used to modularize the code. It doesn't pertain as much to the understanding of the code or the control flow. That's why I talk about "abstractions" instead of "base-classes", or "functional requirements" instead of "virtual interface", because these are terms that more clearly convey how you should understand the code without necessarily enforcing a particular implementation mechanism (which may or may not be an "OOP" mechanism).

For instance, abstractions can be created in many different ways. In procedural programming (i.e., C-style code), people create abstractions, but they call them APIs (Application Programmer Interface). In object-oriented programming, base-classes (or abstract classes) are the abstractions. In generic programming, abstractions are generally called "concepts". In other more loosely coupled architectures, like event-driven arch., service-oriented arch., publisher-subscriber systems, and other variations, they use other terminology and formulate abstractions in terms of what they publish or subscribe too. Each of these "paradigms" come with their advantages and disadvantages mainly in terms of flexibility, performance, and reliability.

The point is, you cannot entrench your understanding of software and your design practices into a single one of these "implementation paradigms" because it will limit your thinking to the limits of that paradigm, and pre-emptively make an important design choice (which paradigm to use) without weight the options as you should.

[cambalinho]

so the languages have their own OOPL. and some more easy than others. like the classic program language(they can be diferent, more powerfull, more easy). but true the C++ is general purpose language(for any type of projects).
thanks for all

[mike_2000_17]

No, I think you would do well to just put the "OOPL" term out of your vocabulary. It's largely a meaningless term, IMHO.

[cambalinho]

i understand. thanks for all.. realy.. thanks for all