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

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

Robert Dewar wrote:
> 
> <<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 *precisely what I disagree with. The trouble is that you don't
> know you don't need to know something until you know it,

The tutorial might tell you. Why not tell the language users what parts
of the language can be safely skipped until later. Also tell them for
what kind of problems these parts of the language are appropriate.

> and then it's too late!

Yes, then it is too late, but then what? Maybe a frustrating experience
that you could have coded the problem more easily or more safely, but
the programs you had written up to then, work exaclty as expected with
the more limited understanding of the code that you had.

Let me give two examples: Ada's exception and tasking mechanisms. These
satisfy the three criteria I gave more or less.

Regarding my first criterion, they are well designed, there are no nasty
quirks that do not stem from the very nature of exception handling and
tasking (unlike exception handling in PL/I which had a rotten design).

Regarding my second criterion, anyone not having read the part of the
manual on exceptions can use the rest of the Ada-language without
problem. Okay you miss the comfort of the mechanism, but what rests is a
language with the power of say Pascal. Anyone coming from Pascal would
not notice any important semantic difference between Pascal and an Ada
without exceptions, because errors in the programs crash the system, as
exspected. Same for tasking, if you do not use it, you never have to
worry about it. The model of an Ada without exceptions and tasking is
the same as that of an Ada with these facilities available but left
unused. So one can use Ada safely without exceptions and tasks in the
sense that the program operates as expected.

Regarding my third criterion, anyone not completly familiar with Ada
(say with a level of knowledge of Ada that covers the features provided
by Pascal) would instantly spot the presence of a task definition,
because there is nothing like it in the language model that s/he had
seen until then. S/he can see there is something special because of the
unfamiliar reserved (bold or capitalized) word 'TASK'. The best place to
fill up insufficient knowledge is in the manual under 'TASK'. Compare
that with a language where tasking is 'emulated' with platform dependant
procedure calls and where the intricacies of the tasking are burried in
procedure calls that look like normal procedure calls, but that have
lots of special semantics. The risks of misreading are severe, even it
uses concepts that he was supposed to understand. The manual cannot
provide much help, because the tasking is handled in a platform
dependant way that is outside the scope of the language. Moreover, there
is not a keyword to search for in the index.

Exceptions however, do not comply with this third requirement. They are
declared as any other object. Nothing to warn you there. Then there is
the 'raise', which looks (if not in bold) like an ordinary procedure
invocation....

To the list I should have added a fourth clause that the user should not
be allowed to accidently run into the feature. Sufficient syntactic
difference between the 'optional' feature and the rest of the language
can guarantee that. With tasking the risk is negligible, there just is
no language feature that, because of some reasonable error on the
programmer's side, could accidently form a task definition. With
exceptions the risk is bigger, but permissible. The programmer might
accidently try to define a type called 'exception' or a procedure called
'raise', but the compiler should catch that, as it is forbidden to
redefine these identifiers. Leaves the risk that the user planned to
define either a type called 'exception' or a procedure called 'raise',
and uses it, but has forgotten to give his/her own definitions. Still
then, more things must go wrong, to have the compiler swallow this as an
correct invocation of the Ada exception mechanism: both the type called
'exception' and the procedure called 'raise' should be planned, their
definitions forgotten, and used with an exception object as the argument
of the procedure 'raise'. The compiler will still catch it because of
the forbidden parentheses with the raise, but it leaves the programmer
confused as compiler error messages or not clear.

Having said this, I do not want to imply that FSM's are a candidate for
incorporation.

> Yes, of coruse it is the case that adding features to a language, and
> thus increasing the complexity of the language may easily be counterbalanced
> by the resulting simplification in programs. That's exactly the tradeoff
> that needs to be considered.

I know that this was a consideration in the design of Ada, whereas often
more academic languages look for compiler, language or definition report
simplicity.

Groeten, Karel