The Philosophy behind Design Philosophies
Had afternoon tea with two old friends yesterday. One of them is doing math at UW and I visited him last November in Seattle. The talk was around topics like “the philosophy behind design philosophies”–or in plain words, “why and how you come to design it that way?” Modularization and abstraction is what pro developers do every day, but how–and why–you modularize or abstract a module/class this or that way, that’s not a natural thing. That’s first something to be learned, and later–as one learns (if one’s willing to) more than one strategy to do it, the questions come to choosing the right pathway.
That’s not just scholastic muttering. When you design a language or a framework (be it a programming framework, legal framework, business framework–an institution that is), this meta-philosophy applies. Because you are designing something that allows generation for other things–or to put it the other way, you’re about to design something that is going to be able to accommodate design philosophies. You design C++ to accommodate design patterns and different paradigms (procedural, modular, object-oriented, generic, etc.). You design commerce laws to accommodate different walks of business entities.
So one can’t be too careful nor audacious in coming up with one philosophy behind design philosophies. It’s hard as abstract thinking always is.
lukhnos :: Aug.24.2007 :: tekhnologia :: 1 Comment »
One Response to “The Philosophy behind Design Philosophies”
modularize