From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Handling of operator . pro
Organization: Computer Science, University of Melbourne, Australia
Date: Wed, 12 Aug 1992 13:32:47 GMT

vadim@cix.compulink.co.uk (Vadim Lebedev) writes:

> fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
> writes:
>
>> >Well, 20 years is a little exagerated, but i'm sure that the time needed
>> >to learn to use some feature of the language is MUUUUUUUUCH shorter than
>> >the time needed to design and implement it's simulation it when the feature
>> >is missing from the language (ERRTI for exemple).
>> 
>> *Someone* has to implement these features - the choice is between
>> whether this is done by the language implementor or the programmer.
>> All of the features you mention are not trivial to implement.
>
>Exactly!!! That IS the reason i want them to be implemented ONCE by the
>language implementor, and not MULTIPLE times by compiler users.

There is more than ONE language implementor...
OK, there are more programmers than compiler writers :-)

However, typically it is easier (requires less work) for the programmer
to use a work-around and code what they want using existing language
features than to modify the compiler to add a new feature to the
language. There *is* a cross-over point at which modifying a compiler
once is easier than using a work-around say 30 times, but there are
other disadvantages with shifting the work onto the compiler-writer.

Compilers become more expensive, which discourages beginners, so the
language becomes less popular. (This in turn leads to less resources
being spent on compilers and tools for the language). Compilation
becomes slower. Compilers occupy more disk space and take longer to
install.  Also compilers become more error-prone; it is a lot easier to
fix a bug in your work-around than to fix a bug in the compiler.

>> Also a good programmer MUST master the language they are using, for two
>> reasons: firstly so as to enable them to write *good* programs, and
>> secondly so that they can maintain other peoples programs.
> 
>Ok, suppose we have a C++ program which NEED some feature (by NEED
>I mean that the program design is greatly simplified by availability
>of this feature) that is missing
>from the language (RTTI for exemple). The program designer have 2 choices
>1) Design and implement some approximation of RTTI
>2) Use an existing library which already implement RTTI in some way 
>
>The eventual maintainer will have to wonder: 
> "How the guy did this RTTI stuff?"
>
>Now, if we had the feature IN the language, the situation becomes much
>simpler, the program designer does not have to evaluate different choices
>it simply can use the feature, and the maintainer simply have to know
>the language, to understand how the thing works.

If the language becomes too complex, then "simply knowing the language"
becomes a non-simple task. On the other hand if some feature has been
coded using the facilities of a simple language, the maintainer can
SEE how it works, by reading the code.

The ideal is to have a language that is simple but powerful and extensible.
This is the idea behind using standard library i/o functions rather than
special builtins, overloading rathern than printf %-specifiers, etc.

>> To quote my Programming Languages textbook [Watt],
>>         "Simplicity should always be a goal of language design."
>
>The question is: "What simplicity?"  Learning simplicity, or usage simplicity?
>Don't you agree with me that in the above exemple the language with RTTI 
>built-in is simpler to use than the language without it?
>Actually the learing simplicity and usage simplicty are often two 
>contradicting requirements. To satisfy both of them a programming language 
>should be designed in such a way that you could
>learn and use it gradually in subsets. In this case the base subset is still
>simple to learn, and you learn about advanced features only when you need
>to use them.

Often it is not clear whether you should use a feature until after you
have learnt it, so this is difficult.

Also you have to learn the advanced feature every time you are maintaining
code that used it, even if that code could have been written using only
simpler features.

>> If you think otherwise, then have a look at PL/1 as an example of a language
>> gone wrong (because of rampant "featurism").
>
>I really LOVE PL/1. Especially when i was using IBM OPTIMIZING PL/1 
>compiler and IBM CHECKOUT PL/1 compilers (which is actually an interactive 
>interpereter) which had an excellent macro pre-processor.
>I learned and used all and every feature of this language. 
>I don't think that this language is 'gone wrong'.

I shouldn't have said PL/1 (I have never learnt that language, I was just
repeating what I have heard and read). Instead I should have said C++ :-)

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature VIRUS is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.lang.c++