🚀 go-pugleaf

Pase & Sommarskog have been bashing each other for a while now, and
both of them have made some valid points.  Let me just add another
viewpoint in case anybody else is interested in this debate.
(Hmmm 45 minutes later this has gotten rather long, but there are some
newish (and maybe even interesting :-) ideas, and only about 70 of the
lines are mine, the rest are context)

In article <1522@ogcvax.UUCP> pase@ogcvax.UUCP (Douglas M. Pase) writes:
>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.
>I am neither in favor of change nor against it.  I am in favor of flexible
>languages and programmers understanding what they are doing.
>
>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 think part of the point here is that there aren't many `modern
languages'.  Particularly not in this discussion (here I don't mean
modern to mean `recently designed', but rather `designed with new and
better ideas').  C, Modula2, Pascal and to some extent Ada are
equivalent languages, 15 years old with minor syntactic sugar
differences.  The major differences are in how strictly the compilers
enforce language rules.  (Ada does have some `new' (and maybe even some
`better') ideas.  Prolog has some `new' (and probably `better' for some
application areas) ideas.)

>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...]
>
>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?
> ...
>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.

I feel there are 2 areas where C is more error prone than the Pascal
class of languages: parameters and pointer arithmetic.  I think the
new ANSI C definition with function prototypes addresses all the
problems with value parameters, and wish the compilers required
function prototypes all the time.  I feel previous C compilers left
too much of the consistency validation to `lint', which because it is
a separate program is too often forgotten.  var parameters in C are a
design flaw, but I don't think they cause TOO many bugs (not of the
lurking type anyway).  Pointer arithmetic is a trade off: lots of
power ==> potential errors.  I think it's worth the trade-off.

>DP>  [Runtime] bound checks are expensive in terms of efficiency.
>ES> This, I'd say, is an really old-fashioned argument.
>
>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.

I agree with both on this one.  Bounds checks are worth having (partly
because not all programmers have DP's discipline, and you usually
over-run bounds when the program has been in place & working for
years (unless you test it RIGHT)).  I have a language I've designed
that combines the best of pointer arithmetic & checked bounds and is
easy to compile.  (I.e. the efficiency of pointer arithmetic, with
checked ranges, but the check is done at compile time or outside the loop)
So I feel it's a language design problem, but that the Pascal
languages didn't solve it right.

>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!
Yes, and no.  At a certain level, we better hope the programmer knows
what they are doing (regrettably hope is often all we have).  But that
does not mean that the language should stand idly by and watch the
programmer foul up.  All of us as programmers can deal with certain
levels of complexity & detail (with order-of-magnitude differences
between programmers).  The more the programming language helps us deal
with and hide the complexity and detail, the more likely that Klutze
Programmer's weapons control system will work rather than start WWIII
(and the more likely that the genius programmers among us can build
Truly Great And Important Programs to Better Our Way Of Life).

>ES> [C is used when other languages might be better, because C is more
>ES> standardized and portable.]
That's the main reason I use it (although I'm an assembler hack at
heart, too, so the `portable assembler' nature of C attracted me).  I
used to use Pascal, but as I started using more different systems, the
only thing they had in common was C, and as I was getting too old to
re-write all my tools for every new environment, I standardized on C
(and Unix when I can get it). 
>
>Again I say, "The right tool for the job."
Good in theory, but if you want to stay portable, C is often the only
tool (except for Fortran, of course :-).  That doesn't mean I don't
use other languages.  But rarely for anything big.  If it's big, I'll
probably want it in several different environments, and also that it's
worth my time writing the utility functions to give me the power that
the other (`better') language would have given me.

One of the most important reasons for knowing other languages though
is the introduction of other programming paradigms.  I'm currently
playing with LOGO, for exactly that reason (and cuz there's a couple
good books by Brian Harvey, and I'm considering teaching first year
computer science in Logo).

> ... We should require the same
>professionalism of programmers that we require of most other engineering
>and scientific disciplines.
Now that's a REALLY scary thought! (Baupal, India; Challenger; Love Canal)

>ES> Erland Sommarskog
>ES> ENEA Data, Stockholm
>ES> sommar@enea.UUCP
>Doug Pase   --   ...ucbvax!tektronix!ogcvax!pase  or  pase@cse.ogc.edu.csnet

	../Dave Mason,	TM Software Associates	(Compilers & System Consulting)
			Ryerson Polytechnical Institute
	..!{utzoo uunet!mnetor utcsri utgpu lsuc}!tmsoft!mason