A Pattern Language for Productivity!?
Apr. 18th, 2008 11:26 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
elfsI'm all about process. I love to read about Getting Things Done and all the nifty different ways that one can apply GTD principles to just about all aspects of your life.
For a while, I was enamored of pattern languages. A pattern language is a set of common problems within a larger problem space, on varying degrees of scale, that describe a problem clearly and the best known solutions to that problem. In computer programming, design patterns give developers a common vocabulary for describing what they do; for example, there are several different kinds of windows one might use (application window, popup dialog, warning, media window) and a factory provides a unified tool for building any of these without the developer having to know the particularities of each kind; on the other hand, if you have a kind of window and it needs more functionality but you don't have the source code, you would use a decorator to wrap the window object and attach new behaviors to it. By giving these practices names, developers have a way of talking one to another without having to clarify terms first.
I've since come to understand that patterns represent shortcomings in a language and the correct solution is not to use the pattern, but to create a method within the language that makes the pattern obsolete. (You can do this with dynamic languages like Ruby and Python.) The classic example is "save frame state," which is a pattern seen often in the 1960s. C did away with "push frame state and goto" entirely by creating function definitions, which did all the frame state management and assembly-level jumping for you in an intuitive manner.
So I groaned when I saw A Pattern Language For Productivity, which turns out to be actually fairly useful. He's tried to hew closer to the Alexandrian model (used in architecture) of patterns than the so-called Gang of Four model (used in programming). The Alexandrian model is better because, unlike programming languages, we don't have a dynamic grip on the real world; we can't make time move faster, or change the meaning of items like pencils and paper. There's nothing wrong with the real world; it's just a brute fact.
And we have to live in it. If your life is a clutter-bound nightmare, take a look. There's nothing new here, but at least it's organized with "when to use" recommendations.
For a while, I was enamored of pattern languages. A pattern language is a set of common problems within a larger problem space, on varying degrees of scale, that describe a problem clearly and the best known solutions to that problem. In computer programming, design patterns give developers a common vocabulary for describing what they do; for example, there are several different kinds of windows one might use (application window, popup dialog, warning, media window) and a factory provides a unified tool for building any of these without the developer having to know the particularities of each kind; on the other hand, if you have a kind of window and it needs more functionality but you don't have the source code, you would use a decorator to wrap the window object and attach new behaviors to it. By giving these practices names, developers have a way of talking one to another without having to clarify terms first.
I've since come to understand that patterns represent shortcomings in a language and the correct solution is not to use the pattern, but to create a method within the language that makes the pattern obsolete. (You can do this with dynamic languages like Ruby and Python.) The classic example is "save frame state," which is a pattern seen often in the 1960s. C did away with "push frame state and goto" entirely by creating function definitions, which did all the frame state management and assembly-level jumping for you in an intuitive manner.
So I groaned when I saw A Pattern Language For Productivity, which turns out to be actually fairly useful. He's tried to hew closer to the Alexandrian model (used in architecture) of patterns than the so-called Gang of Four model (used in programming). The Alexandrian model is better because, unlike programming languages, we don't have a dynamic grip on the real world; we can't make time move faster, or change the meaning of items like pencils and paper. There's nothing wrong with the real world; it's just a brute fact.
And we have to live in it. If your life is a clutter-bound nightmare, take a look. There's nothing new here, but at least it's organized with "when to use" recommendations.
