Paul.
http://theprogrammersparadox.blogspot.com

Copy-and-paste is a form of duplication, and can therefore certainly help ease the pain of code duplication. However, it cannot ease the pain of “code triplication”. Many domain-specific languages seem to have code triplication problems. For instance, if the domain-specific language does not have an implicit reference counting mechanism, then the language must have an explicit mechanism — in fact, a heuristic — for knowing the reference count is zero and the resource has fallen out of use/scope. Now, I know the objection: “Z-Bo, you’re silly, DSLs that don’t garbage collect?!” They exist and are widely deployed. Redhat Package Manager (rpm) is a good example! rpm SPEC files are DSLs that provide rpm with it’s intelligence. rpm has a “feature” where you specify a “%dir” directive to note what directories are owned by a package. When the package is un-installed, the directory can be removed IF it’s empty. This parameter is really just a work-around for not having some garbage collection mechanism. What’s more, package management is also really just an informal system. It’s an NP-complete problem that is managed through the use of heuristics.

My point is that even in programs that handle NP-complete problems you can have mysticism aside from the basic heuristics that pare the problem space.

Brian Foote touches on another form of duplication in his OOPSLA 2005 Breakthrough Ideas answer: temporal duplication. Saltzer et al’s paper on End-to-end Arguments in System Design addresses exactly that phrase.

The biggest obstacle I see for Programming as Experimental Philosophy (nice metaphor) is that it requires a complete change in the way academics think. Academics always strike me as too reactionary. Even in a field like Computer Science where things seem remarkably fast-paced, most advances are in response to trends. That’s probably why people often cringe at the statements I make, like telling people they should disregard the notion of abstraction as “central” to Computer Science and regard abstraction as a malaise – I always try to improve a sentence about abstraction by seeing how I can remove the word from the sentence. It’s not that I’m more right or more wrong than anyone else. It’s because I don’t see the value in waiting to react to what other people are doing.

But, one thing that I think you miss is that programs and programming *can* be formal in the middle. Although that is a compromise, it is still usefull. E.g., if you accept an instantiation of some evolving, fuzzy requirements and an imperfect, changing data model then you can apply some useful formalisms to it (e.g., type checking, regression testing).

Actually, reading your post again, I think you may disagree with this statement. “I believe that it is actually worse – software design is not just subjective – it is chaotic.” Well, maybe…but type checking and regression testing seem to *work*.

The challenge with programming is to determine which formalisms work, which don’t (and have the courage to throw them out), and then find new (potentially non-formal) techniques to fill the gap. All the while we have to realize that some applications (e.g, device drivers) lend themselves better to formal verification than others (UI design).

[Andrew - I quite agree that formal methods are important and useful, at the right time and place. What I am against is totalitarian formality. - Jonathan]