Software Design for Flexibility Quotes

“A good program must be written many times. This is true of the programs we show. The first draft may not clearly separate out the concerns, but by making that draft the programmer learns the structure of the problem. We will show two different implementations, which will reveal the evolution of the program as we identify shortcomings in our draft.”
― Chris Hanson, Software Design for Flexibility: How to Avoid Programming Yourself into a Corner

“The most powerful kind of code constructs other code that has been bundled with just the right amount of curated data; such a bundle is not just a “function pointer” but a closure (in a functional language) or an object (in an object-oriented language).”
― Chris Hanson, Software Design for Flexibility: How to Avoid Programming Yourself into a Corner

“Regular expressions are widely used for string matching. Although regular-expression systems are derived from a perfectly good mathematical formalism, the particular choices made by implementers to expand the formalism into useful software systems are often disastrous: the quotation conventions adopted are highly irregular; the egregious misuse of parentheses, both for grouping and for backward reference, is a miracle to behold. In addition, attempts to increase the expressive power and address shortcomings of earlier designs have led to a proliferation of incompatible derivative languages.”
― Chris Hanson, Software Design for Flexibility: How to Avoid Programming Yourself into a Corner

“In software engineering this principle is enshrined as “Postel's law” in honor of Internet pioneer Jon Postel. In RFC760 [97], describing the Internet protocol, he wrote: “The implementation of a protocol must be robust. Each implementation must expect to interoperate with others created by different individuals. While the goal of this specification is to be explicit about the protocol, there is the possibility of differing interpretations. In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior.” This is usually summarized as “Be conservative in what you do, be liberal in what you accept from others.”
― Chris Hanson, Software Design for Flexibility: How to Avoid Programming Yourself into a Corner

“One should not have to modify a working program. One should be able to add to it to implement new functionality or to adjust old functions for new requirements. We call this additive programming.”
― Chris Hanson, Software Design for Flexibility: How to Avoid Programming Yourself into a Corner

“We have all spent too much time trying to deform an old piece of code so that it could be used in a way that we didn't realize would be needed when we wrote it.”
― Chris Hanson, Software Design for Flexibility: How to Avoid Programming Yourself into a Corner

“So the syntax of the regular-expression language is awful; there are various incompatible forms of the language; and the quotation conventions are baroquen [sic]. While regular expression languages are domain-specific languages, they are bad ones. Part of the value of examining regular expressions is to experience how bad things can be.”
― Chris Hanson, Software Design for Flexibility: How to Avoid Programming Yourself into a Corner