chuck@felix.UUCP (08/17/87)
In article <18100001@infbs.UUCP> neitzel@infbs.UUCP writes: > [summary and previous discussion about using microcomputers and the > kind of turnaround involved.] >But there is nothing bad about waiting for something! >In fact it gives you a good opportunity for talks with all other >students waiting for printouts, too. Students that work on the same >problem. > [More detailed discussion about this topic] In addition to the loss of communication between people that accompanies the individual use of microcomputers, I believe the more damaging loss is in programmer discipline. By this, I refer to the ease with which one can reprocess a program, and the resulting trap one can fall into. Because of this speed, many programmers tend to let the compiler or interpreter do their debugging for them. Less effort is put into understanding the problems which are occurring. Superficial changes are made to programs which are then reprocessed to check out the modifications. The net effect can easily become counterproductive. Yes, machines are fast and getting faster. Yes, compilers are good and getting better. But this does not substitute for understanding the problems you are dealing with. You may be able to change your program 15 (or more) times, recompile and run it during a day. If you are just using a shotgun approach, you really are not any further ahead than you would have been if you just sat at your desk and read the code. Lets go back 15 years. Before you submitted your 100 line FORTRAN program to your university batch processor, you spent a great deal of time ensuring that it was correct. After all, it could normally take you three hours to get the results. You didn't want to waste that time with a syntax error, or a transposition of a logic test. You spent part of that time desk checking your code for correctness. Modern language processors may remove the drudgery involved in ensuring correct syntax, but they won't ensure your logic is correct. If you just continually make changes you don't understand to a program, you may indeed finally get it right. The temptation to do this is very high since it is so easy to re-process the program. But that may not be the best way to solve the problem.
neitzel@infbs.UUCP (08/23/87)
[Warning: LONG! About 100 lines, and not a single one was eaten by th..@%^$#] Let me vote in favour of the fast programming environments for CS education. The recent notes pointed the dilemma of "quick & dirty vs. concise & sleepy" out well enough. To summarize with George W. Leach's words: > And from my experiences as an undergraduate dealing with long delays > while waiting for my printout from a line printer, or punching hollerith > cards I feel that today's students are lucky! ^^^^^ > Today my students have Turbo Pascal, which not only detects > errors, but takes them into the editor at the appropriate place in the > code where the syntax error occured. My they are spoiled! ^^^^^^^ About the "benefits of slow environments": /***** infbs:comp.edu / felix!chuck / 6:34 pm Aug 17, 1987*/ > > Lets go back 15 years. Before you submitted your 100 line FORTRAN > program to your university batch processor, you spent a great deal of > time ensuring that it was correct. [...] Hmmm... six years ago the students here had still to work under similiar circumstances. Most importantly, computer usage was severely budgeted. So each compilation run was a penalty for the student. Until today the undergraduates learn their first programming language on an IBM mainframe, and I can still remember the days, when it took 20 (yes, twenty!) minutes just to login. But I don't think the "compilation penalty" makes the students prepare their programs significantly more carfully. We tinkered with our programs until they finally ran, too. And when that took half the night, then we thought: ok, that's how life is. In one sense, though, a lot of students made sure that their programs would run as soon as possible: They avoided all things, that were new, looked "complicated" and were yet not (by other people) proven to work. "What funny thing is this? A PARAMETER ??? Hmmm... a global variable will do it, too. And I know global variables. Reliable, working, compile-able global variables." For learning a language, you can't play enough with it. That is the reason, why I am arguing for fast environments. [TurboPascal is fine, because it is really 'turbo'; interpreters are generally even better, because you can easy do isolated testing (and you can inspect your program mostly without an extra debugger).] On the mainframe most students couldn't experiment. Experiments like "what happens, if I change this..." are essential for learning. They should not be prevented by slow (or budgeted) environments. > Modern language processors may remove the drudgery involved in > ensuring correct syntax, but they won't ensure your logic is correct. Agreed. But fast environments allow controlled experiments, where the problem can be investigated isolated from the rest. And in fact much better understood. A slow edit-compile cycle was to often the reason, that students tackled many problems in parallel, because they felt, an extra test program for each problem would be luxury. 15 yearse ago is 15 years ago, and now is now. We should continue to debate the education of todays students. The problem of "programming without substantial understanding" is a serious one. And, as pointed out by chuck@felix, todays facilities increase the danger of code- tinkering. But can re-introducing the slow environment solve this problem? I doubt it. The "modern" environment has great influence on the way we program. Think of makefiles, tag lists, sophisticated editors. Should the student learn about these things? Until now, the students here are supposed to learn the programming language and this language only. Every student , who uses something beyond 'login', 'edit', 'compile', 'run' and 'logout', must prepare himself to be called a "hacker". Okay, that is exaggerated. But at least the tendency is right. Undergraduates changing from their learning environment to something like Unix are remarkebly helpless, me thinks. E.g., they don't know how to use a source level debugger. And they aren't willing to learn any things beyond "their program". On the other hand, a college of mine remarked today something like this: "If we gave the students all the zillion brilliant tools we have (or wish to have), that would occupied all their time. They had to learn how to tweak, twiddle and frob with all the knobs and options, and no time were left to learn the language." Doesn't sound to be a wrong position, either. Martin Neitzel neitzel@infbs.uucp ...!mcvax!unido!infbs!neitzel ------------ "Disclaimer": In such a long article, it is possible that some severe errors crept in; Please note: English is _not_ my mother tongue. No flames or offensive statements intended unless explicitly marked as such. Either bear with my spelling, wording and punctuation or correct me by mail. Thank you.
chuck@felix.UUCP (Chuck Vertrees) (08/25/87)
In article <18100002@infbs.UUCP> neitzel@infbs.UUCP writes: >Let me vote in favour of the fast programming environments for CS education. > >> Modern language processors may remove the drudgery involved in >> ensuring correct syntax, but they won't ensure your logic is correct. > >Agreed. But fast environments allow controlled experiments, where the >problem can be investigated isolated from the rest. And in fact much >better understood. A slow edit-compile cycle was to often the reason, >that students tackled many problems in parallel, because they felt, an >extra test program for each problem would be luxury. > >15 years ago is 15 years ago, and now is now. We should continue to >debate the education of todays students. The problem of "programming >without substantial understanding" is a serious one. And, as pointed >out by chuck@felix, todays facilities increase the danger of code- >tinkering. But can re-introducing the slow environment solve this >problem? I doubt it. I was not advocating that we in fact step back 6 or even 15 years by slowing down the teaching environment. What is available today is much superior to the previous environments. My point was to highlight the dangers of "programming without substantial understanding." I know that as I transitioned from older slower environments to those with faster turnaround, I fell into the "tinker" trap myself. I slowly came to the realization that while I was turning around a lot of compiles, I was not making significant progress. I agree that the more you can play with a language, the better you will learn it. To a certain extent, this can be encouraged with speedy environments, but the "programming without substantial understanding" trap still exists. I think that one of the fundamental questions should be how to encourage tinkering for learning's sake while fostering a discipline which encourages you understand the problem fully. In some people, these conditions are synergistic, while in others just the opposite. Perhaps, more emphasis should be spent on promoting good analysis, design and programming skills. The end result should be to produce people who have a solid foundation in these areas. A fast programming environment is but a tool towards this end, albeit a marvelous one.