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.
IT's Reputation: What the Data SaysInformationWeek's IT Perception Survey seeks to quantify how IT thinks it's doing versus how the business really views IT's performance in delivering services - and, more important, powering innovation. Our results suggest IT leaders should worry less about whether they're getting enough resources and more about the relationships they have with business unit peers.
What The Business Really Thinks Of IT: 3 Hard TruthsThey say perception is reality. If so, many in-house IT departments have reason to worry. InformationWeek's IT Perception Survey seeks to quantify how IT thinks it's doing versus how the business views IT's performance in delivering services - and, more important, powering innovation. The news isn't great.