I’ve long been an advocate of outside-in API design. This reflects my interest in user-interface principles in API design. When designing a GUI it is customary to mock it up on paper and then with prototyping tools before implementing the internal code. This helps the interface reflect the user’s goals and expectations rather than the internal data structures of the program. In API design, this means the class becomes more easily usable by decoupled client code.
It occurs to me that the same principles apply in language design. In particular we should try writing some code with proposed new features before we implement the features. This has several advantages:
- Ensures we get what we need, rather than what the proposal supports
- Helps us understand exactly what is being proposed
- Shows the strengths and weaknesses of each proposal
- Avoids unnecessary features that don’t support a real use case
Consequently herewith are some challenges for the proposers of the various closure proposals. I’ve tried to make them as simple as possible so that the closure issues will be focused on.
(more…)