🚀 go-pugleaf

Since this is a reply to a reply, comments by sommar@enea.UUCP (Erland
Sommarskog) will be prefixed by `ES>'.  My comments (Douglas M. Pase
(pase@ogcvax.UUCP)) will be prefixed with `DP>'.

ES> To appreciate a modern langauge you must be a modern programmer.
ES> Some of the arguments Mr. Pase presents, and of which we have
ES> and will see many times, seems just as conservative as those
ES> that must have been around when assembler vs. Fortran was the issue.

I quite agree that I am conservative, as long as "conservative" is not being
used to mean "unwilling to accept change -- even when change is merrited."
I am neither in favor of change nor against it.  I am in favor of flexible
languages and programmers understanding what they are doing.  It seems,
however, the intent of the previous paragraph was to claim my arguments
were reducible to an aversion to change.  This is simply not the case.

A far better summary of my opinions, I think, would be "The right tool for
the job."  I don't use C for combinatorial searches, and I don't use Prolog
for system work.  I don't use Modula-2 for anything.  (I once wrote a 15,000
line compiler in Modula-2, and later maintained a 12,000 line library.  The
same thing in C would have taken 1/3 the memory, 1/10 the time to write, and
run about 2x faster.)

ES> [...] a good language should save you many mistakes as early as possible.

DP> This is a noble goal.  A major problem with this is the definition of what
DP> constitutes a 'mistake'.  [followed by an example...]

ES> [a response to the example, not the statement]  As for
ES> reading, I think the explicit type conversions help understanding what's
ES> happening.

This doesn't answer the question.  Is it just a matter of type casts?  What
other expressions are considered `mistakes'?  When are explicit type
conversions required?  Whenever the types do not match exactly?  Consider
the following list of conversions:

	int <- char	-- types are different, no information lost
	double <- float -- lower bits contain essentially garbage
	float <- double	-- possibly lose precision, small number becomes 0
	int <- float	-- ditto
	float <- int	-- may lose bits on the lower end of large ints

Problems could arise in all but one of these cases, but it is very rare
that such things trouble me.  However, it would be tedious and not in the
least bit more readable to me if I had to cast every piece of data whenever
I wanted a mixed expression.  (assume a is int, b is float, and c is char)

	(float)a + b * (float)(int)c

is much less readable to me than

	a + b * c

I may be unusual in this (I doubt it), but programming errors in this area
give me few problems.  What's more, I've never had much difficulty finding
them when they did occur.  C does what I expect, and I expect what it does.

One area where I believe explicit casts should be required, even though such
casts rarely change the bit-pattern of the representation of the value, is
is where pointers are used.  In my earlier days I ignored casts to pointers
because the values did not change.  It proved to be the source of my most
obscure and difficult bugs.  It was not and is not my intention ever to
suggest that casts on pointers (when different types are involved) should
be ignored.  Our C compiler here gives warnings whenever pointer types do
not match.  But I believe that is as it should be.

DP> [arguments about array bounds-checks]

ES> A modern language should of course allow dynamic arrays.

That, more than almost anything else, is something I use.  C gives me that;
Modula-2 does not.

DP>  [Runtime] bound checks are expensive in terms of efficiency.

ES> This, I'd say, is an really old-fashioned argument.

Some things are simply timeless...

ES> when hardware is cheaper than software, buy faster software, don't
ES> remove the array checks. Believe, you save the money just in having
ES> the program crash on array overrun, than searching for those funny
ES> errors caused by having data unexpectly over-written.

This is another error I have had few problems with.  I am always careful
to put the checks in, but I put them in where they are less likely to slow
the execution.  For example, I build the checks into the preliminary stages
of loops, rather than array accesses within loops.  That way I check once
at the beginning of the loop that the indexes will not overrun, rather than
a dozen times within each pass of the loop.  Few compilers have the smarts
to do equivalent things for me, and I'd usually end up doing it anyway.

This whole thing is really a minor point anyway.  I wouldn't condemn or
avoid a language because it had runtime array checking.  That sort of thing
just doesn't bite me very often.

DP> [C] assumes (rashly) that the programmer knows what s/he is doing.

ES> And this is just so wrong, wrong, wrong! We have lived with computers so
ES> long that we know that programmers very often only are just dimly aware
ES> of what they are doing.

This is not the problem of a language, it is the problem of a programmer!  If
a person does not understand what s/he is doing, how will I have confidence in
what s/he has written, whatever the language!?!  A programmer is simply a
person who translates concepts from one language (that of the application) to
concepts in another language (that of the programming model).  It is very
similar to natural language interpreters.  If I were to hire a Russian
to interpret for me, I would want one who understood both Russian and English.
A failure to understand either one would mean he was not an interpreter.  If I
hire a programmer, I want him to understand the machine (model) as well as the
application.

If you were to argue that programmers who know and understand C well are not
able to rapidly produce efficient and relatively bug-free code, or that C
is inordinately difficult to learn for the benefit it gives, I might be more
simpathetic.  Its expanding popularity serves as evidence against both of
those arguments.  All you have argued is that the standards for graduation
in computer science are much too lax.

ES> [C is used when other languages might be better, because C is more
ES> standardized and portable.]

Again I say, "The right tool for the job."  C has some very nice features,
but it is not the only language in town, and it does require a certain
amount of skill and caution in its use.  Does that mean it should be
avoided?  Absolutely not!  Programmers should know several languages, since
no single language can handle all applications (not even Ada).  Programmers
should also understand what they are doing.  If too few can make that claim,
then C is not the biggest problem we have.  We should require the same
professionalism of programmers that we require of most other engineering
and scientific disciplines.

ES> Erland Sommarskog       
ES> ENEA Data, Stockholm    
ES> sommar@enea.UUCP        
ES>                    [opinionated comment deleted, again]

--
Doug Pase   --   ...ucbvax!tektronix!ogcvax!pase  or  pase@cse.ogc.edu.csnet