Wednesday, May 5, 2010

Powered By [enter name here]

I have been a long time advocate of home-brewing (code, not beer... unless you know what you're doing, thought I suppose the same could be said for both).  I refused, perhaps from a desire to learn, or perhaps sheer arrogance, to use packages which were not included in a programming languages core.  For me, to download a library, which someone else had written, and use it in my own code was closer to blasphemy than my sensibilities would let me tread.  In retrospect the distinction between those things distributed with a language via it's core and that which one would need to download seems paltry, though my adherence to a rejection of the later has led to some interesting thoughts on levels of knowledge.

Once, I heard it said, "You do not need to know how to build a car in order to drive a car."  Statistically this is sound simply based on the observable myriad of car-drivers in comparison to the relatively few auto-repair workers.  The statement may also be applied to domains outside the realm of automotive engineering.  For our purposes, we will apply it to programming.  My prior personal decision to set-aside external packages and, by inference, frameworks, forced me to learn how to build these packages and frameworks.  However, there was a limit to the depths to which I was willing to delve.  I did not, for instance, write my own programming language before using PHP.  Similarly I did not write an operating system before turning on my computer.  Essentially, the distinction between functionality provided by a languages core distribution and add-on functionality established the domain, or level, of knowledge I was endeavoring to internalize through work on my personal and academic projects. 

Often I've said (sometimes to others but usually to myself) that a serious Computer Scientist should not use a built package or framework without having make a comparable package themselves.  The statement is too broad however and does not accurately reflect the concept of knowledge levels.  It would be better stated in the context of a particular domain, such as "someone who is serious about learning how content management systems work should not heavily use a content management system without building their own."  Similarly, one could say "someone who is serious about understanding how a programming language works should write their own programming language."  Creating such a system may seem a waste of time in so much as the system will more than likely be tossed aside at a later point in favor of a more robust and mature system of the same genre.  The experience however is edifying.

One should explore ones purpose before setting forth on an endeavor of this ilk.  Are you attempting to truly understand how a system, or genre of systems, works, or are you attempting to setup something that functions as expected without any grandiose visions of future changes outside the bounds of what a particular framework provides?  If your purpose is the latter, home-brewing is admittedly overkill and, assuming a first attempt at brewing said genre of system, would result in an application of questionable stability.

This line of thinking was largely inspired by my explorations in JQuery, a Java Script library which I have given a wide berth until recently.  While elegant, understanding of the library, and usage thereof, is not trivial, barring a willingness to code on blind faith and the kindness of support forum members.  Statements like "functions are first class citizens," with which the JQuery documentation is rife, hold little weight to someone who has not coded a Javascript closure.