It occurred to me that a design is really just a cheap prototype. In a sense, you write or draw a design to prove to yourself that the idea is viable. The more detailed the design, the more proof you've given yourself. Later on you solidify the design in terms of code or whatever. Some systems like you to go so far as to write down function and class names on paper before you start implementing. So what you essentially have there is a prototype, which just happens to be on paper rather than on disk. And instead of physically executing your prototype, you mentally execute your design, seeing how things link together, making mental notes of what is missing and what needs to be amended. The point here is that big up-front design on paper and rapid prototype development are perhaps not really separate paradigms but more 2 ways of implementing the iterative development model where you work gradually from a rough initial prototype to a finished product.
Similarly, the arguments between compiled and interpreted languages, or static and dynamic typing, and so on, can be seen to be almost irrelevant if you stop thinking of a compiler as an essential tool in the compiled language development process, but rather as a combined testing and optimisation tool that merely tests type constraints to reduce errors and optimises code to make it run faster.
Maybe we could eliminate the religious arguments if we could think about all these things as shades of grey rather than black and white all the time. I think I might investigate these things further for my Masters project.
