Michael rails on the term "easy" - and seems to argue that "easy" has no place in our dialog.
I once took a class on compiler dependence analysis from Michael, based on his excellent PhD work, published as "Optimizing Supercompilers for Supercomputers" in 1982. I need to go read over my class notes... but I'm pretty sure Michael told me he had some easy methods for loop dependence analysis, loop interchange, and distance computations... the phrase "you can easily see" still rings in my ears... so that easy term might be relative.
I believe what should be "hard" about programming is the algorithms and approaches for parallelism ("Think Parallel") not the method to write down the program.
Having an easy method to write express or debug a parallel program, can be quite different than making programming itself easy.
I'd just like tools to make my job as easy as they can. Good programming is not easy and parallel programming isn't going to be easier than regular programming.
Michael does conclude, what at times what seems to be a down beat article, with "I have confidence in the applications programmer's ability to develop algorithms and approaches to using parallelism."
No one says that is going to be easy if we haven't made programming easy for all.
5 Top Federal Initiatives For 2015As InformationWeek Government readers were busy firming up their fiscal year 2015 budgets, we asked them to rate more than 30 IT initiatives in terms of importance and current leadership focus. No surprise, among more than 30 options, security is No. 1. After that, things get less predictable.