Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!lll-winken!sun-barr!newstop!texsun!convex!rosenkra From: rosenkra@convex.com (William Rosencranz) Newsgroups: comp.sys.atari.st Subject: Re: standard practices Message-ID: <1991Mar21.065817.1799@convex.com> Date: 21 Mar 91 06:58:17 GMT References: <1991Mar20.204257.26740@convex.com> <324@uqcspe.cs.uq.oz.au> Sender: news@convex.com (news access account) Organization: Convex Computer Corporation, Richardson, Tx. Lines: 126 Nntp-Posting-Host: convex1.convex.com [ after re-reading my response, i should mention this is not any sort of personnal attack. no offense intended. i just like to debate :-) ] In article <324@uqcspe.cs.uq.oz.au> warwick@cs.uq.oz.au writes: >In <1991Mar20.204257.26740@convex.com> rosenkra@convex.com (William Rosencranz) writes: >>it would be really nice if unix-like programs on the ST (or anywhere, for ^^^^^^^^^^^^^^^^^^ i was not refering to gem stuff. and nor would i assume people who prefer gem are "_potentially_ dim wits". to each his own... >-debug - Very rarely used, so should be #IFDEFed out in releaase. i use it alot. and it can often help users who just want to see what goes on behind the scenes (i.e. seeking knowledge not found in a manpage) or are trying to find out why the command is not working the way they expect. i leave in debug stuff, regardless how much larger it makes the code, especially in large, complicated codes (like nroff). i am thinking about saving MY time, not the computer's. >-help - No way! I MUCH prefer "man " - and again, save on program >size. the "save on program size" argument was fine in the days of < 64k memory and 160k floppies. this is 1991 and we can get megabytes for real cheap these days. i think you should start thinking about *your* time and not a couple of dollars saved on disk/memory. i am talking about less than 1k for all this, text+data. 1k out of 4 MB memory is nothing. 1k * 100 programs out of 60 MB (or even 20MB) of disk is nothing. less than 2 spectrum or 3 degas pictures, to put it in perspective. >-changes - No, stick it in the manual. often the manual does not match the program. putting a few lines out to the screen does not hurt here. i'd rather do: gcc -changes than wade thru endless readme (or worse: source) files, if they even exist! >See. Standards only work if they are inarguably beneficial. i think u are argumentative just for the sake of argument... all these things ARE beneficial. tell me, just who does it hurt? if u don't want to type "cmd -help", so don't. but lots of times i just plain forget lesser used options. like on (my) cc(1) which has a zillion options. or are u suggesting that we limit functionality to make use easier? doing "cc -help" and getting the info in a very terse, concise way is much faster than using man and wading thru pages of docs. i work mostly from home at 2400 baud. and believe me, reading man pages is no great joy. having a "-help" option in no way hurts my (sizable) ego. in fact, just the opposite: i would call the programmer considerate for not making me try to remember every single scrap of information without openning a book, electronic or otherwise. >Personally, I write more GEM stuff than TOS stuff, and in THAT CASE, "help", > "version" >and "changes" are good things to include - because the average GEM user is >_potentially_ >a dim wit - so it goes to make the program more User Friendly. People who use >command lines are used to using "man" or just "more"ing the documentation. boy, i sure hope you are not trying to sell your codes, after demeaning your potential customers :-) you are defeating your own argument: making code user friendly, even for (or ESPECIALLY for) experienced users is why we have computers in the first place. i'd rather the computer be my slave than visa versa. i have been using command lines for over 15 years. i have been using "man" for 7 years and NOS equivilents long before that. believe me, i am very used to it. before that i used cards and lugged around pounds of paper for my "man" command (let my fingers to the walking :-). but i also am keenly aware of what makes people productive programmers and users. and not having to stop and look something up is of great value to me, at least. if i can't remember the switch on make(1) to print out the internal macros (is it "-m" for "macro" or is it "-p" for "print" or is it "-z" because it is unix :-), i'd rather, in 1.5 seconds, do: % make -help usage: make [options] [definitions] [targets] options: -i ignore error codes -s silent -r no built-in rules -n no execute mode -t touch target files -q question -p print out macros -d debug mode -f file alternate makefile (searches for "makefile" then "Makefile") % about 275 bytes data, and about everything an experience user needs to know, though adding environment variable info is also helpful. self documenting code is the best, IMHO. and see, make DOES have a debug option! not #ifdef'd (at least alliant's make the closest *MANUAL* i had available :-)... incidently it took 25 seconds to find it in paper manual (another 30 sec to find the manual). "man make" would take about the same, maybe somewhat faster, maybe slower, depending on how many times "macro" appeared befor your PAGER's /string search found -p (i use less). or do i have to remember the propper search string, too? i am not blessed with a photographic memory. with a "-help" option, there is only one thing to remember: use -help for a command synopsis. i would wager that the average programmer has to remember millions of rules and facts. my goal is to try and minimize this so that he can concentrate on creative programming and deductions rather than remembering still more rules and facts. anyway, thanx for the input. i am not going to stop doing this in my programs which i post. i was just hoping that others would start doing it in theirs. since i post source, you are free to remove all this seemingly wasted space :-) question: if posix 1003.2 had said something like this, would u still disfavor it? just curious... -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com