restivo@POLYA.STANFORD.EDU (Chuck Restivo) (04/08/88)
Date: Tue 5 Apr 1988 11:34-PDT >From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU> Reply-to: PROLOG@SUSHI.STANFORD.EDU US-Mail: P.O. Box 4584, Stanford CA 94305 Subject: PROLOG Digest V6 #12 To: PROLOG@SUSHI.STANFORD.EDU PROLOG Digest Friday, 8 Apr 1988 Volume 6 : Issue 12 Today's Topics: Implementation - Code Formatting & Wisdom ---------------------------------------------------------------------- Date: 13 Feb 88 18:40:17 GMT >From: ed298-ak@violet.Berkeley.EDU (Edouard Lagache;;;6310183;GY24) Subject: Re: code formatting (even more random musings) - Touche! Regards to Dr. O'Keefe's Comments on coding readability: 1.) Touche! 2.) Sorry for the spelling errors, that will learning me not to type on the fly when I should use my trusty speller checker. 3.) With all due respect, I was not proposing that there not be any coding standards. On the contrary, as my note suggested our courses have fairly strong coding standards to get students to adopt good habits. My comment on creativity was noting how varied the result one sees even with those standards. 4.) I was glad to see that Dr. O'Keefe noted the creativity involved in programming. I believe that I called programming a craft, not a science. Unfortunately, most people these days have lost sight of that fact. The creativity I was concerned about is the type one sees in hand tailored suits, custom furniture, and programs. 5.) Unless we recognize both our constraints in coding, and the freedoms we have, we will never be able to use our creative energies to make our code more readable, (or flexible, or whatever). I think again that Dr. O'Keefe and I are again probably in general agreement, but my words failed to convey my actual feeling on the matter. -- Edouard Lagache ------------------------------ Date: 13 Feb 88 05:03:36 GMT >From: cbosgd!mandrill!arun@ucbvax.Berkeley.EDU (Arun Lakhotia) Subject: Re: code formatting (some amusing musings) Have you ever read a Pascal program that was completely left aligned. Not too long, just about three pages. With global variables like 'x', 'xxx', 'yz' etc. What if the author came to you to find a bug in that mess, and further told you that s/he would run it through a beautifier while submitting the assignment. Or have you ever seen a C program that was about 12000 lines long. The whole program in just one file. I have. And when I did see them, I knew they were bad programs written by programmers who were taught the language constructs, but not programming. There is no way i could appreciate them on grounds of creativity, freedom of expression, individualism or anything else. I have also seen nice elegant programs. And in most cases just the stucture, layout or indentation tells you that the program is well written. Elements of beauty are hard to express. But one you do come across one there is usually a consensus on whether something is beautiful. Good programming style is a necessity not a luxury. From what I have seen, people who have good programming style, spend less time in debugging. Or else I know of people who since the last 3 months are debugging a program that they wrote in only 5 days. I strongly support Richard O'Keefe's view about programming. One should program for human readability first and machine later. Its not just for your successor. In the course of development of a project, you may write the code only once, but read it several times. If you try to save on typing, you end up spending time in deciphering. Using 'line_counter' instead of 'l' saves you the hassle of a mental conversion of "'l' carries 'count of lines'" every time you read the code. Like Lagache and O'Keefe, I too have been a TA. I was grading Pascal programs. In the very first assignment I set a guideline. A program *should* have procedures Procedures *should* have parameters Global variables *should* have meaningful names No procedure *should* be more than 1/2 a page begin/end *should* be properly matched and code indented There *should* be some comments, what-so-ever Not that these rules define a good program. They just forced people to use procedures and parameters: a concept that has a steep learning curve or write sensible procedure and variable names that made grading an assignment much more enjoyable. *Not* surprisingly I did get well structured programs. And in most cases when the programs were well structured they were also well written. By no means are these guidelines to be complete, but i do appreciate a need for some guidelines rather than a free-for-all world. The above rules do leave a whole lot to creative thinking. But all the same they provide a guideline for a creativity that is appreciated at large. I have met several people, especially in the industry, who are always looking for a *quick and dirty* solution. And i have always wondered: Why does quick have to be dirty? I know it is easy to end up with a dirty program very quickly. And when a dirty program does work *correctly* I almost feel it is a miracle. Most of the time the program is very complex with kludges thrown in left, right and center, while there is always an equivalent program which may be very simple and almost close to being trivial. There has been an instance when I saw a very knowledgeable programmer trying to code a simple algorithm that had a polynomial time complexity. But his programming process itself was of Non-deterministic Polynomial time complexity (NP complete). It was then that i realized that it is not just the time complexity of the algorithm that is important, the time complexity of the programming process is equally important. That could only be tackled by evolving a sense of *good* style. I do *not* claim that I am a great programmer. But i sure would like to become one some day. And I do look forward to critiques like Richard O'Keefe to shape my style. It's sad to see he is on a one man crusade to shape the world. I am sure there are other grandmasters who share his views and do hope they would speak up sometime. There are several times I find O'Keefe's comments harsh. Pointing out spelling mistakes, which could very well be typos, too is not a very convincing style of argument. But that to my mind does not reduce the gravity of his concern otherwise. Alas!! every human is fallible. I think O'Keefe's suggestion of running an experiment on programming style is very neat. I hope there is someone out there in the organization committee of the ICLP who would be listening (reading :-). -- Arun Lakhotia ------------------------------ Date: 14 Feb 88 05:59:18 GMT >From: quintus!ok@unix.sri.com (Richard A. O'Keefe) Subject: Re: code formatting (even more random musings) - Touche! > 2.) Sorry for the spelling errors, that will learning me not to > type on the fly when I should use my trusty speller checker. I did use 'spell', repeatedly. Which meant of course that the spelling mistake which resulted in a valid English word survived. Anyone know of a cheap spelling checker for UNIX which takes grammar into account? > > I think again that Dr. O'Keefe and I are again probably in general > agreement, but my words failed to convey my actual feeling on the > matter - Oh well, too many late nights I guess! > Eduoard: C'est blanc. Richard: No, it's white. ------------------------------ Date: 15 Feb 88 10:39:32 GMT >From: mcvax!ukc!its63b!jha@uunet.uu.net (J Andrews) Subject: Re: code formatting (even more random musings) | blah blah blah | |Let me quote Henry Spencer: | | meta-blah blah blah | |> Inspite |Should this be "In spite"? There is no word "inspite". ^^^^^^^ | | blah blah blah | |Let me offer an example of "creativity". | In my MSc work... | | blah blah blah | | Laws and patterns *enable* the Great Dance, they are a |trellis for the vine of life, a skeleton for the playing otter. | | blah blah blah | | (If you think you know who |I have in mind, you're *wrong*. Yes you are.) | | blah blah blah Personally, my theory is that O'Keefe *is* Henry Spencer. Their styles are amazingly similar. They even both quote from themselves. Has anyone ever seen them together? On the other hand, O'Keefe, on odd, random occasions, seems to actually know what he's talking about, so that theory doesn't quite hold. Perhaps Spencer/O'Keefe has a split personality? >Summary: > > blah blah blah > > Who would you rather buy a program from? Will some given answer cause him to stick to posting sensible articles? If so, that's my vote. ------------------------------ Date: 17 Feb 88 08:21:11 GMT >From: quintus!ok@unix.sri.com (Richard A. O'Keefe) Subject: Re: code formatting (even more random musings) To the best of my belief I have never met Henry Spencer, which is a pity, because I've learned a lot from his postings, and would like the opportunity of thanking him in person. You would not, however, suspect us of being being the same if you saw C code written by me and C code written by him (I like to think that my code is nearly as good as his, but there are strong stylistic differences). Please do not spread rumours like this. There is an organisation called the I.R.S. which is only too eager to follow up suggestions that one person is collecting two incomes (:-). ------------------------------ Date: 9 Feb 88 04:27:10 GMT >From: ed298-ak@violet.Berkeley.EDU (Edouard Lagache;;;6310183;GY24) Subject: Re: code formatting (even more random musings) With all due respect to Dr. O'Keefe, does he ever have anything positive to say? I must admit that I find his concerns about code readiability and "standard style" to be rather amusing. As the head TA in a programming course I grade programs in 4 languages, and I assure you that even with fairly strict style conventions, every new grading task is usually an enjoyable experience in discovering the depth of human creativity. Inspite of this abundance of different coding styles, rarely do I have to send students back due to "unreadable code". Come now, should we for the sake of communication standardize on only one form of greeting, or article format, or even commenting style? In this terribly structured, dry, and mechanistic world, I vote that we hang on to whatever means of creative expression remain - even if it is a simple as how we box our comments! -- Edouard Lagache ------------------------------ Date: 21 Jan 88 04:08:54 GMT >From: mtune!whuts!homxb!mtuxo!mtgzz!drutx!druhi!kam@rutgers.edu (MorrisseyKA) Subject: WISDOM prolog Does anyone out there have WISDOM prolog, the one listed in the back of "The Art of Prolog"? I have the IBM PC version 2.00B. I ordered it fall '86, it arrived summer of '87 after two broken promises of availability, and now that I have finally started using it I am disapointed. It is poorly documented, the manual is poor and sadly out of date compared to the software. It crashes when running a compiler I had written under C-Prolog. It doesn't even handle tail recursion. Anyone else out there have any other experiences? ------------------------------ Date: 25 Jan 88 19:48:06 GMT >From: tikal!phred!daveh@beaver.cs.washington.edu (Dave Hampton) Subject: Re: WISDOM prolog After a year and a half of monthly phone calls to MIT Press, I finally got a copy of Wisdom Prolog 3 months ago, and it is pretty sad. The documentation and editing capabilities are non- existant, and I, too, have run into a number of crashes. I also got the disk which contains the programming examples from the book. It arrived a year before the language disk (and was billed a year before the language disk, even though it couldn't be run...). Every example was copied (accurately, I must admit), even the ones which don't run under Prolog (Programs 3.1, 3.2, and 3.3, for example). Overall, a very disappointing purchase. Back to Turbo Prolog, I guess..:-)... -- Dave Hampton ------------------------------ End of PROLOG Digest ********************