(j3.2006) Optional parts of programming languages

[William B. Clodius]

I am surprised that several people are suggesting that a programming 
language should contain significant optional parts. While it can appear 
to make the implementors job easier, he need only implement the parts 
he thinks his users want, its affect on the standardization process and 
the user community are both too negative. It is too tempting for the 
standards process to think that optional parts of the language can get 
by with less consideration than the required parts of the language, too 
easy for a minority that wants a feature to try to get in the language 
as an option, rather than a requirement, too easy to develop options 
independent from one another and result in features whose combination 
is not understood. From a users point of view optional features are 
intrinsically less available individually, their combinations are even 
less available (note that for N independent options the number of 
potential combinations goes as N**2), and reduced availability results 
in reduced use which in turn results in less robust implementations.

As an example it is my understanding (I think from Computer Standards 
and Interfaces Vol 16 Nos 5/6, September 1994 a special issue devoted 
to programming language standards) that the COBOL 1974 standard 
originally specified a large number of optional parts (sections), and 
the effect on portability was limited because the US government (Bureau 
of Management and Budget?) set  requirements on which combinations must 
be supported on its systems.

-- 
William Clodius