PGOETZ@LOYVAX.BITNET (04/22/88)
>Re: "Granted these courses are enough for some, but not for the best." >No way. Flame On! >Here are a few trivial things... >1. Assembly language with true parameter passing & recursion So why did you wait for a class to learn this? That's your fault. And I'll bet they didn't teach you to read a program from a hex or binary dump. >2. How to write a compiler I've written a compiler and an interpreter on my own. >3. How to prove that a program will terminate; how to prove it is correct. But Turing proved that it's impossible to prove that a program will not terminate. So it's not useful. Besides, nobody applies proofs to real programs. I took that course, too. Saying we can verify programs is like saying SHRDLU proved that computers understand English: it dealt with a toy world. You could in theory verify a large program, but nobody would have the patience to write it. I'll believe it when I see it. >1. How to write timing-critical code like RWTS If you cracked programs & got into DOS seriously, you would know how. >2. How to write an operating system Our OpSys prof refused to let me take OpSys as a freshman, even though I was writing the operating system for the Gemini robot at the time. What a jerk. I made a long list of things I've done outside school. Fortunately for you, I deleted it. My primary sources are journals, magazines, books, and experimentation. Classes are 1. paced to slow students, and 2. out of touch with reality. Language classes are useless. A language/hardware survey might be useful. When you start a project, you should be able to choose the machine & the language. Then you learn them. In 3 of 4 computer classes I've taken, the prof didn't grade your program on whether it worked. Rather, he graded it on how well it met his idea of a well-written program. Some people wrote non-functional, non-compilable programs that got better grades than my bug-free, memory & CPU efficient ones. Once I was downgraded because I built error-correction into a program - "It wasn't in the specs." Often I lost points for using non-approved commands (Gotos, deletes, stack pops, etc.) Professors are all hung up on their own programming philosophy ("Globals are evil! Comment every line! Never break out of a loop! Always design top-down/bottom-up/on data flow/on program flow/incrementally/fully!"). The really useful classes are indepedent studies. Especially the ones where you write a program in a language your counselor doesn't know - then he can only criticize the program organization, data structures, & results. Comp sci classes offer only a fraction of what's out there. You are not self-motivated, you are not a hacker, if you restrict yourself to classes. Phil Goetz PGOETZ@LOYVAX.bitnet Disclaimer: If you are a Loyola comp sci professor, this is about all the Loyola comp sci professors except you.
CLAP100@BGUNOS.BITNET (Eran Lachs) (04/22/88)
Every word in Phil Goetz'(PGOETZ@LOYVAX.bitnet) posting is TRUE in regard to comp sci in Israel, too... too bad. Eran Lachs Can you run Ascii on the Orient? eran : clap100@bgunos ------------------------------------ -> Apple // Forever <-
jon@cisunx.UUCP (Jon M. Pearsall) (04/24/88)
>>Here are a few trivial things... >>1. Assembly language with true parameter passing & recursion > So why did you wait for a class to learn this? That's your fault. >And I'll bet they didn't teach you to read a program from a hex or binary dump. Sure they did. Hex anyways. If you're reading binary (the concept's not that hard once you can do it in hex or octal), though, your're living in the 60's. >>2. How to write a compiler > I've written a compiler and an interpreter on my own. Why would you want to go and do something like that? Softball sounds more fun. You *did* get *paid* didn't you? You didn't do this because life had no other fun things to offer you? >>3. How to prove that a program will terminate; how to prove it is correct. > But Turing proved that it's impossible to prove that a program will not >terminate. So it's not useful. > Besides, nobody applies proofs to real programs. I took that course, too. >Saying we can verify programs is like saying SHRDLU proved that computers >understand English: it dealt with a toy world. You could in theory verify a >large program, but nobody would have the patience to write it. I'll believe >it when I see it. I'll pretty much agree with you here. It's pretty useless. But nevertheless, it *is* a part of computer *science* and there are those people who maybe also deal with a lot of mathematics (Comp Sci/Math majors) who might like it or even need it if they are planning to stay in the University Research World. After all, the theory of mathematics didn't end with Newton. People still are doing that stuff. >>1. How to write timing-critical code like RWTS > If you cracked programs & got into DOS seriously, you would know how. Why crack disks when hundreds like you do it for us. I mean, some of us have a history paper due next week, I have to finish my Student Registration System and the Unix machine keeps going down, and my girlfriend is screaming "neglect!". We've got better things to do with our free time. Life's short and pretty soon all you've got is a bad back and you still can't find that darn dangling pointer. >>2. How to write an operating system > Our OpSys prof refused to let me take OpSys as a freshman, even though I was >writing the operating system for the Gemini robot at the time. What a jerk. Did you or do you even know what a FIDO queue is? Did you know about scheduling processes? Could you define concurrency within a system? Did you know just what the difference was between a task and a process? How about the various algorithms and methods for memory management and partitioning? > I made a long list of things I've done outside school. Fortunately for you, >I deleted it. Yes, I do feel fortunate. > My primary sources are journals, magazines, books, and experimentation. >Classes are 1. paced to slow students, and 2. out of touch with reality. > They're to teach you the core of ideas in computer science that have evolved over the last 30 years. Not the current trends and fads. 30 years from now, sophmores might be writing Mac like interfaces in the C language whereas today they're writing pascal programs that solve chess situations (think what computers could only do a couple of decades ago). They'll teach you the basics. It's up to you and the world you will soon enter to learn what's to be done and can be done with them. If you want a fast paced education go to Computer Tech. > Language classes are useless. A language/hardware survey might be useful. >When you start a project, you should be able to choose the machine & the >language. Then you learn them. Choose the machine you want to use? Tell that to the corporation you're working for who has asked you to design and implement their information system. "Well, we have this VAX 8700 up on the 47th floor for you and the rest of the software team..." "But sir, I'm used to an Amiga system. The instruction set is simpler..." If you're *that* good at programming, then you can make do with whatever system and language you're told to use. They call it "versatility." > In 3 of 4 computer classes I've taken, the prof didn't grade your program on >whether it worked. Rather, he graded it on how well it met his idea of a >well-written program. Some people wrote non-functional, non-compilable programs >that got better grades than my bug-free, memory & CPU efficient ones. Once I >was downgraded because I built error-correction into a program - "It wasn't in >the specs." Often I lost points for using non-approved commands (Gotos, deletes, Yes, in a way it does seem silly, and I guess alot of times it really is. Nevertheless, they're trying to get you to form good habits that you will use later in life. When handed the formal specification for a system and told to implement it, you're to follow what you have in black and white. The system's designers and the future users (the clients) have already decided what it should and should not do. And you have those decisions written out for you. Maybe that extra menu choice you added makes changes to the data files that could make future modifications difficult to implement. 5 years later: "Let's change the system so it does this now..." "Sir, we can't. That extra feature which counts the number of hot babes in the company personel records changes the file to a point where we couldn't do that anymore." "WHAT COUNT OF HOT BABES!!!??" >stack pops,etc.) Professors are all hung up on their own programming philosophy >("Globals are evil! Comment every line!Never break out of a loop! Always design >top-down/bottom-up/on data flow/on program flow/incrementally/fully!"). Once again, they're just preparing you for later. Five people working on the same project can't be jumping where ever they feel like and keep accessing each others data. You might as well start these habits now with these trivial 500 line projects. Of course nothing that I've said matters if your only goal in life is to sit in a back office of some Xenon Advanced Technology Systems (founded 1987, net worth $45,000 and two secretaries, stock at 1.32 and down 3/4) and be all safe and warm where you can hack to your hearts content and write the code for a ROM chip that will drive some goofy printer interface. > The really useful classes are indepedent studies. Especially the ones where >you write a program in a language your counselor doesn't know - then he can >only criticize the program organization, data structures, & results. > Yeah, well if he had the time he'd figure you out. Hackers worry about viruses and whether to use traps or interrupts. Comp Sci people worry about car insurance. -- =-=-=-=-=-=-=-=-=-= Jon Pearsall, University of Pittsburgh =-=-=-=-=-=-=-=-=-= = !pitt!cisunx!jon As the Zorg closes in, Spaceman Spiff = = jon@unix.cis.pittsburgh.edu cooly draws his death ray blaster. = =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=