Featuritis not always bad (was re: GOTO considered necessary)

[Karel Th�nissen <thoenissen@hello.nl>]

Robert Dewar wrote:

> Right, I often state a rule that says that adding ANY feature AT ALL to
> a language damages the language by increasing size and complexity.

Yes, but leaving it out may lead to increased size and complexity of
programs written in the language. If the feature is difficult to get
right, maybe it is an even better idea to have it incorporated in the
language and not in the programs. Then tens of thousands of programmers
can all save hours of trying to make it themselves in their numerous
programs (Ada-case) or millions of programmers can all save weeks trying
to make it themselves (C/C++-case 8-) in their numerous programs.

In general, I object to the use of the term complexity as a measurment
in language design. Complexity of the compiler? complexity of the
tutorial? complexity of the programs written in it, complexity of the
design, complexity of the design and programming proces, complexity of
verification, validation and testing? Usually one comes at the expense
of the other.

The most serious effect is often the consumption of precious name space
by reserved words.

> The trick is to ensure that the positive contributions of the new 
> feature outweigh this damage.

As for many things in life 8-)

> I think this is an important language design principle. Otherwise you
> end up saying "oh sure, stick this in, people do not have to use it
> if they do not want it."

Which is no problem if the feature:
1) is well designed and well behaved, so no tail biting
2) comes as a independant feature, so that people can work with the rest
of the language without ever knowing that the feature existed. This
ensures that people can write in the language safely if they have not
finished the full language course: avoid steep learning curve and memory
load.
3) comes as a clearly recognisable syntactic entity in the language. So
if one reads the code and is not familiar with the feature one at least
knows that there is a cognitive problem, and knows where to look in the
reference manual (and find there many useful informations on the feature
that would find no place if the feature was to be simulated with lower
level constructs)

This is one of the great benefits of design patterns: they allow us an
understanding of the system at a higher level of understanding and
provide an easier to grasp repetoir of solutions and a vocabulary.

I leave it as an exercise to the reader to determine whether the FSM is
such a feature.

Groeten, Karel