Why is Java more popular than C++

[KunjeeB]

I also tend to notice java devs cursing features that exist in c++ that does not exist in java, but praise features that exist only in java.

One such feature they curse in multiple inheritence.
My argument here is - if you don't feel comfortable doing MI then don't, if do you do then do - at least you have the option.

Some examples can be argued to be solved better with MI:

class Father
{};

class Mother
{};

class Me : public Father, Mother
{};

Surely you can't argue with this logic unless you were test tube baby :)

[rapidcoder]

I'm not my father, nor my mother. Inheritance shouldn't be used at all in this case. People who advocate MI usually don't get even the single inheritance right and you are a great example of it.

In many serious companies doing C++ development, using of multiple inheritance is a worse crime than using a goto.

Can't seem recall a java dev saying something like that.

I was saying many times on this forum, that you shouldn't use Java for low-latency applications requiring to run with very little memory. E.g. software running on microcontrollers for controlling machines in a factory. These are usually simple algorithms that can be perfectly coded in assembly, C or PLC ladder language.

You also shouldn't use Java-the-language for writing complex algorithmic stuff, because Scala does it much better.

As for the enable_if hack, I know of it, but it is merely an ugly hack and doesn't provide all the goodness you get from generic bounds in Java. It just moves the problem one step further away, but doesn't solve it.

public class <T> SomeClass {
  
  public <U extends SomeOtherClass> U process(U object) { ... }

  public void someCode() {
     T item = ...;
     process(item);  
  }

Such code when translated to C++ using enable_if, would compile, because actual generic typechecking is moved to the phase when all types are concretized. In Java that would fail with compile error. C++ templates are not a part of the type system and C++ compilers can't reason about generic types. That's why you can't be sure if your generic code is ok from the typesystem point of view until someone concretizes it. Actually, if you get syntax right, template code compiles just fine in most of cases - there is no type checking at that time. Exactly the same as old C macros, with a little exception that at least in C++ it checks the syntax and obey namespace scope.

A side effect of that (besides accepting broken template code as correct) is impossibility to get nice tool features like intellisense or type-aware error highlighting in generic code.

<typename T>
void method(T item even with all the enable_if ugly stuff) {
  item. // what your IDE offers here?
}

Java generics have been significantly improved in Scala. It could be easy to translate STL API to Scala, but it would be impossible to translate Scala collections API to C++. Lack of type bounds are not the only problem, but also lack of perfect forwarders, lack of variance control, type constructors etc.

I also tend to notice java devs cursing features that exist in c++ that does not exist in java, but praise features that exist only in java.

Features that exist only in Java? Nooo... Can't be. Many times I hear Java feature set is a subset of C++ features... :D But I understand where it comes from. Usually people start with C++ (college) then learn Java (industry). You immediately notice the missing features, while learning the new ones take some time. I know of one guy who went the other way, from Java to C++, and he says something like that:

"ok, so now I must admit C++ is not the C++ I learned at college. It is far better, more intuitive and faster to code, with all the Google goodness we use here. However, I'm still nowhere near that productive that I can be with even plain Java (leave alone Scala for a while)"

[zb0S216C]

Well, inheritance isn't always an "is-a" relationship, nor is it always a "has-a" relationship. The relationship between a base-class, and the derived class depends on the class design. However, programmers tend to represent the "has-a" relationship with object association.

In KunjeeB's example, though, the inheritance seems to use the "has-a" relationship, since a child cannot be a parent unless that child, too, gives birth. The relationship between "Father", "Mother", and "Me" does not suit the "is-a" relationship, so it could only be "has-a" relationship. However, the theory behind it seems to suggest that both "is-a", and "has-a" play a role:

"Me" is-a child, but has-a father & mother.

_Wazzak

[o1vk4iN6]

anyone else find it funny that wha rapidcoder thought couldnt be expressed in C++ templates could actually be done in 3+ ways. Just incase you missed that from last page :). If you want a good example of how multiple inheritence can be used, look at WTL or the 3ds max API (it has some classes that inherit from 20 different classes i can only imagine the nightmare of an api it would make in Java). Yes that is a bad multiple inheritence example but that doesnt mean he doesnt understand single inheritence.

[LB]

Rapidcoder, what is your view on C++'s protected and private inheritance, in relation to Java? This is something I miss in Java along with easier coupling.

[aquaz]

KunjeeB, I don't know if it's irony but the example you given is terribly wrong.

rapidcoder:

E.g. you can't directly express this in C++:

public <T extends SomeType> void function(T item);

As stated earlier, maybe you should just learn C++.

For the GC being faster, maybe on some very specialized algorithms but in general application which need performance I seriously doubt it. You know using smart pointers in C++ doesn't mean using shared_ptr evrywhere, there is also unique_ptr which doesn't add overhead and should be used if possible. To break cycles there is weak_ptr. On top of that you often not need pointers at all but Java forces you do do so.
Knowning the slowness of Java, there is many algorithms I wrote in c++ i can"t even imagine writting in Java, so, please, stop this "Java is best for evrything" nonsense. I already said it, Java has good point and is probably great for a lot of non-performance critical applications but when you want to be fast Java is not an option and no, this is not easier to write in Java than in C++ when you are used to C++(which may take some time I agree).

PS: You tell me abou Scala and co, the subject is "Why is Java more popular than C++" or I missed something?

[ne555]

> "Me" is-a child, but has-a father & mother.
"Me" is-a person, I act as a child to my parents and as a parent to my children.

[rapidcoder]

Java has good point and is probably great for a lot of non-performance critical applications

The point you are all missing is it is also great for a lot of performance critical applications. E.g. database systems, web servers, big data analytics, real time search, large scale websites (think Amazon, Twitter, LinkedIn or Netflix) and many many more. And it is used there a lot, while C++ not so much. Yeah, they use it sometimes for a small piece of code here and there. Just to be called from some higher level language.

E.g. you can't directly express this in C++:
public <T extends SomeType> void function(T item);
As stated earlier, maybe you should just learn C++.

All the solutions provided were not type-safe. They could compile for whatever object not meeting the criteria, only if the object was of a generic type. A hack is only a hack. I could place a comment on that method signature and it would give similar value. Java (and C# and Scala and many more) solved it correctly - type bounds are part of the type system. In C++ they are not. There were some plans to do it in C++, but... as usual it turned out to be a total mess, because C++ committee loves complexity (this is the "look, I invented this complex thing, I'm so clever" syndrome).

I guess this is one of the reason for C++ losing popularity - it is full of hacks, partial-solutions and leaky abstractions like that. All that together makes it not a pleasant environment to code.

but when you want to be fast Java is not an option and no, this is not easier to write in Java than in C++ when you are used to C++(which may take some time I agree).

If you spent the same amount of time coding Java and coding C++, it is much faster to code in Java. Tooling is better. Build tools are better. Standard library is better and has useful stuff in it (instead of 100 implementations of random generators). Reading someone's else code is easier. Compiler is much faster (although written in Java). It is much harder to accidentally create hard to track bugs... Lots of reasons productivity is superior in Java.

This is another reason Java is more popular - it takes much less time to master. Actually finding a good C++ coder is very, very hard. Most of the C++ coders out there learned C++ at college and... can't really program (to be honest the same I can tell about Java coders, but at least there are 3x as many to chose from, so you have higher chances to find someone good).

[LB]

Templates are real types in C++. <T extends SomeType> makes no sense in C++, but in Java where generics are fake types made as a workaround to be compatible with older code, it makes sense. Also, don't say C++ is full of hacks and partial solutions without admitting Java is too. Just look at erasure with generics, the way inner classes are named in class files (OutClass$InnerClass), the way enums are implemented (Java is a "reflective" language, the implementation really matters).

Also, I find it all too easy to shadow variables and misuse unintuitive interfaces.

Java is easy to learn, but don't you ever say it is easy to master. Too many people don't understand high level concepts like interfaces, inheritance, overloading, annotations, etc.

And you still did not answer my previous question.

I like Java, and I like C++, and I try my best not to be biased. They both have their flaws and their abilities, but you clearly are biased toward Java. I redact my support for you.

[KunjeeB]

Standard library is better and has useful stuff in it (instead of 100 implementations of random generators).

I found plenty of useful things in my standard library.

For one it will teach you about templates, with the syntatic sugar of operator overloading and overloading the new operator ...

You will learn about the different collections and other template classes and probably get a good idea of how powerful and useful it actually is.

What 100 implementations of random generators are you referring to - must say I've not used these things you talk about - I used the 100's of other features of stl.

[rapidcoder]

Templates are real types in C++

No they are not. std::vector<T> is not a type. Before it hits compiler's typechecking phase T has to be substituted for something concrete.

As for Java's erasure - yes it is a hack, but not very problematic in reality. It is easy to get around this. The main purpose of types - catching errors in your code as early as possible is retained.

[Shinigami]

Discussion about nothing :S
Which is better? JAVA or C++ is the same as:
Which is better? Linux or windows?
Which is better? chocolate or ice cream?
Which is better? POP or ROCK music?

Here are no real answer. It depends of situation and your liking.
Everything that can be programmed on Java, can be programmed on C++ and vice versa. Just something are better on Java and another on the C++.

[LB]

@rapidcoder I mean std::vector<int> is a real type that is never considered the same as std::vector<float>, whereas in Java List<Integer> and List<Float> are indistinguishable at runtime and can be accidentally interchanged at compile time. But again, I am comparing two features that have absolutely no relation to eachother.

[kbw]

I think it's fair to say that none of the arguably superior mechanisms available to C++ make it more popular than Java.

Perhaps the problem is portability and lack of common libraries is the answer.

[LB]

Definitely. I use Java for two reasons: portability made easy, and the massive standard library with all the hip gadgets. All the other reasons are why I use C++.

[rapidcoder]

List<Integer> and List<Float> are indistinguishable at runtime and can be accidentally interchanged at compile time.

They are indistinguishable at runtime only if they are empty :P And even if you manage to make a bug like that, it is still easily detected at runtime, so you are nitpicking. BTW: a similar problem exists in C++. You can check types at runtime only for objects with a vtable. For all other ones, types are erased just like in Java. All objects are just a bunch of bytes.

BTW: Erasure is not always bad. It allows for some cool features, like implementing a covariant container i.e. for type X inheriting from Y, Container<X> can be used whenever you can use Container<Y>. In C++, you won't be able to simply cast Container<X> to Container<Y> and back due to lack of erasure. That's why I like Scala collection library so much - because most of containers are covariant, so List<Integer> *is a* List<Object>.

Anyway, the main purpose of static type systems is not for checking at runtime. You should avoid runtime casts. The main purpose of static typesystem is to proving program correctness at compile-time. I was referring fully to the compile-time checking capabilities of templates and generics. And in this regard, generics are far more advanced, because they allow compiler to reason about generic types (and provide good error messages and great tooling support), while templates allow only to reason about concrete types.

[LB]

C++ is not a reflective language, but Java is, therefore you really should have this information at runtime. With C++, RTTI is just a bonus (a 'hack' like you call it).

I have a question, by the way, how come there is .class but not .method or .field? It makes me go through loops when I'm doing reflective stuff.

[rapidcoder]

1. Because that would complicate syntax.
2. Because it would be redundant - class already offers a method for looking up methods and fields.

C++ is not a reflective language, but Java is, therefore you really should have this information at runtime.

Agreed. Part of this information is accessible at runtime, though - not all generic information is lost.

[ModShop]

rapidcoder wrote:

Agreed.

Wait, did rapidcoder just agree with something someone else on this site said? I wasn't a believer in Armageddon, but now I am.

[LB]

@RapidCoder: So, .class isn't complicating syntax or redundant despite the Class class already offering a method to look up classes, but .method and .field are?