peterd@opus.cs.mcgill.ca (Peter Deutsch) (03/16/90)
I missed the follow-up by Flint Pellett to my posting on teaching a first assembler, but caught the subsequent posting by Mike Albaugh, so will buy back into this by responding to points made by both. I think the thread could/should be expanded to a more general discussion about soft-eng training in general. If you find the assembler stuff boring, skip to the end where I throw in another 2 cents worth. For a taste of what I feel, I'd say there is merit in a first software engineering course that contains (at least in part) a large project written in assembler. See below for more. ------------------------------------------------------------ In article <1003@dms.UUCP>, albaugh@dms.UUCP (Mike Albaugh) writes: > From article <891@gistdev.gist.com>, by flint@gistdev.gist.com (Flint Pellett): >> peterd@opus.cs.mcgill.ca (Peter Deutsch) writes: >> >>>BTW, the assembler I teach is the PDP-11 assembler. We >>>don't have any PDP-11's any more, so we use a simulator >>>... >> To each his own I suppose, but I think you're doing your >> students a dis-service. Learning a dead language just because >> that will help you to learn a modern one is only a reasonable >> path if it will take you less time to both learn the dead one and >> then the modern one than it would take to start with the modern >> one and only learn it. I'm afraid I have to disagree (obviously! :-) but it's because you appear to misunderstand my motives. The reason I teach the "dead langauge" is _NOT_ so I can then teach the modern one. I teach it because it better illustrates the general principles I am trying to communicate, without unnecessary special casing, verbose explanations and convoluted justifications. (eg, I don't want my students asking: "So why do we NEED segment registers? Why do we HAVE to use the BX register, I'd rather use AX. Well, can't I copy that from here to there? Oh, what's an ES register?" No prizes for recognizing this incredibly widespread CPU, so popular in industry). And why teach assembler? Not so they can work as programmers, but so students better understand the workings of their machine and their programs. More on this below. >> . . . . . . . . I doubt this is true. Your students >> are going out into the world with PDP11 on their resumes instead >> of something that might help them in the real world: I wonder >> how many of them will support your position a couple years from >> now? One point of course is, "how many will be hired to program in assembler?" but I also wonder how many would be better served if I'd simply taken over the PC lab, where they wouldn't have the UNIX environment, the network, Usenet, ftp to all those archive sites, real email, talk, electronically distributed, submitted, graded and returned assignments, automatic backup by a professional systems admin staff, and so on. After all, there are all those DOS machines out there... Seriously, someone suggested to me that we convert to 68000 a couple of years ago, but now they're suggesting SPARC. I say "Let's teach them what an Execution Cycle is, what addressing modes are, what is the difference between Harvard and Von Neumann architectures, what is a Bus access (and why is it so expensive), what is the difference between Memory-Mapped and Port-Mapped I/O, what are peripherals, what a compiler does to an Assignment Statement, etc, etc. I _DON'T_ want to spend my too short semester on Segment Registers, Page Zero addressing, how to reboot if you crash the machine and gorf your disk, etc. These are _details_, and not germaine to the point of the course. To be fair, noone actually suggested I use 8088 assembler, but it is certainly a popular chip. The newer Intel chips have done away with much of the problems of the early designs, but that's the whole point. I shouldn't be a slave to fashion. I'm suppose to be teaching principles, and as efficiently (and hopefully enjoyably) as possible. [ And Mike Albaugh wrote: ] > I must strenously disagree. The first computer language > a student learns seems to mold a great deal of the student's > attitude and approach to programming. We may choose to quibble > about the "right" first language on theoretical (or religious :-) > grounds. But we should _never_ to pick one on "resume" grounds. Hear Hear! There exist any number of companies that promise to make you a "Systems Analyst/Programmer in only three short months!" (So is that February, April and June? :-) Presumably there is a reason university degrees take a little longer? I might also point out that I don't teach them their first language, just their first assembler. A first Computer Science course is a prerequisite and they learn Pascal there. Of course, Pascal is not the point of that course, either. It's learned so they can implement the ideas presented in class. They are later expected to "pick up" other languages as needed, with only some help from instructors. > It can take a very long time for an employer to "de-train" > an employee in those areas where blind-spots (and unreasoning > phobias) have been induced by commercially expedient training. Or to "fill in the gaps" left by limited exposure to a narrow view of the world. I usually try to spend one lecture on another CPU architecture, just to stress the common ground and areas for legitimate architectural differences. I do _NOT_ try to teach it all in one course. Actually, it's probably time to swing this back into the area of software engineering, so I'll take a stab at it. I have seen earlier discussions on the net (I think it was in comp.edu) along the lines of "but why even teach assembler? Most students wont every use it!" I happen to think assembler in the second semester is a great idea, because it is time to "demystify" the computer and convince students that they really do control EVERYTHING the machine does. _Someone_ wrote the code to write to the disk, get the date and play hack. Once they believe that, you can start to show them how to do it themselves. Now, soft-eng? I would suggest that it is possible to bang on a 500 line Pascal program, and perhaps with sufficient patience, help and luck get it not to crash during the demo for the TA. I would maintain that if you wrote a 500 line assembler program that was not designed along proper engineering principles (eg. structure your tasks, eliminate side-effects, document your code, develop and debug in a methodical manner, changing no more than a single variable in the debugging process to avoid masking problems, etc) then your program just can't be made to work. I have seen too many examples where it wasn't and it didn't. Note, I am NOT advocating that we develop large commercial projects in assembler, but that exposure to a good sized assembler project is a suitable microcosm for some of the classic problems in software engineering for beginners in a first assembler course. I like to think my course serves to "demystify" the computer for novices, gives confidence needed to tackle large projects and, as a bonus serves as a first exposure to some basic software engineering principles. For the record, I structure my programming assignments as a series of progressively more complex specifications, where assignment(n) assumes the availability of assignment(n-1). I deliberately do _NOT_ reveal the purpose of assignment(last) to students until the final specification is released, after the submission of assignment(last-1). Thus students are forced to a) completed each assignment to stay in the running, and b) write each subroutine in a general purpose manner. If you take short-cuts, you will tend to have to reimplement each time. What are the type of projects? Well, one semester students implemented a PDP-11 disassembler (well, a subset), another semester a toy simulator (on the simulator, that threw them a bit) another semester an actual assembler in assembler. I hope each served to make clear the role of the tools they were using in bringing the silicon to a usuable state. How does this work? I would claim it is reasonably successful. I do _NOT_ get a Bell-curve grade distribution, but rather a double-humped curve of A's and D's, weighted towards the A's. Students seem to enjoy the course (which I think actually matters, and not just as a quality of life issue. If you enjoy it, you pay attention, if you pay attention, you tend to learn more) and althought I fail some people each semester, those that pass seem to have "got the point". Anyways, enough about how _I_ do it. I was fortunate to have inherited a course that fits into my own philosophy and which I can teach as I see fit (of course, if I failed 2/3 of a class or got spectacularly bad reviews, that might change! ;-) So what do others think about using such a course as a first exposure to software engineering. And if it is such a bad idea, how _should_ it be done? Enquiring minds want to know.... - peterd
flint@gistdev.gist.com (Flint Pellett) (03/17/90)
I have the impression that more was read into my statement than was stated or intended. I certainly am not against the teaching of assembler, and I'm certainly am not against the teaching of basic concepts: in fact, just the opposite! (Apparently it was me who misread the previous statement, since I've agreed with pretty much everything in the follow-ups.) What I intended to convey is that it is a dis-service to teach a course where the whole intent of the course is to teach "how to program in assembler" and then teach a dead language, or even to teach just one current one. When your intent in your course is to teach basic concepts, then what assembly language you use probably doesn't matter, just make sure you grade your students primarily upon their understanding of those concepts and not on how many syntax errors they had in their programs. I myself had the misfortune to take a course in "Assembly Language Programming" where the instructor's intent was clearly to teach all the quirks and tricks of programming in IBM 360 assembler, and students were graded on that basis: I probably mis-read your motives because of the experience with this other teacher's motivies. (I've yet to write any 360 assembler since then, although I've done a couple years of assembler work. Other courses I've taken that used assembler as a vehicle to teach concepts rather than as the goal itself have been far more useful to me.) I believe the same on non-assembler as well: a course on "Programming Languages" ought not intend to teach you all the details on 3 different languages, (and make 60% of your grade based on whether you can get the 3 programming projects to run) it ought to teach you their concepts, and grade you on your understanding of the concepts behind the languages, in what situtations you should select one language over the other, etc. -- Flint Pellett, Global Information Systems Technology, Inc. 1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165 INTERNET: flint%gistdev@uxc.cso.uiuc.edu UUCP: uunet!gistdev!flint
kca@cbnewsc.ATT.COM (k.c.archie) (03/17/90)
From article <1940@opus.cs.mcgill.ca>, by peterd@opus.cs.mcgill.ca (Peter Deutsch): [ stuff deleted] > designs, but that's the whole point. I shouldn't be a > slave to fashion. I'm suppose to be teaching principles, > and as efficiently (and hopefully enjoyably) as possible. > [ stuff deleted] > There exist any number of companies that > promise to make you a "Systems Analyst/Programmer in only > three short months!" (So is that February, April and June? :-) > Presumably there is a reason university degrees take a > little longer? Right on! I have taught a couple of classes at a local college where many of the students complain that we shouldn't use Pascal because they all use C at work. What I try to teach is programming, not programming in C, Pascal, etc. That is one of the major differences between colleges and vocational schools. > [stuff deleted] > Note, I am NOT advocating that we develop large commercial > projects in assembler, but that exposure to a good sized > assembler project is a suitable microcosm for some of the > classic problems in software engineering for beginners in > a first assembler course. I like to think my course > serves to "demystify" the computer for novices, gives > confidence needed to tackle large projects and, as a bonus > serves as a first exposure to some basic software > engineering principles. > > For the record, I structure my programming assignments as > a series of progressively more complex specifications, > where assignment(n) assumes the availability of > assignment(n-1). [stuff deleted] > might change! ;-) So what do others think about using such > a course as a first exposure to software engineering. And > if it is such a bad idea, how _should_ it be done? > > Enquiring minds want to know.... > - peterd My first language was a kind of assembler from a book. The second was BASIC and the third was PDP-11 assembler. One of my most memorable classes as one on computer architecture. The first assignment was to develop code to simulate an and gate. This got built into a half-adder and then a full adder. The next assignment was to incorporate the adder into a micro computer simulator we had to write. Having to simulate the entire processor was a revelation for me. I was strictly a software type, but started to understand the hardware better by the time class was done. The last assignment had us modifying the microprocessor simulator to add new features, new operations, I/O or , in my case, change the instruction format from horizontal to vertical. All this was done in PDP-11 assembler and on cards under RT-11. Why, I remember having to debug programs from the front panel switches. You young people today have life so easy...:-) I completley agree with teaching assembler. It should be a simple architecture like the PDP-11. What you learn from this is not a direct commercial skill but knowledge of how your tools work. By building your own at least once, you know how to evaluate others when you buy them. You learn what you really can and cannot do with a computer. That class was one of the most valuable I had even though I have written no production assembler code since then. It is important to remember in all this that studying software engineering isn't about coding, any more than civil engineering is about riveting I beams together. I am lucky if I spend 20% of my time writing code. These days, most of the code I write is for the classes I take. My work is mostly product design and project control. Well enough rambling, us old codgers (MS in '81) get talking and you can't shut us up. Maybe that's what I like about teaching, the captive audience. **kent Kent Archie kca@cbnewsc.att.com
bwalker@marlin.NOSC.MIL (Beth Walker) (03/17/90)
In article <1940@opus.cs.mcgill.ca>, peterd@opus.cs.mcgill.ca (Peter Deutsch) writes: > I have seen earlier discussions on the net (I think it was > in comp.edu) along the lines of "but why even teach > assembler? [.. stuff deleted} > I would maintain that if you wrote a 500 > line assembler program that was not designed along proper > engineering principles (eg. structure your tasks, > eliminate side-effects, document your code, develop and > debug in a methodical manner, changing no more than a > single variable in the debugging process to avoid masking > problems, etc) then your program just can't be made to > work. I have seen too many examples where it wasn't and it > didn't. [ .. deleted text ] > I like to think my course > serves to "demystify" the computer for novices, gives > confidence needed to tackle large projects and, as a bonus > serves as a first exposure to some basic software > engineering principles. I tend to agree with Peter. I thought I would give a perspective from different point of view, as my background in CS is perhaps not typical. I am employed full-time, working in CS/SE, am currently working on a Masters in CS, and have a BS in Zoology. My 'undergrad' CS experience was all on-the-job. My very first assignment was to optimize (by hand) the assember output of an executive program written in LISP. The assembler was a home-grown, written for a bit-slice stack machine developed in house. My second assignment was developing a screen-oriented editor in Z-80 assembler. I had the good fortune to work for people that insisted on a structured approach to coding... one entrance, one exit, etc. I got a very good grounding in both assembler language, debugging skills, team development, etc. Unfortunately, not all schools appear to stress the Software Engineering aspects of programming in the introductory courses. When I went back to school for my Masters, I found that most of the students had very poor skills in designing and debugging programs. In one class (upper division), there was a team project to build an assembler. My two team members had only a vague idea of what an assembler did, and what its output was supposed to be. Not having taken the school's prerec assembler course myself, I can't say how it was structured. However, undergrad courses at that school typically used toy programs for lab assignments, and had very little to say about how programs should be organized. I do know that virtually all undergrads dreaded having to take the assembler course...
madd@world.std.com (jim frost) (03/17/90)
peterd@opus.cs.mcgill.ca (Peter Deutsch) writes: >There exist any number of companies that >promise to make you a "Systems Analyst/Programmer in only >three short months!" (So is that February, April and June? :-) >Presumably there is a reason university degrees take a >little longer? Red tape? ;-) Seriously, I've wondered what must be on the minds of the people that pay for those courses. How can you become a competitive programmer -- starting from scratch with no previous experience -- in seven weeks? I just don't see it happening, even though the ads around here claim better than 90% placement. jim frost saber software jimf@saber.com
gday@digigw.lab.digital.co.jp (Gordon Day) (03/20/90)
In article <1940@opus.cs.mcgill.ca>, peterd@opus.cs.mcgill.ca (Peter Deutsch) writes: [ an extremely long, but worthwhile set of observations removed] > So what do others think about using such > a course as a first exposure to software engineering. And > if it is such a bad idea, how _should_ it be done? > > Enquiring minds want to know.... > Well, I'm not sure about the benefit to the understanding of software engineering concepts of the type of course you describe (I'm one of the OOPS crowd =:-)), unless we also assume that a clear understanding of the Von Neumann architecture benefits the student as a base for other concepts in the future (e.g. recursion, task switching, etc. (yes, I know, these are applications, not S.E. per se)). I am a little concerned about your comment about the 500 line assembly program. In my experience, carefull design in assembler code might get you partway there, but debugging (A REAL TIME WASTER FOR STUDENTS!!) occupies most of the students time. Now, you may have an effective debugging setup for them, in which case it's not so bad, but if we are talking about S.E., isn't assembly teaching students the nasty things as well? global data space, zero security, "just stuff a jmp in there, son", etc. I don't necessarily disagree with you, but please define the area of S.E. you are addressing. Now on to the interesting bit. I am a recent Univ. grad in Computer Science and in my second year I had a course just as you describe. We used PDP-8 assembler running on a simulator and our big project (in Pascal, NOT a.lang.) was to write the assembler for a subset of the language (you can imagine how many instructions were left...). We worked up from handcoding in octal to assembly language, culminating in designing an assembler. This is one of 3 CS courses I took out of about 20 that still stays in my mind as one of the most enjoyable and valuable in University. I don't really list PDP-8 on my resume, but then who really needs to list assembly on a resume now? However, given the background of the course I took I easily learned 68000 and 8088 in a very short time. My understanding of it all "really works" did _really_ help in my later O/S courses and in my understanding the underlying stack operations in C (very necessary to really master the language, IMHO). One qualification however, I learned my languages in the following order: BASIC, Pascal, PL/1, _then_ assembly. I strongly feel that the first (or even second) course a student hits should NOT be assembler. It just ain't friendly, folks. gday@digital.co.jp%uunet.uu.net (Japan's not so bad, mate) =:!