On Meta-coding
[NB: This article is in primarily an internal discussion, and is in serious need of editing.]
Meta-coding may well be defined elsewhere as something other than that which is here described.
For the sake of working premise, consider the following as definition:
Meta-coding is a structured re-working of already-functional (and likely already compiled) programs, pieces of programs, data, and possibly other meta-code.
Meta-coding describes something that, assuming he accepts the general concept and its definition provided here, the reader may still find room to argue the degree implicit in said definition. Coding can take place at remarkably low levels. One traditionally thinks of coding at its lowest level being a variant of assembly for a given architecture, but even this is higher level than is possible; much that can be deemed coding can be and, on occasion, must be done at the hardware level. The high end of what may still be deemed 'coding' is the area in which disagreement is to be anticipated. Is java still coding? An overwhelming majority would say yes. How about python or ruby? Still, mostly 'aye's. What about shell scripting? (Here some naysayers are beginning to be heard.) How about managing the filesystem layout of rpm's, deb's, or ebuild's? Now we here some definite 'no's, and some plainly confused, "What's he talking about?"'s Obviously at some level of abstraction, managing 'code' or perhaps simply managing files that contain code is not going to be considered coding, proper.
So what is the cutoff point? ... Actually, it's immaterial and insignificant. The point of the present article stands regardless of the reader's view on this essentially trivial matter of scale. The topic at hand is actually
"How important is meta-coding?"
Let's slip into a comfortable first person tone for a while -- that is, if the reader doesn't mind. I've often considered code written at a lower level to be inherently superior to code written at a higher level. This (notedly snobbish) view has stood regardless of the scale or perspective on the hypothetical project in question. Formal scripting languages with libraries are 'better' than shell script; C is better than Python; assembly better than C and so forth. There may be argument regarding the relative ranking of languages of similar degree of abstraction, but the general premise has held firm for me. Now, this is interesting as a personal reflection, as I personally engage in remarkably little that any reader might consider low-level coding. I've probably written fewer than 1000 lines of C in my lifetime; I've written a "Hello World" in assembly and nothing more; and I've probably spent more time writing bash than I've spent collectively learning, writing or thinking about any other language. I believe it is this very familiarity with scripting that has engendered in me such contempt for higher-level, more abstract code, and the higher level languages themselves.
I read an author once who noted that while he has greater respect for the low level languages, he spends his days employed writing Delphi. He compared the act of writing Delphi to that of connecting black boxes with wires and attempting to personally fabricate as few black boxes as possible. He described this process with a measure of derision, but seemed to be of the stance that it was a necessary evil. Well, I've taken quite a similar position, personally, in the past, and have reason to believe that I am in error. It is my position at present that 'real coding,' 'mere scripting,' and meta-coding each have their place, and truly should be recognized individually as necessary and functionally independant. The manufacturer of a modern automobile wheel depends upon the maufacturer of lug nuts to have researched the materials he uses and their torsional strength. Similarly, the automobile assembler sees that wheel as a functional unit which he needn't consider on any further divided level. Similarly, when the task at hand and the manpower available call for a higher level language, the percieved loss in performance is offset by the reduced development time, and the increased plausibility of completing the project. This is a realm in which we as digital architects -- on any level -- are certainly standing on the shoulders of giants who have come before us. This is not to indicate that the low level work is complete. There will always be a need for low-level code and for those who excel at writing and refining that code, but the view that anything written at a more abstract level is wasting the resources of the machine on which it is run is not only elitest and pig-headed, but also visionless and limiting.
I do my best work at very high levels. I find it engaging to be productive among the black boxes rather than among their contents. I know many who are more productive than I'll ever be at several different lower levels. I admire their work, and am greatful to all those who have created and maintained projects at that level -- projects that I use, and to which, when possible I contribute. I will however, no longer look to meta-coding with a derisive snearing eye. I will look with an assessing eye, and determine at what level a given project will be best handled, most productive, most secure, most rapidly available, most stable ... or in determining the 'right' medium in which to begin or advance a task, I will assess which combination of the above is in fact the most appropriate set of ideals for the project.