More thoughts on goals
I remember from SICP they recommended a top-down approach to design. In the initial phase they recommended you engage in "wishful thinking." In other words, you haven't written the details yet of how you're going to accomplish what you want. You're just writing, "This is what I want accomplished." This also brings to mind "goals" for me. After you've done that, they recommended looking at:
- What are the primitives?
- What are the means of combination?
- What are the means of abstraction?
I think from this they said you could determine primitives, which are the base level actions that everything else will depend on.
The thing is, it's difficult to imagine doing this within the existing software development culture, which values constructing things out of pre-existing frameworks, which have already made a lot of these decisions for you.
Getting back to what Alan Kay said about architecture (at the bottom of my comment to which you responded), the main point I meant to get across was he said it's possible to separate "meaning" from "optimization." I liked this idea, because it would contribute to two goals you talked about: clear code, and optimization for speed, because if you separate "meaning" from optimization, that means you can be clear in your meaning (your goals), while maintaining some benefits of speed that you want. I think what he was getting at, though, is that the underlying architecture--the runtime--has to support this in order for both goals to be achieved simultaneously. That's the rub for a lot of developers, because sometimes this works out, and other times it doesn't. And there's the issue that one single architecture may not be able to do this for you at all times in a project. It seems he's been dealing with this issue, from what I've seen of his recent work, because he and other people he's worked with have talked about compilers which can be altered in the midst of the application code the programmer is writing! Quite a concept!
