We read three brief papers, two on patterns we have covered earlier and one on a new "pattern".
The first was a review of the pipes and filters pattern, wherein a system is engineered to allow reusable modules to tackle sequential inputs. The idea in this paper of likening this process to the way a graph flows is an interesting idea and could help with the constructing of shared modules as common breaking points can be identified. The very brief mentions of how to parallelize programs using this pattern if welcome, but for a wiki it is awfully short on links to the appropriate pattern details. Considering how brief this whole section is it should not have been difficult to build a similar page for the mentioned patterns or link to their main wiki counterparts. More care could have been taken to discuss how to identify and construct the modules and their interfaces, including leveraging existing technologies like XML for these specifications. Overall this was a decent introduction to the pattern, but like the next two entries lacked the meat really needed to make this anything other than a guidepost.
The Layered Pattern follows much the same format, being a decent guidepost but lacking the detail necessary to use this as a guide for constructing programs according to this pattern. It keeps talking about making sure to get to the "minimum" number of layers with absolutely no direction other than you may want a layer to talk to hardware. I was convinced until I reached the example that you can just as easily have called this paper "Model View Controller" and changed nothing. Since this pattern is impossible to apply correctly without rigorous effort identifying the correct splitting points between layers I'm surprised there was no actual discussion on how one would accomplish this. Other than some vague references to TCPIP and a poorly described robot-controlling piece of software there was little actual content to this. A disappointment, even for the length of this paper.
The Iterative Refinement pattern is an interesting case. It seems from the discussion that it is applying parallelization to the standard recursive model of problem solving. This reminds me very much of what was discussed in the ReLooper paper where it was talking about building array loop parallelizers, only instead of iteratively going over specially designed datatypes we are applying the same thought to independent, recursive problems. It seems to me that making these calls parallel is not where the difficulty in this pattern lies. Indeed, the ForkJoin Framework paper even discussed applying itself to problems like this one. The focus of a paper like this should be on guiding an engineer through identifying when this can be applied and possible steps to take to modify current solutions to apply to this approach.
Wednesday, October 14, 2009
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment