Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!ccplumb From: ccplumb@watnot.UUCP Newsgroups: comp.edu Subject: Re: software engineering Message-ID: <12788@watnot.UUCP> Date: Fri, 3-Apr-87 11:14:18 EST Article-I.D.: watnot.12788 Posted: Fri Apr 3 11:14:18 1987 Date-Received: Sun, 5-Apr-87 00:46:42 EST References: <340@ndsuvax.UUCP> <1986@cwruecmp.UUCP> <4428@utah-cs.UUCP> <5308@mit-eddie.MIT.EDU> <4429@utah-cs.UUCP> Reply-To: ccplumb@watnot.UUCP (Colin Plumb) Organization: U. of Waterloo, Ontario Lines: 73 shebs@utah-cs.UUCP (Stanley Shebs) writes: >Data abstraction seems silly if you believe you can remember all >the details of a program, so students have no motivation for it. One radical >solution might be to de-emphasize writing programs, and require reading them, >starting with the first course. I would be interested in hearing if anyone >has tried making a first- or second-year CS class modify programs that were >much too large for them to have written themselves... Don't forget that any 1st-year class will include a certain number of people who make a hobby of removing (most intricately written, and *completely* undocumented) copy protection from programs. These types are *very* good at remembering details. I've seen many `infinite free men' hacks to commercial games, and these people are adding features to binaries they're not `supposed' to be looking at anyway, without benifit of anyone's data abstraction techniques. >ambar@eddie.MIT.EDU (Jean Marie Diaz) writes: >>The 9th or 10th (depending on the whim of any given term's lecturers) >>problem set is writing a meta-circular evaluator for Scheme. This >>problem set is no joke. You're handed 10 pages of code, and generate >>another 10, easily. > >When I said "large", I meant something over 100 pages of source. If the >students can even *conceive* of writing it themselves, it's not big >enough. The idea is that the students will depend on documentation >and comments and organization to be able to *find* the places to tweak, >let alone change them. This of course presupposes a piece of code >sufficiently well-engineered to unleash on the students... Is 100 pages large enough? I wrote 54 pages of assembler in 2 months' spare time. This was for a VAX, running Unix, neither of which I had used more than a month and a half when I started. (I really ought to finish the thing... it works, but there are some bits which are ungodly ugly. That should bring it up to *at least* a hundred pages.) Speaking as a first-year CS student, I could conceive of writing a Unix kernel. (From what I know of the job, it'd take me years, but I don't think the people who write the things are a higher order of being or anything.) GNU emacs is about where I start to boggle at the size of things. (I could, I think, still write such a thing, but I'd have to learn how to attack the problem first.) >(Has anybody tried TeX sources? The purpose of TeX is probably clearer >than say MINIX, whose nature will probably be somewhat obscure to >freshcritters, despite the documentation. Students could add simple >features to TeX or better yet, whack out something considered useless :-) ) I've always wanted to be able to add format characters to macro parameters, so \def\foo#1{...} would pick up the next indivisible element in the input stream in #1, while \def\foo#d1{...} would pick up the next . #i1 would pick up the next integer, #n1 would pick up the next real number, etc. Perhaps this could be attempted? The parsing routines are already in TeX, thay just need to be put to use. Of course, you can always add Yet Another Feature to GNU emacs. That should be a big enough program for anybody. (Finding a feature that isn't there already could be a challenge, however.) There is also the opposite problem of producing an assignment that some couldn't handle. Remember that, in order to modify TeX, you have to know web, which means both TeX and Pascal, and the gnumacs lisp is essentially undocumented. If you want something really funny to think about, consider that neither TeX nor GNU emacs are big enough to be true tests of software engineering. After all, experience proves that they aren't too big to be written by just one person... -- -Colin Plumb (watmath!watnot!ccplumb) Silly quote: He hit the nose right on the head.