Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!bu-cs!bzs
From: bzs@bu-cs.BU.EDU (Barry Shein)
Newsgroups: comp.lang.misc
Subject: Re: Check the Arg Count
Message-ID: <3226@bu-cs.BU.EDU>
Date: Fri, 2-Jan-87 17:20:52 EST
Article-I.D.: bu-cs.3226
Posted: Fri Jan  2 17:20:52 1987
Date-Received: Fri, 2-Jan-87 21:00:56 EST
Organization: Boston U. Comp. Sci.
Lines: 72


From: mangoe@mimsy.UUCP (Charley Wingate)
>You still haven't explained why lint as a processor should be logically and
>functionally distinct from cc as a processor.  The ONLY reason I can see for
>separating them is so that you don't have to be confronted with messages
>telling you that you're writng tricky or otherwise dubious code.

Lint goes further than that really. One nice thing about the
arrangement is that it can warn you of things that are not "tricky or
dubious". For example, non-portable constructs (it's not irrational to
write a non-portable program, it happens legitimately, or perhaps
something that will only be made portable via different link
libraries.)

I remember PL/1 was full of "warnings" and "informational" messages,
to the point that the programmers I worked with simply ignored them
(oftentimes disasterously.) You have to draw a line, running lint
every so often as a double-check is a real plus (in my opinion.) I get
the msgs when I want them (of course, I also remember that PL/1 had
both a checkout and optimizing compiler, unfortunately that was a real
mess, like it wasn't uncommon that they refused to compile the same
programs.)

>No.  Students shouldn't HAVE to learn to use things like lint, in my
>opinion, because they shouldn't have the option of NOT running things like
>lint.

I repeat, setting up an environment to force them to use lint is
trivial.  At least you get the choice, and if you have to run on an
overloaded machine you can take your chances that they will run lint
voluntarily, perhaps not on every little edit fix, but often enough (I
am dubious that people who will resist "doing the right thing" are
going anywhere anyhow, at least right now, maybe they'll mature.)

Does your opinion extend to the following:

Makefiles: Surely this is at least as good a practice as running lint.

Make dependancy scripts: again...

Separate source compilation: oops, can't even do this in standard
Pascal in any rational way, oh well...

Using library routines rather than treating programming as an ad hoc
exercise: oops again, as I've said before you need one strlen routine
for every length of string in pascal, can't write a generalized sort
routine either, gotta ad hoc that also, same for I/O routines and
anything else that might benefit from being written once by an expert
rather than hacked together for every new program because you can't
get around the "strong" typing.

Why do I drag all this in? Because I am utterly convinced that this
entire mindset of forcing the user to be what s/he isn't (careful,
conscientous etc) is an utter failure. You want a good program? Hire
a good programmer. You want to become a good programmer? Ya gotta
work at it. Sorry, ain't no short cuts.

The solution is not to put more restrictions in programming languages
in an attempt to control the incompetent at the expense of the
competent. The solution is to teach good design. 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.

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. This is due to the very poor design
inherent in these. It is not surprising they appeal to those who
discount careful design and effort as being the ultimate goal. In
short, the "emperor" has no clothes.

	-Barry Shein, Boston University