OOP's unique feaures can't deal with massively parallel CPUs. In the future the following will not be allowed:
The following are not allowed for the core data in your code.
Recursion.
Variables declared with the volatile keyword.
Virtual functions.
Pointers to functions.
Pointers to member functions.
Pointers in structures.
Pointers to pointers.
goto statements.
Labeled statements.
try , catch, or throw statements.
Global variables.
Static variables. Use tile_static Keyword instead.
dynamic_cast casts.
The typeid operator.
asm declarations.
Varargs.
OOP may live at the top level of granularity, but when it does for working with your data, OOP is not compatible. You can choose which module to run with polymorphism, but you data can't be be processed with virtual functions.
With "in the future" you mean "currently, in a restricted subset of C that runs on massive numbers of very simple cores". Massive parallelism is also possible with somewhat less simple cores; CUDA and OpenCL also started from the "bare subset" philosophy but gradually expanded to allow more flexibility because developers demand it.
And of course massive parallelism is also possible with normal CPUs, in a cluster or in the cloud, and there an entirely different set of restrictions hold, not so much on the programming language but on higher level design.
Whether or not you need to restrict yourself to a subset of C completely depends on your requirements. The future is heterogenous, not homogenous [1].
Notice that C++AMP is a language extension designed specifically for heterogeneous computing, and it is where this list comes from.
The article you posted was rather extensive and as somebody who works in HPC, I can say that I disagree with many points in link provided. Also it was too god damn long to read. Most notably, that somebody needs to actually write the cloud implementation, will still require models like OpenACC or CUDA.
There is not reason hat whatever mechanism was used to push parallelism onto the GPU can't be used for moving it onto the cloud.
There is an infinite amount of musing that can be made against and possibly in favor of expanding the acceptable language features in threading kernels. Yet, it is safe to say 3 things.
1) Simple kernels run faster
2) Current specifications are closer to C++AMP's restrict(amp)
3) Cloud computing uses GPUs for the data crunching
My point is that you're focusing on low level kernels only, which obviously need to be simple and highly optimized. However, the number of people actually writing lowlevel HPC code (the super-optimized number crunching inner loops, usually embarrassingly parallel), compared to highlevel code is very small, and certainly isn't the only focus of "the future". It's safe to say that the number of platforms that support more advanced programming features (be it object orientation or closures or message passing or...) will only increase, not decrease. Of course no one wise will be calling virtual functions in inner loops, but they are perfectly fine to use for control flow, configurability, modularity, etc.
The following are not allowed for the core data in your code.
http://msdn.microsoft.com/en-us/library/hh388953.aspxOOP may live at the top level of granularity, but when it does for working with your data, OOP is not compatible. You can choose which module to run with polymorphism, but you data can't be be processed with virtual functions.