IE was well optimized for Sunspider already, so there is not much of a change there. Google Octane 2.0 however has always been terrible in IE, and now it comes in roughly the same as Chrome, for a massive 81.8% increase over the old rendering engine. Kraken continues this with a 45% jump in performance. It is a big change, and a welcome one too.
It would help if they mentioned what the hell these benchmarks are supposed to measure. Out of Sunspider, Octane 2.0, Kraken 1.1, WebXPRT, Oort Online, and HTML5Test, only HTML5Test has a name that means anything to me. Most of them are easy enough to google, but I didn't find anything searching for oort online benchmark. Isn't this supposed to be the author's job?
That's just it, products aren't supposed to be released with code names, that's the whole damn point. For decades code names were used just to give the people working on a project something to call it, because coming up with a real product name takes time (market research, trademark search, considering how it sounds in other languages, etc.) Ridiculous names were chosen on purpose so that they wouldn't be mistaken for actual product names. I guess some marketing genius didn't get the memo.
Developing a useful, general framework for expressing the relations among different types of entities (what philosophers call ``ontology'') seems intractably difficult. [...] a variety of inadequate ontological theories have been embodied in a plethora of correspondingly inadequate programming languages.
My favorite example of that is the Circle-ellipse problem. It seems so natural that a circle is-an ellipse, but it doesn't map to OO heirarchies the way we expect it to. The ontologies offered by OOP languages are always presented as if they were perfectly natural and universal without a hint of the lurking problems. It's not until you come up against some of these problems (hopefully early, before you've drank the coolaid) that you start to realize something's wrong.
[...] In fact, we suspect that these problems cannot be adequately addressed in terms of computer-language design alone, without also drawing on work in knowledge representation and automated reasoning.
Ok, fine, but I'd settle for less inadequate.
I think power consumption has brought back an emphasis on performance. With desktop software we were at a point where even the most inefficient languages wouldn't make a noticeable difference, except maybe in memory usage. Inefficient software won't necessarily seem slower to the user, but they will notice the power consumption. Mobile chips are narcoleptic. The faster you can get stuff done, the faster the chip can go back into lower power mode.
And on the data center side, it is kind of surprising when you see the massive amount of power consumed. Energy is already a big chunk of the costs of running data centers, and energy is probably just going to get more expensive in the future. More efficient means fewer servers. Facebook is doing a lot of stuff in C++ nowadays, and I believe power consumption is one of the driving factors there.
I'm nowhere near smart enough to do C++ well.
This is a bit of an illusion. If it would benefit you to know C++ better, I'd encourage you to not give up easily.
First, it's an illusion because when you read some template code by an expert like Andrei Alexandrescu, it's easy to imagine that this code flowed out for him as easily as writing Python is for you. But writing that kind of code is a slow thoughtful process even for experts, and even they get it wrong sometimes.
Second, it's an illusion because you're comparing your limited experience with C++ programming to people who have been doing it for decades. C++ just takes longer to learn that the languages you mentioned. Even when you feel you're starting to get the hang of it, a few years later you'll look back and realize you're still learning a lot. It isn't a matter of intelligence so much as persistence and continuing to expand your knowledge rather than settling down on some habits that work well enough but don't really take advantage of the full language.
And finally it's an illusion because other languages that have the expressive power of C++ aren't really simpler except in syntax. Consider for example a generic version of the useless function mul(a,b) which returns a times b, in C++, D, and Standard ML:
C++
template<typename A, typename B>
auto mul(const A& a, const B& b) -> decltype(a*b)
{
return a * b;
}
D
auto mul(A, B)(A a, B b)
{
return a * b;
}
Standard ML
fun mul(a, b) = a * b;
It appears that SML is simpler than D which is simpler that C++, but that's really just syntax. All of these are strongly typed, compile-time type checked, and work for arbitrary types. For example if a is a float and b is a vector of integers, then a*b is a vector of floats, which is a different type than a or b. Another example is if a is a 2x3 matrix and b is a 3x2 matrix, the return value is a 2x2 matrix. Generic programming requires you to think abstractly about operations where you don't know what the types are going to be. mul(a,b) is trivial, but if you imagine a more complex algorithm, you can see it's going to require careful thinking. It's just harder than working with concrete types, regardless of the language. Dealing with the syntax is just an annoyance.
The reward is that you get very powerful code that can be reused in many more situations without compromising type safety or performance.
I used generic programming as an example, but the same kind of arguments apply for object oriented, procedural or even functional programming. The real beauty of C++ (and D) is that you can combine these styles of programming according to what's appropriate for the task at hand. But you shouldn't expect that to be as easy as learning OOP in Java or procedural programming in C.
The lack of a built-in string is a red herring. One of the design goals of C++ is that user defined types can be fully integrated with the type system so you don't need to have special built-in types can can't be implemented as a user-defined type. It doesn't have a built-in complex number type either, but again a special built-in type is not supposed to be necessary, by design.
I completely agree with the rest of your comment. Templates are complicated, but that is getting better with recent language changes. Concepts are going to help a lot if we can ever get them into the standard. Couldn't agree more on the legacy C crud and #include. Hopefully we'll get modules in C++ soon.
These things are all better in D, especially build times. D has it's own issues though.
A preprocessor is the only way to ignore syntax errors.
Here's how to break your compile even when UNTESTED_FEATURE is undefined:
#endif
The preprocessor can't save you from developers who check in uncompilable code. I'd argue it makes the situation worse: overuse of the preprocessor makes breaking the build easier than ever and makes figuring out why it doesn't build no fun at all. Use a branch in your version control for that.
Here's your mystructure example in D:
struct mystructure { int one; static if(GREATFEATURE) int two; };
How simple is that? Sadly, C++ doesn't have static if yet, but the D implementation proves you don't need a preprocessor for that.
I was going to show how to do that in C++ with partial specialization, but it's obvious you don't care and nothing is going to convince you that the preprocessor is evil
That's fine, you can keep it.
length of an array was part of its type
The size of a statically allocated array simply is part of it's type. It's size is known at compile time, it can be allocated on the stack, or embedded in a structure without a pointer (keeping memory contiguous, without dynamic allocation, and without creating an incidental data structure.) All of which is indispensable for systems programming. It's a feature not a bug. Maybe it was a design error to make that the default array type, but simply having it is not a bug.
You can use D without automatic garbage collection, but most of the system libraries depend upon it. The two main language designers are working on an architectural change so you can use the system libraries with or without garbage collection as you choose.
I really wanted to like D, but the dependence on the garbage collector is a deal-breaker. That's a pretty big oversight for a language trying to compete with C++. It makes me wonder how well they've thought out using different subsets of the language without paying for what you don't want, which is one of the reasons for using C++.
Yes it would be nice to have a C++ with a cleaner syntax, but C++11 is already a huge improvement, and C++14 will be even better. If we can finally get concepts, it'll be amazing. In fact, C++ is innovating faster than D is.
New York... when civilization falls apart, remember, we were way ahead of you. - David Letterman
