c0de517e

Fortan is -undoubtedly- thought as a HPC. That doesn't mean it's great or I would use it today, but yes, without a doubt it is one of such languages.

That's not to say that if today I had to write, as I do, a tight CPU kernel, I would not chose C or C++, these have the best compilers and tools and are more general languages.

But C++ was never designed to aid stuff like numerical computation, never. It was designed to be zero-overhead on top of C if you didn't use any feature with overhead. That means that it can go all the way down to C performance, and C is considered almost as a portable assembly, so it's quite low-level.

Low-level and high performance are not entirely the same thing!

In fact you can easily, easily outperform -standard- C++ in many interpreted languages that support vector operations or GPU offloading, for example matlab.

If you want a c-like cpu hpc language for tight numerical kernels to integrate with c functions, look for Intel's ISPC

To both comments - it's not JUST because the lack of threads, don't take an example as the entire extent of the critique. It lacks threads. It lacks SIMD. It lacks control over pointer aliasing (restrict), something that FORTRAN did right decades before C++ and C is doing today but C++ still lacks, and it's quite fundamental to write high performance kernels. It does -NOTHING- of the things that are needed for performance, all these things had to be added by custom compiler extensions because it's a popular language and we have very, very good compilers, but the language standard itself lacks in a lot of ways for HPC

Really I don't often use classes, unless they are providing a benefit. Just using them to group some state with some functions is not great because they have lots of drawbacks for that, I find an opaque pointer and C functions to be better at hiding implementation details and so on. I use classes basically when I need destructors and constructors, so for things that need to go in collections really. http://c0de517e.blogspot.ca/2012/09/follow-up-why-classes.ht...

The question you should ask yourself is - what other languages I do know to compare C++ to?

Do you know about hygienic macros in scheme? Standard ML parametric polymorphism? Haskell type classes?

But even more mundane stuff like D's templates? Code-generation and reflection in C# (not to mention generics)? Scala's generics and parametric polymorphism?

The lack of GPU support is indeed widespread and really quite forgivable today. Threads, SIMD and restrict are not.

And you're right about C++11, my bad. It's funny how C is actually pioneering a lot of the changes actually required for performance while C++ thinks about standardizing Cairo for 2d graphics...

In fact I argue that a strict C++ replacement won't really cut it. But it's very wrong to say that "you'll end up with the same complexity and rules as C++", that's the justificationist argument that says that C++ is the way it is because given its goals couldn't be any better. And D is there to prove that line of thought UTTERLY wrong.

I might have written too much about the languages I intended just to bring forward as example.

D is not high-performance (I clarified that in the post) the same way as C and C++ are not. They are not meant for HPC, they are meant to be "systems" languages.

The difference between the two is that HPC is usually about parallelism and has always been. Instruction level (SIMD and GPUs), threads, clusters and so on. D is a bit better than C++ as it at least standardizes SIMD a bit, but still IMHO it doesn't qualify as HPC.

C++ adopted threads only in 11, doesn't have SIMD, doesn't know about GPUs, it got "restrict" only in 11 as well and so on and on. It's clearly not for HPC.

Nowadays most of the code I have to deal with and that I write myself is very "c-like" C++. For personal projects I usually use C# instead.

The solution is - more objects wrapping more objects. I can already imagine people doing exactly that.

Dependency injection is the name of the game right? That's what videos on youtube are advocating...

But it's also a pain to pass everything that is needed down to functions, so let's stuff all the global state in a class and pass that class down!

I hope I just didn't get the sarcasm, really.

There is an appropriate application of almost any tool, what's wrong is the hype behind certain ones. By abandoning the fad I don't mean that now everybody will never use OO again, but that OO had become the -default- paradigm for -everything- (even the only one that gets taught nowadays), which is completely utterly bullshit.

- Angelo from c0de517e