preston@titan.rice.edu (Preston Briggs) (07/23/90)
This has certainly been an inflammatory little topic, so I'll be brief. Programming isn't computer science. Topics like indentation, mnemonic variable names, implementation language, favorite editor, ... are all programming. Pretty low-level and boring (like asking a good lawyer what brand of pen he uses). Computer science does have "hard" (as in non-fuzzy) topics such as decidability, complexity, and algorithms. This is the basic knowledge Karsh alluded to and is comparable to knowledge of Maxwell's equations or whatever. I expect most schools offer these topics at one level or another. There are also religious issues. For example, I believe in RISC. I believe that a straightforward 1st pass, followed by a few general-purpose optimizations, and global register allocation is the way to build a compiler. These are things I believe despite lack of proof. They were revealed to me by the prophet John Cocke and his disciples Cooper, Kennedy, and Torczon. Religious issues are also taught in school. I think (believe!) they should be. When confronted by hard choices and incomplete information, I'm curious about how others have approached the problem, particularly people with lots of experience. I look to my teachers for guidance. Naturally, this applies to program indentation, languages, et cetera. It's perhaps unfortunate that many people graduate with an inverted view, thinking perhaps that "algorithms" is advanced elective, suitable only for theoreticians and that "real" CS types take assembler instead. -- Preston Briggs looking for the great leap forward preston@titan.rice.edu
drh@romeo.cs.duke.edu (D. Richard Hipp) (07/23/90)
I've never taken an undergraduate computer science course. But as
a computer science ABD (all but dissertation) I have taught a course in
introductory computer programming using Turbo-Pascal. I learned quite
a lot about teaching programming from that experience, which I now wish
to share with the net as my contribution to the recent "indentation"/
"ivory tower" jehad.
I approached my course with what might be termed a "progressive" viewpoint.
Rather than give my students lots of rigid rules about indentation,
commenting, modularization, and so forth, I decided to give a few lectures
on some fuzzy, imprecise ideas of "good style" and "maintainability" and
then let each student program in whatever way their own creativity led.
This stretegy failed, and by the end of the course I had converted to a
programming demogogue, mandating a very specific indentation and commenting
style and prohibiting global variables and subprograms longer than 30 lines.
If I had it all to do over, I would be even more rigid. Here's why:
1. Abuse of global variables: I found that if students are allowed to use
global variables, then they will use them to the exclusion of all else.
This is especially true of students who have had prior exposure to BASIC.
Passionate lectures on the virtues of modularity, information hiding,
and re-entrancy are ignored. The only way I found to get students to
use local variables and subprogram parameters was to forbid the use
of any global variables whatsoever. This decree was meet by loud
complaining but it was quite effective in improving the quality of the
student's programs. (I define quality as a combination of correctness,
speed, and functionality, by the way.)
2. Lack of modularization: Prohibiting global variables requires (in
Pascal) that the students use at least one procedure. Were it not
for my second rule, "No subprogram longer than 30 lines", then many
students would never use more than that single procedure.
3. Random walk indentation: I initially allowed students to use any
"consistant" indentation style. Some students reasoned that no
indentation is consistant, and so every line of their programs began
at the left margin. (This was the popular pick from the BASIC crowd.)
The rest of the class must have assumed that a white noise process is
"consistant" since for these students the left margin looked like the
walk of a drunken sailor and was largely unrelated to the program's
structure. Both styles resulted in the same set of problems:
a. Students were unable to follow their own programming logic.
b. Students spent hours looking for silly errors such as a BEGIN
without a matching END.
c. The instructor nearly went blind trying to read the student's
code.
Only after implementing rigid and uniform indentation rules was I
able to bring some order to the students' programs.
4. Mystery variables: Students would often come to me for help with
programs they could not get to work. After looking over their
(uncommented) code, I would often ask some innocent question like
"What does this variable/procedure/function do?" The typical responce
of the student was "I don't know". After pressing further, I would get
an explanation like "I must have put it there for some reason, but
if forgot what that reason is." My resulting frustration eventually
led to a "comment every variable and subprogram" rule. I refused to
provide help on any program that was not commented. This did not
prevent useless comments such as
var x: integer; (* x is an integer variable *)
but it did help some. Late in the course I began requiring pre-
and post-condition comments on every subprogram. This was a great
idea since it forced the students to actually stop and think about
what they were doing for a change. The improvement in program
quality was immediate and very noticable. Unfortunately, I added this
requirement late in the course, and not all the students had time to
catch on. Next time, pre- and post-conditions will be in my first
lecture.
There are more examples, but these will suffice. I will now attempt to
analyze the problem at a higher level.
Programming well is difficult, especially for novice programmers. In
designing a program, the programmer generally has more than enough to
worry about. Allowing excessive freedom with regard to commenting and
indentation does the programmer no service -- it makes his job harder
by giving him more decisions to make. Rigid rules of style do not
inhibit creativity -- it shifts the creative effort to where it belongs,
into the designing of the program's algorithms and user interface.
A recent wave of postings have flamed computer programming instructors
for their rigid rules of style, claiming that style doesn't matter, and
that the instructors should spend more time on important issues like
functionality. Granted, functionality is much more important than style.
But one must remember that correct indentation is the EASY part of
programming. Someone who is unable to comment and indent a program
according to the instructor's doctrine has a slim chance of succeeding
at the hard part -- making the program work.
Remember when you were learning to drive, and you instructor (dad) made
you keep both hands on the wheel at the 2 and 10 o'clock positions? Do
you still drive that way? Probably not, except in heavy traffic or other
situations which might require a quick response. This is because you are
now comfortable with driving and able to safely do other things with your
hands. Learning to program is analogous. When you first start out, you
need a strict set of rules to keep you out of trouble. After you acquire
some experence and become more confident in your abilites, the rules can
be relaxed somewhat.
'Nuf said.magnus@THEP.LU.SE (Magnus Olsson) (07/23/90)
In article <20955@duke.cs.duke.edu>, drh@cs.duke.edu writes: >I approached my course with what might be termed a "progressive" viewpoint. >Rather than give my students lots of rigid rules about indentation, >commenting, modularization, and so forth, I decided to give a few lectures >on some fuzzy, imprecise ideas of "good style" and "maintainability" and >then let each student program in whatever way their own creativity led. >This stretegy failed, and by the end of the course I had converted to a >programming demogogue, mandating a very specific indentation and commenting >style and prohibiting global variables and subprograms longer than 30 lines. >If I had it all to do over, I would be even more rigid. I think the best summary I've heard of this point of view was given by one of the CS teachers here in Lund: "You have to know the rules to be able to break them" (i.e. in a constructive way). I know the rules of structured programming (from having been forced to follow them); I break them when I think it's necessary to make the program efficient or more easily understandable (using a goto to jump out of a nested loop in Pascal is much simpler than having a lot of flags and extra termination tests, and doesn't make the program any more difficult to understand - on the contrary). I'm surprised at how seldom I have to do it. My own experience as a T.A. is that (beginning) students who aren't forced to "follow the rules" will not follow them - not because they've made an evaluation of the arguments pro/con structured programming and decided that they can write better programs if they ignore the rules (and, believe me, the only good programs produced by beginners tend to be the well-structured ones) but because they *don't understand* what the rules are there for and that they may benefit from using them. They aren't stupid - they won't waste a lot of time learning some stupid rules if they can't see the point in following them. Of course, in an ideal world, students would *first* learn so much about programming that they could write good programs, and decide for themselves if they needed the rules or not, and *then* start programming. However, to be able to decide, you have to have some programming experience, and to get that, you have to program! I think it's better to force people to follow the rules until they are sufficeintly good programmers to see the reasoning behind them. If they then decide that they don't need the rules, well, there's more than one way of skinning a cat, isn't there? Finally, let me just add that of the computer scientist I've met, some are indeed sitting in some sort of ivory tower (at least in dome aspects!) but there are also lots of CS people who are very good programmers and who really care about program efficiency, usability and so on. You just can't generalize the way some people love to do. (I'm not a computer scientist myself). Magnus Olsson | \e+ /_ Dept. of Theoretical Physics | \ Z / q University of Lund, Sweden | >----< Internet: magnus@thep.lu.se | / \===== g Bitnet: THEPMO@SELDC52 | /e- \q
jhl@kira.uucp (John Lawitzke) (07/24/90)
From article <10133@brazos.Rice.edu>, by preston@titan.rice.edu (Preston Briggs): > > This has certainly been an inflammatory little topic, > so I'll be brief. > Lots of other stuff deleted. All well and fine, but this posting and the discussion which will result have nothing to do with the nature of comp.arch move it to comp.edu or elsewhere. -- j |%|John Lawitzke, Dale Computer Corp., R&D |%|UUCP: uunet!mailrus!sharkey!dale1!jhl |%| or: uunet!frith!dale1!jhl Inquiring minds just wondering. |%|Internet: jhl@frith.egr.msu.edu
haynes@ucscc.UCSC.EDU (99700000) (07/24/90)
"Maybe Computer Science should be in the College of Theology..."
R. S. Barton, 1967
haynes@ucscc.ucsc.edu
haynes@ucscc.bitnet
..ucbvax!ucscc!haynes
"Any clod can have the facts, but having opinions is an Art."
Charles McCabe, San Francisco Chronicleian@sibyl.eleceng.ua.OZ (Ian Dall) (07/24/90)
In article <20955@duke.cs.duke.edu> drh@cs.duke.edu writes: >I approached my course with what might be termed a "progressive" viewpoint. >.... >This stretegy failed, and by the end of the course I had converted to a >programming demogogue, mandating a very specific indentation and commenting >style and prohibiting global variables and subprograms longer than 30 lines. >If I had it all to do over, I would be even more rigid. When you learn most skills you do exercises. Often coaches in physical activities will get their charges to exagerate a certain motion in training to improve their style. In a more closely related area, I remember when I first learned algebra we had to write in margin the axiom which allowed us to do each step. Somewhere along the line a tennis player learns that, in a match, it is better to make the shot with his feet in the wrong position than not make the shot at all. And somewhere along the way I learned that the axioms in the proof could normally go unstated. I have no objection to programming *exercises* which have a strict discipline, but they need some "match practice" as well before they are released on the real world. Don't get me wrong, I am all in favour of modular code etc but I have certainly run across some people with little real experience making dogmatic statements about *never* using goto's etc. To that extent, I agree with the thesis that some CS people haven't acquired the right set of priorities. >3. Random walk indentation: I initially allowed students to use any > "consistant" indentation style. Some students reasoned that no > indentation is consistant, and so every line of their programs began > at the left margin. (This was the popular pick from the BASIC crowd.) > The rest of the class must have assumed that a white noise process is > "consistant" since for these students the left margin looked like the > walk of a drunken sailor and was largely unrelated to the program's > structure. Both styles resulted in the same set of problems: > a. Students were unable to follow their own programming logic. > b. Students spent hours looking for silly errors such as a BEGIN > without a matching END. > c. The instructor nearly went blind trying to read the student's > code. > Only after implementing rigid and uniform indentation rules was I > able to bring some order to the students' programs. I think correctly indented programs are great. The trouble is I think it is of only marginal benefit getting the *programmer* to indent the code. If you make a mistake, it can be more misleading than unindented code! I think that these days, auto-indenting editors or seperate programs should be available. I think that emacs c-mode has saved me an enormous amount of time. If you leave off a ';' or have mismatched parenthesis it becomes immediately apparant by the indentation. If *I* had indented it, I would have indented it as I *intended* it to work. That is not to say that getting students to indent by hand mightn't be a useful *exercise*, but I think getting best use out of appropriate tools is an important skill. >Remember when you were learning to drive, and you instructor (dad) made >you keep both hands on the wheel at the 2 and 10 o'clock positions? Do >you still drive that way? Probably not, except in heavy traffic or other >situations which might require a quick response. I agree except that I don't think it is quite a good analogy. Not driving with hands at the 10 to 2 is due lazyness rather than because it is sometimes not the best way (watch any race driver). More importantly, once they have learned the skills, they should be told that they can be more flexible before they finish the course. -- Ian Dall life (n). A sexually transmitted disease which afflicts some people more severely than others.