Our Pattern Language

I don't have that much experience with parallel programming, but I think this paper does a decent job of laying out one approach to codifying the process that will need to occur to help maximize this hardware architecture going forward. I like the discussion at the beginning of the paper where there was a discussion of the "ideal" layout of developers across the overall hierarchy of a given set of problem spaces and I would love to see a model like that actually in place and working. I know the company I'm currently working at seems to be putting more and more effort into going into something like this, but we keep running into real world issues where the various products are so used to their own specialized stack that they are untrusting of moving to this new unified service package. The other issue also seems to be that no-one is entirely sure whose job it is supposed to be to actually port products over to the system. In a new company, some startup, this would be an excellent plan to follow to make sure that effort is getting spent where it needs to be and work to move technology changes to the stack is simplified.

The biggest issue I have with this paper is the granularity of the patterns they present. It seems like they are almost arbitrarily grouping problem solutions into large patterns, and at the same time focusing in on smaller patterns at the same level. For instance, in the Architecture section they have an entry for MVC, which is indeed a way to approach designing the overall project flow, and another entry for Event Based invocation which seems to be a slightly more complex version of the Observer pattern. Either my inexperience is showing, or I'm not sure that one can justify placing those two patterns in the same grouping, as they seem to solve entirely different issues of organization and activation. And others like "Bulk Iterative" seem to be even more simplistic. With these drastic differences in approach all being captured by patterns at the same level I am more than prepared to state that this team needs to seriously examine their current dissection of the parallel programming architecture space and make sure that the patterns they have here are all full patterns and not simply a macro-equivalent of a "code trick" or "handy thing". With so much variance in scope I have a hard time understanding how they can consider this a unified design tool.

Although, any advantages in this area that will help more programs actually take advantage of multiprocessors is a welcome thing. With multicore processors becoming standard equipment I'm too used to seeing one of my cores getting much more heavily taxed than the other depending on where the programs I'm running got assigned by the OS. It makes much more sense to balance the load out as much as efficiently possible, but many developers simply do not have the training to do this effectively. And much like UI has been codified and recodified into more flexible and easier to understand and use libraries the ability to effectively use cores must extend in a similar way. I do not want to end up needing one core for every new program I need to run, especially since today's exploding hardware capabilities are making lazier and lazier developers and thus bigger and more bloated software.