java is not purely oops language,if its true then why?

[sheelap]

some people says that java is not purly oops language like C++.pls suggest me if it is true then why iot is so?

[JamesCherrill]

Primitives like int, char, float, boolean are not Objects, so the language is not 100% OO. The reason was for efficiency and speed - primitives have much lower overheads than objects.

[stultuske]

also: the use of static. just because it is written in a class, doesn't mean you have an object when you use it.

[JamesCherrill]

Of course there's no absolute universal definition of Object Oriented, so there's no definitive answer ot this question either.

Personally I worked with SmallTalk before getting into Java, and SmallTalk is definitely the most OO language of all. Everything is an object (including the code itself), and the only syntax is sending a message to an object (ie method call). No other statements ("if", "while" etc) needed or present in the language (they are just methods in the Boolean class). Similarly, the language has an assignment operator, but no others (+ - etc are methods in the Integer class etc).

[mike_2000_17]

OOP is a programming paradigm, which is to say, it's a way to reason about the code, i.e., the way you see / understand the code. It's a kind of philosophy, if you want. In very general terms, it's about looking at the overall application as a collection of objects, each belonging to a certain class that can play certain roles in the software, that, together, provide all the functionality that make the application work. Then, there are a number of practical patterns and abstract concepts that are attached to this paradigm, such as inheritance / polymorphism, encapsulation, abstraction, design by contract, etc...

Some languages have these practical patterns and abstract concepts more deeply ingrained in their language rules than others. I wouldn't really say that any language is really "pure" OOP, because programming paradigms are, first and foremost, about what goes on in the programmer's head, not in the code. It's also important to understand that programming paradigms are not mutually exclusive and don't have clear dividing lines.

You can write in an object-oriented way in C just as well as you can write in a procedural way in Java, and both of those things are actually very common. Like many other "philosophies", doing "pure OOP" software is something that only academics can afford to do. And in practice, no language can force you to remain "pure" in whatever paradigm is favored by that language, because the language doesn't control how you think, it only influences how you implement your ideas.

And the best advise I can give with regards to doing "pure" OOP is: don't. People who want to remain "pure" in whatever paradigm they favor are just people who refuse to take different perspectives on their code, to see things in a different light, or to consider other objectives or considerations besides the ones their paradigm is tailored for. OOP is certainly a very important paradigm and it certainly is very useful when its benefits are aligned with the design requirements of the project, but it would be extremely foolish to think that it is the only option or that it is always the best option, because it is neither, and that's why no practical language out there goes too far in enforcing a "pure" OOP style.

Java is not purely oops language like C++.

That is really odd that you heard that, because we usually hear the exact opposite. Java is generally considered as one of the most "pure OOP" of the main-stream languages (by main-stream, I mean, in the top-10 or so of languages used in the "real world"). At the very least, Java takes a very purist approach to its OOP syntax features (e.g., everything is virtual by default, single-root class hierarchy, no multiple-inheritance, etc.), and it sort of tries to forbid procedural code by forbidding free functions, but with static methods as an easy work-around for that rule. Basically, Java wants you to write "pure" OOP code, and if not, at least, it wants the code to look like OOP, even when it's not. This is both as source of praise and criticism of Java.

And it's also important to know that Java does not natively support many paradigms except for OOP and procedural programming. It has a half-baked and essentially useless version of generic programming. You would have to raise hell to support functional programming in it. You can't really do declarative programming in it. And it can't really support DSELs either. So, in that sense, Java is more "pure" OOP than some other languages, because, remember, being "pure" is all about closing the door to alternatives, i.e., it's restrictive and narrow-minded, not liberating.

As for C++, it is a multi-paradigm language, one of which being OOP. The OOP purists often criticize C++ because it's not "pure" enough, or because it allows things that are not part of the OOP "canon", like non-virtual functions, multiple-inheritance, and classes and objects having value-semantics. Not to mention that is hardly anything at all in the C++ standard library that is object-oriented, most of it is generic, procedural, declarative, or DSEL. The only visible by-the-book OOP code in the C++03 standard library involves the std::streambuf base-class, which very few people ever use or deal with. That said, OOP is used a lot in C++, and is one of the main options, but it is rarely used in any kind of "pure" fashion. It's all those things put together (and more) that make OOP purists absolutely furious when discussing C++. That's why they are called "purists" because they see any non-OOP code as blasphemy. And also, a very common technique in C++ is to hide away the OOP code, i.e., encapsulate the use of OOP techniques as an implementation detail, which is another thing that purists can't stand because they proclaim OOP as a great way to build interfaces, which it is not.

And with all that said, I couldn't really tell you what "pure" OOP is, and if any language actually matches up exactly to that definition. OOP, like software engineering in general, has evolved over time and exists in many flavors. You can look at some of the early OOP languages like Simula or SmallTalk. But the important thing is to learn what OOP can offer and how some of its techniques are implemented and used, and what benefit they give. After that, do the same for at least 5-10 other programming paradigms, and you'll be a pretty good programmer then, and you can pick whatever language best suits you in terms of preferred paradigms and application domains (both need to be factored in, and they are inter-related).

[iamthwee]

Mike can you further elaborate on what DSELs are. I've never come across that term before.

[mike_2000_17]

DSEL: Domain-Specific Embedded Language. It's when you create an informal domain-specific language (DSL) inside of a general-purpose language (e.g., Java, C++, D, etc..). This generally involves overloading operators and playing special tricks with the semantics of the objects and classes, which, together, completely redefine the normal semantics of the code and turns it into something more appropriate for the targeted domain, i.e., a domain-specific embedded language.

In the C++ standard library, a small example of that is the IO-stream library, where right and left shift operators take on the semantics of input from and output to a stream, and free functions like std::endl(), std::flush(), or std::setw() now take on the semantic of instructions pushed onto streams, as opposed to things that you call (in the imperative sense).

There are also many other C++ libraries that construct their own little world that looks very alien from normal C++ code, or have a lot of fancy mechanics that do a lot more than meets the eye. For example, a well-known domain-specific language for doing linear algebra and numerical analysis in general is Matlab, well, there are many C++ libraries (including mine to some extent, or also Eigen, or Blitz++) that reproduce a nearly identical language syntax, but as straight C++ (with lots of fancy tricks). Another example is Boost.Spirit, which is a DSEL for writing parsers (and related things) with near-EBNF syntax directly as C++ code (no need to use so-called "compiler-compiler" tools like YACC).

In order to be able to create a DSEL, the host language has to have a number of features, most notably, operator overloading, value-semantics, meta-programming, and a strong static type system. This is why languages like C++ or D are most appropriate for it, others not so much. Writing DSELs can be a very interesting experience, but it's very tricky.

[iamthwee]

Mike many moons ago I submitted a snippet

http://www.daniweb.com/software-development/cpp/code/216831/expression-evaluator

Which looks similar to an example on Boost.Spirit... Would that qualify as DSEL or would I have to use operator overloading and remove evaluating the expression as a 'string' for it to qualify as DSEL?

[iamthwee]

It's when you create an informal domain-specific language (DSL) inside of a general-purpose language (e.g., Java, C++, D, etc..).

Since java doesn't support operator overloading does that not disqualify it from being able to create a DSEL?

[mike_2000_17]

Would that qualify as DSEL

No, it just looks like normal C++ code. If you had this expression:

a.set("3-(5-(7+1))^2*(-5)+13");
a.rpn();

but if instead, it looked like this:

3-(5-(7+1))^2*(-5)+13;

or nearly so, and be compilable by a C++ compiler, and with the exact same output as your original version, then it would be a DSEL. In this case, it wouldn't really be possible given that it uses primitive types, which can't have overloaded operators.

would I have to use operator overloading

I would say that a DSEL does not absolutely require using operator overloading, but it very often does require it. It always depends on the domain, and what kind of pseudo-language you want to create. Operator overloading is just a very powerful way to create a new language within the host language.

The real litmus test for DSELs is "does it look like code of the host language?". If the answer is no, then it is a DSEL. For example, here is a Boost.Spirit example (parser for a comma-separated list of floating-point values):

double_ >> *(char_(',') >> double_)

Does that look like C++? No. It's a DSEL, i.e., a completely different language (still compilable C++ code, if you include the right headers).

Since java doesn't support operator overloading does that not disqualify it from being able to create a DSEL?

I was just listing general-purpose languages. But yeah, Java can't support DSELs, because it just doesn't have the necessary features, like I said, it requires "operator overloading, value-semantics, meta-programming, and a strong static type system", and Java does not have any of these features. That's why I listed DSELs as one of the many paradigms that Java does not support.