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