Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!mcvax!unido!infbs!neitzel From: neitzel@infbs.UUCP Newsgroups: comp.edu Subject: Re: Microcomputers and Productivity - (nf) Message-ID: <18100002@infbs.UUCP> Date: Sat, 22-Aug-87 18:57:00 EDT Article-I.D.: infbs.18100002 Posted: Sat Aug 22 18:57:00 1987 Date-Received: Tue, 25-Aug-87 01:29:57 EDT References: <5715@felix.UUCP> Lines: 104 Nf-ID: #R:felix:-571500:infbs:18100002:000:4881 Nf-From: infbs!neitzel Aug 22 23:57:00 1987 [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.