Wednesday, December 24, 2008

Declarative Software Design

I'm thinking that software architecture should be entirely described in a declarative fashion... well, almost. The most basic element of work in a software project probably has a built in necessity that it be described in an imperative way. The processor speaks imperative, after all. These units should be sufficiently small that they can be easily and completely described in, say, a sentence. Much imperative code has complexities which require substantial study in order to be able to say, "ok, I understand the 'why' of what's going on here". Understanding the why is the most difficult part of reading someone else's code. So, I'm suggesting that the method name, or the preceding comment be able to completely describe the why for the method. This way, you don't have to read the code. if it's behaving poorly, you trash it, and write an implementation which accomplishes the stated why. If the stated why is not working in the program, then you have an architectural problem. This problem exists at a much higher level and should be able to be described declaratively and modeled that way.

No comments: