We'll see a lot more co-design of hardware and software. So far, outside of major trends (e.g. multi-core CPUs, GPUs), authors of different abstraction layers (

We'll see a lot more co-design of hardware and software. So far, outside of major trends (e.g. multi-core CPUs, GPUs), authors of different abstraction layers (programming languages, compilers, OSes, etc.) have worked towards improvements independent of other areas. I suspect that much of the improvement over the next 50 years will come clever tricks that require collaboration across more than one area. Consider a simple example: CPUs have had caches basically forever. Caches are the epitome of independent development, because they require modest performance improvement with no effort. (Advanced users and compilers can of course put in more effort to get more improvement, but the maximum improvement is limited because CPU vendors have been reticent to allowing direct user control over the cache.) What if these caches were instead scratch pads? Frankly, this sounds like painful way to program, especially in traditional languages, because now everything will have to be explicitly moved into the scratch pad. Maybe high-performance users will benefit, but the vast majority will not. But we can reinvent the language as well. Let's propose a different programming model: tasks (blobs of code) with explicit data usage declarations. The rule is that a task only runs when its data is available. Thus the processor can copy data into the scratchpad asynchronously, and only run the task when all the data is there. Suddenly, there are no more cache misses! We just had to give ourselves permission to modify the programming model too. Well, actually this is not a hypothetical programming model. I've described Legion, a programming system from Stanford [1]. A software-only implementation of Legion was able to scale to 1000s of nodes on a distributed system [2], so we know the basic approach works. Even better, the Legion folks described a type system which allows you to hide the gory details behind an easy-to-use apparently-sequential programming language [3, 4]. So far, these results have focused on software only. What would it look like if we were able to change the hardware as well? To answer your original question: I think this will require more expertise (and more diverse expertise) on the part of the system designers, but if we do it right, we can still design a system which is easy for everyone else to use. That's where I think the biggest wins will be in the next 50 years. (Disclaimer: I work on Regent, the Legion programming language) [1]: http://legion.stanford.edu/ http://legion.stanford.edu/ [2]: http://legion.stanford.edu/pdfs/legion-fields.pdf http://legion.stanford.edu/pdfs/legion-fields.pdf [3]: http://legion.stanford.edu/pdfs/oopsla2013.pdf http://legion.stanford.edu/pdfs/oopsla2013.pdf [4]: http://legion.stanford.edu/pdfs/regent2015.pdf http://legion.stanford.edu/pdfs/regent2015.pdf