the Hopwood design process

[David Hopwood]

Matthias Lang wrote:
> 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".

I deliberately didn't say anything about the criteria on which features should
be included (because that would require a book, not a short post).

In practice, once it has been decided to implement a feature, it will stay in
the language forever, even if it is never optimized. Instances of features being
*removed* from a programming language in the course of its incremental development
are vanishingly rare. Partly this is because of backward compatibility, but
mainly it is because the cost of retaining a feature is rather low.

The mechanism by which features fall out of general use is by designing new
languages, that don't have the features that were considered "more trouble
than [they're] worth". But it is only possible with hindsight to assess
which features those are. All language design is an ongoing experiment, and
it should be expected that each language will have some features that are more
useful than others.

Actually, I'm in favour of placing the bar very high on introduction of new
features. But it is possible to be too conservative. A situation where no
new features are added can be almost fatal to a language's popularity: a
large proportion of a language's potential user community will consider it
to be dead if it isn't being actively revised. This is a rational response
to the fact that most programming languages have insufficient resources
supporting their development.

> 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.

Now you're just attacking a straw man. It is obvious that each of the steps
will only happen if there are people motivated to do them. (Conversely, at
least in the case of a language with an open spec and open-source implementation(s),
each step *will* happen if someone decides to do it.)

Most ideas will never be developed to the stage where they could be implemented,
because no-one is sufficiently motivated to do the work needed for steps 1 and 2.
If you look at the effort Joe has put into the design of abstract patterns, it
is clear that at least step 1 has been completed, to a high standard IMHO, in
that case.

>  > 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.

-- 
David Hopwood <david.nospam.hopwood@REDACTED>