Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!spf
From: spf@clyde.UUCP
Newsgroups: comp.lang.misc
Subject: Re: Check the Arg Count
Message-ID: <5020@clyde.ATT.COM>
Date: Fri, 9-Jan-87 17:37:32 EST
Article-I.D.: clyde.5020
Posted: Fri Jan  9 17:37:32 1987
Date-Received: Sat, 10-Jan-87 05:36:05 EST
References: <3226@bu-cs.BU.EDU> <1635@enea.UUCP>
Sender: lp@clyde.ATT.COM
Reply-To: spf@bonnie.UUCP (Steve Frysinger)
Organization: AT&T Bell Laboratories, Whippany NJ
Lines: 86


Building on a followup by sommar@enea.UUCP (Erland Sommarskog):
>
>In article <3226@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes:
>>The solution is not to put more restrictions in programming languages
>>in an attempt to control the incompetent at the expense of the
>>competent.

  Who said we were trying to control the incompetent? You know, I wear
boots when I use my axe, even though I have a lot of experience
with axes.  I like to protect myself against mishaps.

>> The solution is to teach good design.

  This is a very funny argument; a "good design" will be largely independent
of language.  The more powerful (i.e. permissive) the language, the
weaker its compiler.  The "highness" of a language determines the
strength of its compiler, and deals primarily with PROGRAMMING, not DESIGN.
The fact that I typed = when I meant == in C is NOT a design issue,
it's a programming issue.

>> Design involves
>>choices and rules, not removing all the sharp knives from the woodshop
>>for fear that some turkey will come in and cut him/herself.

Even the "competent" wordworker wears safety glasses.

>>
>>Unfortunately, Pascal makes a false promise it has never been able to
>>keep. In fact, it and its successors (at least as of this date) have
>>been by and large a failure in practice. Very little code of any use
>>has ever been written in them.

Got Data?  I've done a lot of real-time image-processing code in
Pascal (perhaps 100,000 lines of source delivered), and wonder how
much of a failure it was.  I don't claim Pascal is the Platonic
programming language; there is no such thing.  But more often than not
it's my language of choice, because it will allow me to do the job
more quickly, and with fewer errors, than the other contenders.  I've
had great success with Pascal programs which call occasional assembly
language or C routines when low-level machine access is required.

>Well, I may missunderstand what you mean, but to me it seems that you are
>trying to say that type-checking languages like Pascal, Ada etc are inferior
>to languages that are more relaxed at this point, like C. Also you seem
>to imply that type checking is only for bad programmers. 

  That's what I read from the argument too.  And that's precisely the
opposite of my opinion.  My rule is "Use the highest level language
which will do the job, because that brings the most powerful
compilation tool to bear and reduces the number of errors which hit run-time.
  The egos of a lot of programmers cause them to miss an important
point:  beyond a fairly short start-up, a programmer's error rate does
not substantially decline as a function of experience.  This is partly
due to psychological learning issues, and partly because task load
often increases with experience, with reduced attention masking any
improvement in the error rate.

>Or do you think that I'm bad at design just because I make these mistakes?
>Actually, I can't escape the feeling that the people who advocates 
>relaxed checks are those who are bad at good design. The more of tricks you put
>into it, the harder to understand it is. A good programmer don't feel
>restricted by a checking compiler, he feels supported.

Right-on.  I regard programming as a means to an end, and thus take
an "engineering" point of view (as opposed to a "for the fun of it"
point of view).  When I write a program (even for my own use only)
I want to minimize the amount of time I have to spend scrutinizing the
code (let a strong compiler do that), and maximize the likelihood that
I'll be able to read and understand the program a year or more later.
This is even more important when developing software for others.
Since there is an inverse relationship between the power of the
language (i.e. what it lets me do) and the strength of the compiler
(i.e. what mistakes it won't let go by), I choose the WEAKEST language
that will still do the job, and thus use the most POWERFUL compiler
I can.  Remember, fans, even K&H assert that C is only a "relatively
low level language" ["The C Programming Language", Kernighan and
Ritchie, Prentice-Hall 1978].  Is it a powerful language? YES (and fun,
if that's what you want)!  Does it have a strong compiler? NO, it
can't!  So many things are legal in C that erroneous code often goes
by, because it looks like some other legal construct.

Steve Frysinger
****
Remember what the doormouse said: "Feed your head!"
		-- Jefferson Airplane