There don’t have to be extremes like “dying” or “superior”. C++ isn’t dying, its being used less. Just like Java is being used less since .NET appeared. It only makes sense that usage shifts, .NET is a better “fit” for certain breeds of developers or companies and so they should use it.
As long as you don’t start building entire application frameworks in PL/SQL, its all good IMO! 
Greetings - (nice anti spam verification BTW),
I’m a long-time simulation boffin in the aerospace industry. Unsurprisingly, we use a lot of gaming technology.
We tend to use the most expensive PCs, with the most cores. But here’s the thing - whatever we use, three to five years later, everyone has them.
And there’s the rub: the future is mulit-core. Start thinking now about immutability, concurrency and parallelism. Give it a couple more years; I reckon everyone will be rocking 8 cores in their phones.
And the JVM supports multi-threading like no other platform.
And that’s why I’m still here. Now go get some clojure.
What the heck?
The future has already been here for quite some time then 
Are you from the past?
The JVM supports multi-threading like ANY OTHER platform since a very long time. Hardly a reason to stick with Java. The real reason is because Java gets you laid.
Just don’t tell my wife!
Hmm. I must watch my turn of phrase.
I was trying to suggest that IMHO that the internal memory and threading model of JVM is the lesser of all other evils.
BTW: Here’s what you’re missing from the past: closures, continuations, conditions, numeric stack… ah, happy days…
For a glimpse of the future, try http://www.azulsystems.com/products/vega/overview
54 cores and hardware accelerated GC, anyone?
Having a well-specified memory model is a Very Good Thing Indeed. You can have all the synchronization primitives you want, but when you can’t guarantee any kind of “happens before” relationship for ordering operations, you either have to dispense with reordering entirely (thus de-optimizing your code) or rely on the behavior you get with your current compiler and arch and find out oops, your assumptions were invalid on this other arch. I believe C++11 has a memory model now, doesn’t it?
Also, it’s ironic that you point out the Vega as a glimpse of the future, since Azul is discontinuing it. Spiffy hardware, but it simply can’t compete with cloud providers on commodity hardware.
Sigh - It’s like Concorde all over again.
Until next time Internet! I’m off to shoot some OPFOR.
I actually rather meant the mess it has become. The first page usually is nothing but a collection of defs, ifdefs, ifndefs and whatnot. Then a file of all kinds of code that you have to figure out for yourself how it all fits together.
Mind you I would love to do more C if they managed to clean it up again and introduce some ‘standards’ like Java et al have.
And I think the ranking is simply a result of this. Besides that Java is simply a lot more flexible then C/C++.
Not to mention compiles a LOT faster! 
C# was interesting but had two problems M$ and feature creep. Latter meant that every crazy idea someone said it must have, was added just to keep it ‘cool’.
While many think that Java is horribly slow with new features, I personally prefer it that way. Any new addition should be evaluated and ‘Javaized’ to fit into the specs.
It is kinda like how you write interfaces. You just do not change them constantly because of some new fad.
While I am usually not one of the kind to like to hear this, but I think that if you want new features that do not fit into Java, then it might not be the right language for you.
There are new langauges for the JVM popping up everywhere and perhaps one of those has the feature you are looking for.
But let’s not stick some horns on a dog and call it a cow.
K?Thx!Bye.
I’m not for treating an established language as a kitchen sink of random ideas, but a lot of the things being asked for are not radical and have been in regular productive use for decades. As for “love it or leave it”, then well, at some point, there does come a critical mass of people who do say “it’s not the right language for me or my project”, those people become PMs and CTOs, and then hopefully the next better thing comes along. Evolution in action. I’d rather not see that demise hastened unnecessarily, and right now the JVM is too nice to put a stake into it by killing its flagship language.
I’ve called Java the C of the JVM as a sort of backhanded praise, but I’m not sure that’s fair: C at least gives me unsigned ints. Anyway, I’ve more than said my piece, all I’m doing is repeating myself now.
arg, unsigned nummbers are evil 111oneone111eleven!!!
You mean like char ?
You know it was only after a random tweet you made the other day Riven that I realised a char was basically an unsigned short. For some reason I’d never put 2+2 together there.
Cas
And now you know you can put together ‘2’ + ‘2’
‘2’ + ‘2’ = ‘d’
;D
I deliberately left that comment wide open to that reply :
Cas
As a homeless software developer once said: ‘The day you stop learning is the day you stop earning.’
:o
ends laziness and starts learning more stuffs
WRT: C++ streams. Just another example of C++ being a crap language syntactically. “Hey! Streaming stuff in my shell scripts is great…let’s toss something like that it!” Yeah…great idea. Mixing styles is always a bad idea.
WRT: C++ in general. Forget about it’s weakness, they’re unimportant. Because some language feature sucks to use in C++ doesn’t mean that it’s bad. The only “bad” feature of C++ in my opinion is multiple inheritance…but maybe that just because all of us have a little bit of a language nanny inside of us. Why not come the conclusion that class-based OO is unusable because of C++?
WRT: Overloading new. I always do. If I’m doing C++ that mean speed is a primary concern, so data flow is going to be important. You can’t just use a single custom allocator, because then you’re stuck with a unified thread-safe heap manager. I’ll have some number of region based (stack like), heap (single & multi-threaded) and pool allocators in a given program.
WRT: Paren operator. I’ve mostly seen that from hard science folks that are probably more use to some DSL (like scilab) and they are attempt to use a familiar syntax. Paren operators should NEVER be overloadable as this leads to an ambiguous syntax. Consider:
public float m(float a, float b)
{
...
}
public void foo(Mat3x3f m)
{
// value of foo depends on if Mat3x3f has overloaded a two parameter paren operator, which could change over the
// lifetime of this code. bad...very very bad.
float foo = m(0,0);
}
Notice, however, that this is not a problem for an array accessor operator. I think that in any language this should be the ultimate litmus test. Never make an ambiguous syntax.
WRT: Cas’s word infix notation. Add a colon and you have SmallTalk. IMHO…bad idea. Again due to mixing syntactic styles.
WRT: Java support muticore like no other? I think Java is very very weak for concurrency.
I love operator overloading. Looking at bad examples in C++ isn’t a proper way to consider the issue. Figuring out what is being executed would be identical to figure out for a named method (i.e. no 1990s grepping all the source files and praying to find it quickly). And I’m sure that Eclipse/Netbeans would render overloaded operators differently from default ones. The trick here is that people that have never needed to do any computational intensive programming with non-primitive types just won’t “get” how awful not have operators is. BUT: for me, operator overloading is a much lower priority that some other features (such as those listed above). And again, I think the most important in terms of wide usage would be getters & setters, which I’m now too lazy to type up a description of why.
:
If you are going to bash Java, could you at least try to make sense?
Java has had concurrency primitives and multithreading from day one, and later got lots of useful utilities. That alone is superior to most languages out there without a standard concurrency model.
If by “weak” you mean: “not the latest fad”, then yes, it doesn’t. And no, Clojure isn’t good because it places the burden on the developer. There’s a reason why dynamic memory management is excellent, a similar reason sould apply to concurrency as well.
Implementing a completely different concurrency model is impractical at this point.
Can you give one example where you do like it? Because you’d never know it given the heated impassioned ranting against all the various instances it that was just put on display here. Is it just the subset of operators you personally use?