ed298-ak@violet.berkeley.edu (Edouard Lagache;;;6310183;GY24) (02/09/88)
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 lagache@violet.berkeley.edu
mohan@hplabsb.UUCP (Joseph Mohan) (02/10/88)
<<
Evidently Lagache and I don't live in the same world. The world I
live in is full of water, living things, fractals, coincidences, and
surprises. Laws and patterns *enable* the Great Dance, they are a
trellis for the vine of life, a skeleton for the playing otter.
If I want to be creative, I can write poems, I can play musical
instruments, I can make up stories, I can invent new algorithms and
data structures. I'm not so short of ways to be creative that I
have to invent new ways of being obscure. YES, let's be creative.
But let's be creative in ways that aren't a burden to other people!
>>
What wonderful writing! If you ever wrote a book, R O'K, I'd buy it
with my eyes closed. The best writing I have ever seen on any bboard!ok@quintus.UUCP (Richard A. O'Keefe) (02/10/88)
In article <6923@agate.BERKELEY.EDU>, ed298-ak@violet.berkeley.edu (Edouard Lagache;;;6310183;GY24) writes: > > 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. ^ I worry about spelling, too... When did I ever say "standard style"? Funny, I thought that in urging people to try to make their programs readable and save their creativity for solving real problems I *was* being positive. I suggested that it would be worthwhile to perform experiments to resolve some of these questions, and offered to help. Is that not being positive? Will nothing less than capitulation to the Humpty-Dumpty school strike Lagache as positive? Let me quote Henry Spencer: It's quite true that such a set of decisions is, to some degree, a matter of personal style. However, to my dying day I will fight the idiot notion that "there is no such thing as bad style, only different style". All of the above examples are thoroughly bad style, not just different but inferior: they are dangerous, error-prone, hard-to-follow constructs that should be avoided like the plague. Even when the situation is not this extreme, though, there are solid objective arguments for using a standard style in anything that somebody else might have to maintain one day. The phrase "anyone should be able to understand that" is the mark of the amateur, more concerned about his own preferences than his successors' problems. Note: Spencer says "a standard style". I don't. I do think that anyone who hasn't sought out objective readability principles and redesigned his coding style around them is being a fool to himself and a burden to others. What is "amusing" about my "concerns about code readability"? Is undreadability a virtue? > 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. I've done this sort of thing too. But what >size< of program do you grade, sir? You can get away with a lot in a one page program. It's interesting that Lagache says "the DEPTH of human creativity". One only says "the DEPTH of X" when one dislikes/disapproves of X... It's also interesting that he says "WITH STRICT STYLE CONVENTIONS". > Inspite Should this be "In spite"? There is no word "inspite". ^^^^^^^ > of this abundance of different coding styles, rarely do I have > to send students back due to "unreadable code". Eh? A sentence ago he said that they had "fairly strict style conventions". Now he says that there is an "abundance of different coding styles". Which should I believe? I don't know how to evaluate this. Which are the four languages? Do any of the compilers pretty-print the listings? (I've been associated with ALGOL and COBOL courses where the compilers did that, and what a boon it was.) What is the range of stylistic variation? What size of programs are these students writing? Are the programs individual efforts, or is the "Software Hut" approach being used? Are code formatters (note that 'indent' is widely available for C) available to the students? Do the students who give Lagache such pleasure with the inventiveness of their layout produce better/worse **algorithms** than those who stick to the layout they saw in their textbooks? > Come now, should we for the sake of communication standardize > on only one form of greeting, or article format, or even commenting > style? (1) If I went up to Lagache and said "Teenaa koe!", I don't think he'd understand me. Most people back home would. If I greeted him "Are you at yourself?", I don't think he'd understand me. Let's face it, within any one group, greetings *are* pretty much standardised. There was a time in my life when I tried inventive greetings & replies to greetings, and I got some very funny looks. That is, "inventive" greetings fail *as greetings*. (2) In most journals, there IS a single article format, and a great help it is. Come now, would you like every article in TOPLAS to be laid out differently? Would that really help? (3) I don't recall suggesting that everyone should follow a single commenting style. I did suggest some fairly minimal guide-lines, but they leave room for a lot of variation. Let me offer an example of "creativity". In my MSc work, I had the problem that my topic had links to three areas of physics, and unfortunately they all used different notation for the same things: there was a quantity that some texts called "alpha", some called "-gamma", and others called "-(k**2)". The texts which used "alpha" also had something called "k", which was not the same as the "k" in "-(k**2)". Coping with differences that were not different and similarities that were not similar was a lot of quite unnecessary pain. > 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! > Evidently Lagache and I don't live in the same world. The world I live in is full of water, living things, fractals, coincidences, and surprises. Laws and patterns *enable* the Great Dance, they are a trellis for the vine of life, a skeleton for the playing otter. If I want to be creative, I can write poems, I can play musical instruments, I can make up stories, I can invent new algorithms and data structures. I'm not so short of ways to be creative that I have to invent new ways of being obscure. YES, let's be creative. But let's be creative in ways that aren't a burden to other people! The layout rules and naming rules I work by are not a cage; they are *tools* just like the Prolog library (800 predicates and growing). They are things I don't have to think about any more. Let's take a current example: I have been challenged to produce a Prolog solution for a certain problem which is "about" as efficient as an existing C solution. This particular problem is going to require very careful thought, and it's also going to require most of my creative powers: I'm going to have to go back to an abstract description of the problem and turn it inside out a couple of times. ANY effort put into layout and naming is going to distract me, and if I didn't already have a kit of data structures and naming rules to take as given, I don't think I'd be able to do it. Even new style rule I add to my kit gives me more freedom: I get to spend more of my time on the mural and less time erecting the scaffolding. Without naming names or pointing fingers even indirectly at specific people, let me say that I have found a strong correlation between the care that people take to make their programs readable and the quality of their code in other respects. (If you think you know who I have in mind, you're *wrong*. Yes you are.) Summary: I believe that every aspect of my code should be criticised by objective standards, and worry about readability. Lagache believes that coding style is a matter of taste and an appropriate arena for "the depth of human creativity", and finds my "concerns about ... readability ... amusing." Who would you rather buy a program from?
varol@cwi.nl (Varol Akman) (02/12/88)
In article <54200003@hplabsb.UUCP> mohan@hplabsb.UUCP (Joseph Mohan) writes: ><< >Evidently Lagache and I don't live in the same world. The world I >live in is full of water, living things, fractals, coincidences, and >surprises. Laws and patterns *enable* the Great Dance, they are a >trellis for the vine of life, a skeleton for the playing otter. >If I want to be creative, I can write poems, I can play musical >instruments, I can make up stories, I can invent new algorithms and >data structures. I'm not so short of ways to be creative that I >have to invent new ways of being obscure. YES, let's be creative. >But let's be creative in ways that aren't a burden to other people! >>> > >What wonderful writing! If you ever wrote a book, R O'K, I'd buy it >with my eyes closed. The best writing I have ever seen on any bboard! Another very loud applause from this side of the Atlantic for R O'K's (now this looks complicated :-) insistence for being lucid !!! To add a short comment: The fact that mathematics is a formal system with well-defined rules *to be followed* didn't and doesn't prevent mathematicians from discovering beautiful theorems.
kam@druhi.ATT.COM (MorrisseyKA) (02/13/88)
Software that does something of value will continue on long after the author has left. Software of value is often the product of multiple people working serially or concurrently on the same code. Uniform style is important at all scopes: within a single program, within a project, or within a company. Differing styles, especially within a single program, will make it more difficult for others to understand the program. Even arbitrary standards are beneficial. A standard does not need to be the best. Who can even say what best is? The value of standards is that they are shared. Karen A. Morrissey 1-303-538-4587 ihnp4!druhi!kam
arun@mandrill.CWRU.Edu (Arun Lakhotia) (02/13/88)
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
PS: A thumb rule for good programming from: Elements of Programming Style,
Kerningham and Plaugher (I think).
"KISS: Keep It Simple and Stupid..." ed298-ak@violet.berkeley.edu (Edouard Lagache;;;6310183;GY24) (02/14/88)
In 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 - Oh well, too many late nights I guess! Edouard Lagache lagache@violet.berkeley.edu
jwl@ernie.Berkeley.EDU (James Wilbur Lewis) (02/14/88)
In article <6974@agate.BERKELEY.EDU> lagache@violet.berkeley.edu.UUCP (Edouard Lagache) writes:
- 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.
Since when are science and creativity mutually exclusive?
-- Jim Lewis
U.C. Berkeleyok@quintus.UUCP (Richard A. O'Keefe) (02/14/88)
In article <6974@agate.BERKELEY.EDU>, ed298-ak@violet.berkeley.edu (Edouard Lagache;;;6310183;GY24) writes: > 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.
shebs%defun.utah.edu.uucp@utah-cs.UUCP (Stanley T. Shebs) (02/15/88)
In article <2363@mandrill.CWRU.Edu> arun@mandrill.UUCP (Arun Lakhotia) writes: >[O'Keefe on coding 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. I'm not a grandmaster, but am a strong believer in the value of programming style, and have crusaded for it when I've had the opportunity. Most of the time the effort seems more like a windmill tourney, however. Many of the people attracted to programming seem to take pride in trying to deal with as much obscure detail as possible, and resist any attempts to reduce the amount of it. After trying various approaches (up to and including ridicule), I've decided that the best way is to flood the world with high-quality and stylish code. The recent trend towards publishing significant amounts of source code in books is encouraging. Quintus could have a big effect too by licensing their Prolog library independently of the basic system, for a nominal fee, or even making it freely available, although that's probably too much to hope for... Teach by example, not by abuse! >Arun Lakhotia stan shebs shebs@cs.utah.edu
jha@its63b.ed.ac.uk (J Andrews) (02/15/88)
In article <637@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: | 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.
ok@quintus.UUCP (Richard A. O'Keefe) (02/17/88)
In article <989@its63b.ed.ac.uk>, jha@its63b.ed.ac.uk (J Andrews) writes: > In article <637@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: > 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? > 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 (:-).
pase@ogcvax.UUCP (Douglas M. Pase) (02/21/88)
In article <druhi.2684> kam@druhi.ATT.COM (MorrisseyKA) writes: > >Uniform style is important at all scopes: within a single program, >within a project, or within a company. Differing styles, especially >within a single program, will make it more difficult for others to >understand the program. I strongly disagree with this statement. Many years back I was part of a FORTRAN 77 compiler development team. My job was to test and correct the compiler. The compiler consisted of ~100,000 lines of PL/6 code, written by 8-10 different people. One other person was supposed to do the same as me. 6 of the 10 people were top notch programmers with beautiful coding style, but the styles were completely different. The other 4 programmers varied in skill from good to beginner. When it came right down to it, picking up a routine written in one style and then switching to a different routine written in another style was no problem if both styles were good. (I had to look at everyone's code, so I had *a lot* of opportunity to do just that.) It didn't matter how radically different the two styles were. Problems arose when #1) the style was poor to begin with, or #2) it was not consistently adhered to. Poor style meant things like: too much or too little indentation, indentation schemes which were complicated, failure to use blocks on control structures (e.g. if, while) breaking lines in wierd places, heavy use of goto statements, routines or modules which were too long, excessive global variables, non-descriptive variable names, names which were similar to or easily confused with other names, sparse comments, comments which were english translations of the code they were commenting (e.g. i = i + 1; /* add 1 to i */), etc. When the style was not consistent, it was often for one of several reasons: More than one programmer had worked on the file and subsequent programmers had not been careful to retain the original style, The style was too complicated, and hence confusing even to the author, The programmer had no real concept of style, and simple indented when he "felt like it". >Even arbitrary standards are beneficial. A standard does not need to >be the best. Who can even say what best is? The value of standards is >that they are shared. Standards may be very strict to the point that they are enforced by the compiler (as in Occam), or they may be no more than general guidelines similar to the ones I have given above (but perhaps more complete and precise). I am against the more rigid end of the spectrum. But I also realize that such things may be needed where programmers are more inclined to write amorphous code. I would rather see minimum standards for readibility than have everyone's code look the same. Strict standards would require time to be spent enforcing them (standards which are not enforced are not standards) which might be more productively used elsewhere. >Karen A. Morrissey >1-303-538-4587 >ihnp4!druhi!kam -- Doug Pase -- ...ucbvax!tektronix!ogcvax!pase or pase@cse.ogc.edu (CSNet)
lhe@sics.se (Lars-Henrik Eriksson) (03/08/88)
[ This article was posted 17 Feb 88 14:05:23 GMT but was stopped on a machine ] In article <54200003@hplabsb.UUCP> mohan@hplabsb.UUCP (Joseph Mohan) writes: > (Quote from article by O'Keefe omitted) >What wonderful writing! If you ever wrote a book, R O'K, I'd buy it >with my eyes closed. The best writing I have ever seen on any bboard! I agree! Marvellous! (I also agree with the other things O'Keefe wrote.) Lars-Henrik Eriksson Internet: lhe@sics.se Swedish Institute of Computer Science Phone (intn'l): +46 8 752 15 09 Box 1263 Telefon (nat'l): 08 - 752 15 09 S-164 28 KISTA, SWEDEN