the Hopwood design process (was: Abstract patterns)

[Matthias Lang]

David Hopwood writes:

 > This seems like an odd way of deciding whether and how to implement a
 > language feature. The preferred process IMHO is something like:

Your process specifically leaves out anything along the lines of
"decide that the feature is more trouble than it's worth, give up".

Using your design process, you end up documenting, implenting and
optimising ("in that order") every idea, be it brilliant or
harebrained, which drops into your inbox.

Matthias

 > 1. Design the feature, paying attention (among other criteria) to whether
 >    it *would* be feasible to implement efficiently given a bit of effort.
 > 2. Document the feature.
 > 3. Implement the feature naively.
 > 4. Gain experience with how people are using the feature, and a body of
 >    code on which optimizations can be tested.
 > 5. Optimize the implementation.
 > 
 > in that order.