In my studies, I studied under several artists who made a large impact on me, both in terms of the work I did and the more abstract philosophy of art, which has as many different styles and themes as Perl, even. ;-)

On one particular occasion, my instructor showed me the difference between the additive techniques and philosophies of creating artwork, and the subtractive school of thought on the subject.

Think of a marble block. No one would argue that the block does not contain within it an infinite number of possible sculptures, and yet, some artists claim that they are guided by the block, to an almost predetermined form, as if the marble had captured and engulfed the sculpture the whole time, until the artist came along with a chisel and freed it from the stone.

This is the subtractive method; bits and pieces are worked away from the form until the underlying sculpture is revealed. The beauty of this method lies in the transformational process; taking something known and revealing a new side, that was always inherent within the object but had been somehow unseen.

On the other hand, the sculptor who works with clay, is using an inherently additive method to create new works. By adding more clay, the object can be extended and formed in new ways. If the structure is built with care, and formed by hands that are trained in the ways of the clay, entirely new sculptures and forms can result in patterns unique to the creator.

Now, before you decide that I have gone off the deep end, consider this. Within CPAN lie a great many sculptures; some are used by every programmer upon occasion, (i.e. CGI, DBD, etc) to create new works, and some are used very rarely, and only when it is absolutely necessary to do so. A great many programs that are written by competent Perl programmers may use a given module (additive technique), but only those features of that module that they deem necessary and/or useful will make it into their final code. (subtractive.)

Another way to look at this would be the example of how, during the first stages of writing an application, much time can be spent on the simple task of data modelling. When an application is in the earliest stages of being written, only a very few things may be known about the final model, and perhaps the coder wants to get started as soon as possible on the program logic and user interface portions of the code. The poor programmer, rushed for time, might choose to over-model the data on the side of too much information (very additively, I must say), knowing that they can go back later and just drop table a bit here, alter row there, and voila, the masterpiece is back in perfect balance and harmony.

In any case, I was just drinking a cup of coffee tonight, knowing that I was going to be up coding for a while, when these thoughts occurred to me, so I thought I would share them with the rest of the Monks. Maybe I am on to something, no? Or, maybe I am going off the deep end, maybe I have spring fever. Either way, it is sort of fun to try out a new metaphor once in a while.