rcj@burl.UUCP (Curtis Jackson) (03/09/86)
craig@comp.lancs.ac.uk (Craig Wylie) writes: >The creation of net.csr (I'm open to suggestions about the name) I see no reason for the creation of a new group for this purpose; net.cse readers will invariably want to read about issues affecting computer science types and all we'll wind up with is every article in net.csr being cross-posted to net.cse as well. Sorry, Craig; you'll have to count this as my 'no' vote. SIDE NOTE: This proposal, even if accepted here, should go up for discussion in net.news.group before the group is created -- net etiquette/protocol and all that rot. If you get the votes for the group and don't ever discuss it in net.news.group before creating it there is a good chance it'll go the way of net.bizarre and other "maverick" groups in a hurry. ----------------------------------------------------------------------------- doug@terak.UUCP (Doug Pardee) writes: >are two different things. (Oh, by the way, this implies that I believe >that a CS degree is not particularly useful for a programmer.) I have found my CS degree to be infinitely useful, and I are a programmer too. Most of the courses you listed that you found useless to programmers are, I agree, useless to *most* programmers. But my degree was in intensely hands-on, user-application style degree -- it was very oriented towards programming as opposed to being seated high in the ivory tower of computer science. There was plenty of computer science theory, too, but almost always with examples of how it could be used in the real world. ----------------------------------------------------------------------------- garys@bunker.UUCP (Gary M. Samuelson) writes: >But requiring one comment per line at times implies such non-informative >comments. For example, with a Z80 it takes three instructions to determine >if a pointer is null (LD A,H; OR L; JP Z,label;) -- should each of these >instructions have a separate comment? I think not. Please remember that these are beginning assembly-language coders in their first assembler class. The one-comment-per-line requirement had ulterior motives -- it is too easy for someone to say, "Hey, Joe, how do I check if a pointer is null?" and Joe provides the following three lines of code, which are blindly copied because the someone is in a hurry. If each line is commented, however, at least the someone in question is more likely to look at the thing and say, "So that's how you do it." Also, the professor's bark was worse than his bite -- if you did something like the above earlier in a program or even in a previous program, then had 3 similar lines with only one comment saying, "check for null pointer", he wouldn't care -- he'd encourage you as long as he knew that *you* knew what you were doing and that someone else reading your code could figure it out. >(Pet peeve: Many people seem to think that assembly language is >inherently unreadable -- this is nonsense. Good code can be >written in assembly, and bad code can be written in C.) Especially when I write the language and the assembler ;-) (Sorry, couldn't resist a momentary loss of humility -- guess it's time to go look at my broken compiler again to bring me down to earth). ----------------------------------------------------------------------------- jjboritz@watnot.UUCP (Jim Boritz) writes: >I wrote: >>The above not only taught people how to comment meaningfully, it also >>prevented them from putting things in their code that were incredibly >>ugly, non-functional, or downright wrong -- "I don't know what the following >>2 lines of code do, but the program won't work without them." > >I was a tutor for an assembly language course a few months ago. When a >student does not know that part of their code is wrong, what is to prevent >them from putting this wrong piece of code in their programs. True, of course. The point is that most (all?) programmers write, then comment (largely) after. This way the students were forced to think about what they had done an extra time -- during commenting. I saw a lot of people go back and clean up programs during this phase because they got new ideas during commenting or were just downright ashamed of the sloppy way they had done some things. Obviously if they couldn't see the error of their ways during the commenting phase the offending/offensive code would stay in. ----------------------------------------------------------------------------- chen@gitpyr.UUCP (Ray Chen) writes: >I can see billing in a situation where the University is selling >time to outside users. However, then I think the University should >make a decision. Are they running the machine for the students >and faculty, or are they trying to make money from the outside world >with it? Even then they're not out of the woods -- if they decide that they are running the machine for the students and faculty then they have to decide whether or not they are running it just for computer science faculty and computer science students, and if they are running it for the whole campus or some definable subset then is the focus of the machine on teaching students or on providing CPU time for university research projects? ----------------------------------------------------------------------------- crm@duke.UUCP (Charlie Martin) writes: >And when we hire people, we usually read the part of the resume that >goes into personal interests, too. We have to more or less *live* with >these people, and the automata are no fun. > YES YES YES YES! Luckily, our group's members do most of the interviewing and most of the decision-making when it comes to hiring -- our boss feels that since we know the job and we have to live with these people that we should have the majority of the say-so in who we hire. [about the possibility of Certified Programmers]: >Well, I don't really *want* the Gummint involved in this, for various >reasons which resolve to "I just don't trust them." (I've worked for >them a lot, I have reason not to trust them.) Agreed 1000% >The basic point of the article was that there are two styles of >thhought involved, and that being good at one *does not* imply >that one is good at the other. As one who is good at algorithmic >thinking and had to struggle with math, I can certainly attest to it. > >But this does suggest that the curricula for CS may be a little >misplaced: perhaps they are trying to teach horse cavalry drills >to helicopter cavalry? I, too, am much better at algorithmic thinking, which leads me to wonder why so many universities put such a heavy emphasis on exotic mathematics in their CS degree programs. How many people actually use this stuff in day-to-day work life? And I don't mean use formulas and the like, I mean use the concepts that were gleaned solely from a higher-level math course (say, anything past the first 2 semesters of calculus and excluding one good P & S course). We needed to do a divide without a divider in one of our pieces of parellel pipelined microcode that had to be blindingly fast. We picked up a couple of books, and out jumps the Newton-Rafsen (sp?) iteration method, which worked very well. I didn't need a college math course for that, and we're microcoding the arithmetic unit of a signal processor! How many people are doing work that is *that* close to a mathematics application? Any examples (other than already posted) are welcomed! -- The MAD Programmer -- 919-228-3313 (Cornet 291) alias: Curtis Jackson ...![ ihnp4 ulysses cbosgd mgnetp ]!burl!rcj ...![ ihnp4 cbosgd akgua masscomp ]!clyde!rcj