revised on Thursday, February 25, 2010
I spend a lot of time revising material I've written. Eventually, I decide it can no longer be improved and call it done. The tiny-c Programming Group on Facebook reveals many examples of this passion to perfect. This short note will give several examples of typical changes I find myself making during the life cycle of a program, webpage or document.
Some changes are driven by external events. As donations continued to come into a fundraising effort I initiated, I changed graph.tc to get its data from a file instead of hardcoding it in the program itself. This allowed me to call the program itself complete.
Other changes are motivated by seeing what someone else has done. The builtin JavaScript function split used by Amrit in his Foxtrot encoder / decoder was adapted 1 and used in foxtrot.tc (and later in graph.tc). This function was improved by Roger to return a value it "knew" when it was done. An instruction that computed this value was now no longer needed.
"Cosmetic" changes (reformatting, clarifying comments, etc.) often take place near the end of my revisions. I tend to "hook things up" at this stage as well by taking screenshots, adding entries to the project index, posting news, etc.
Sunday, February 14, 2010
1 Bradley's First and Third Law apply. It is not surprising that a paper titled "Revising" itself gets revised. My split predated my discovery that Amrit's program used JavaScript's counterpart! I got the idea of writing split when I saw it used in Ken's foxtrot.pl. Only after writing split and using it did I see that Amrit used JavaScript's split.