john@nmt.edu (John Shipman) (07/12/90)
+-- | I went to a highly rated (top 5) university, yet all of the real | fundamentals were only found in electives. It really surprised me | that you could get a BSCS without learning about compilers or operating | systems. And more than just a few students missed these fundamentals. +-- Is this generally true? Nevin Liber (nevin@igloo.scum.com) wrote the above in misc.jobs.contract, on a thread about whether a college degree is worthwhile. I cross-posted to comp.edu because I'd like to know what is required elsewhere. At New Mexico Tech, nobody gets a BS in CS without going through both the compiler class and the OS class; it's been this way for twenty years. And these aren't just lecture classes, either. Every student implements a whole compiler and a whole operating system from scratch, working in a team with one or two other students. -- John Shipman/Computer Science Department/New Mexico Tech, Socorro, NM 87801 (505)835-5301; john@jupiter.nmt.edu
kitten@wheaties.ai.mit.edu (Patrick Juola) (07/12/90)
In article <1990Jul11.233006.17884@nmt.edu> john@nmt.edu (John Shipman) writes: >+-- (nevin@igloo.scum.com) >| I went to a highly rated (top 5) university, yet all of the real >| fundamentals were only found in electives. It really surprised me >| that you could get a BSCS without learning about compilers or operating >| systems. And more than just a few students missed these fundamentals. >+-- >Is this generally true? > >At New Mexico Tech, nobody gets a BS in CS without going >through both the compiler class and the OS class Well, at Johns Hopkins U *when I attended (1984-1987)* there was a joint EE/CS department. I managed to graduate without having taken either compilers or OS. My understanding is that the degree requirements for the new CS program are somewhat stricter.... I also don't consider myself particularly damaged by failure to take the OS or compiler classes. The textbooks and source code are out there; I've used them to teach myself compiler theory. In my ideal universe, computer science would be taught as a branch of the math department and everyone would know up to and including topology by the time they left.... - kitten Patrick Juola kitten@ai.mit.edu juola@boulder.colorado.edu
dlt@lando.la.locus.com (Dan Taylor) (07/14/90)
In article <1990Jul11.233006.17884@nmt.edu> john@nmt.edu (John Shipman) writes: >+-- >| I went to a highly rated (top 5) university, yet all of the real >| fundamentals were only found in electives. It really surprised me >| that you could get a BSCS without learning about compilers or operating >| systems. And more than just a few students missed these fundamentals. >+-- > >Is this generally true? Nevin Liber (nevin@igloo.scum.com) >wrote the above in misc.jobs.contract, on a thread about >whether a college degree is worthwhile. I cross-posted to >comp.edu because I'd like to know what is required >elsewhere. > >At New Mexico Tech, nobody gets a BS in CS without going >through both the compiler class and the OS class; it's been >this way for twenty years. And these aren't just lecture >classes, either. Every student implements a whole compiler >and a whole operating system from scratch, working in a team >with one or two other students. >-- >John Shipman/Computer Science Department/New Mexico Tech, Socorro, NM 87801 >(505)835-5301; john@jupiter.nmt.edu I'm very aware that is IS true. I have interviewed several prospective employees, with degrees, that have NEVER had exposure to operating systems, computer architectures (much less the associated assembly languages), compilers, or any language that is commonly used in a production environment. Several of these were from the University of California at Irvine. Please note the location, other UC campuses may have different requirements. This is often the result of a clique running the CS department, that is heavily involved in AI, or some other heavily-researched, but not yet in common use, branch of CS. As an aside, for the edu folks, CS is not the only descipline with this problem. UCI's English department is equally (in)famous for being narrow-minded. Employers and students need to research the tendencies of the schools in their locale to determine which ones offer courses applicable to their requirements. As John pointed out NM Tech has a more "real-world" approach. Cal Poly is similar. Any others to offer? Dan Taylor * dlt@locus.com * Locus Computing Corp is in no way responsible for * * my statements. Complain to me.
jfh@rpp386.cactus.org (John F. Haugh II) (07/16/90)
In article <1990Jul11.233006.17884@nmt.edu> john@nmt.edu (John Shipman) writes: >At New Mexico Tech, nobody gets a BS in CS without going >through both the compiler class and the OS class; it's been >this way for twenty years. And these aren't just lecture >classes, either. Every student implements a whole compiler >and a whole operating system from scratch, working in a team >with one or two other students. At The University of New Orleans everyone was required to take a theory course in languages, operating systems and so on, but there were few, if any, courses where students were required to actually write useful code. A suggestion to one of my professors to implement a PL/1 compiler as a project for a special studies course was met with incredible disinterest. Many universities that I am aware of take a dim view at students working together on large projects. The fear being that the students would cheat or slack off. The only course I had which produced something "useful" was an advanced O/S course taught by Jim "Nothead" Thomas. The course was excellent from a learning experience, but a dismal failure as the O/S we wrote refused to do much of anything. Jim Thomas can be found someplace in New Mexico [ UNM I think ... ] working on Yet Another Degree. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org Proud Pilot of RS/6000 Serial #1472
greg@uts.amdahl.com (Greg Bullough) (07/17/90)
In article <18454@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: >In article <1990Jul11.233006.17884@nmt.edu> john@nmt.edu (John Shipman) writes: >> Every student implements a whole compiler >>and a whole operating system from scratch, working in a team >>with one or two other students. > >At The University of New Orleans everyone was required to take >a theory course in languages, operating systems and so on... At Forkover University, every student has to build his/her own system from scratch. They have to actually mine and process the silicon themselves. Then they design the circuits, do the layout work, produce the masks, and make the chips. Then it's on to the microscopes, to wire 'em into dual-inline packages. That done, they have to lay out the printed circuit boards, etch them, and solder the chips in. Of course, that includes the positive and negative power supplies of various voltages. Where the greatest number of students flunk out, not surprisingly, is in the machine shop. Turning those bearings for the hard disks is pretty fine work. Well, once they've got that done, they're ready for their first OS course. That's always taken during the Winter term, so they have to walk the mile or so from the dorms in the snow. Uphill. Both ways. :-) Greg
hawley@icot32.icot.or.jp (David John Hawley) (07/18/90)
In article <790S02pfb89A01@amdahl.uts.amdahl.com> greg@amdahl.uts.amdahl.com (Greg Bullough) writes: >At Forkover University, every student has to build his/her own >system from scratch. They have to actually mine and process the >silicon themselves. Then they design the circuits, do the layout ... One of the more interesting "warm-up" exercises given in my OpSys class was the problem of bringing up your-favourite-dream-system given the stuck-on-a-desert-island-with-a-big-box-of-hardware-and-a-nuclear-power-plant- but-absolutely-no-software. Oh I forgot to say, it was a 'paper' exercise :-) Further optional courses did give you the opportunity of developing bits and pieces of the same.
steve@grian.cps.altadena.ca.us (Steve Mitchell) (07/23/90)
>At New Mexico Tech, nobody gets a BS in CS without going >through both the compiler class and the OS class; it's been >this way for twenty years. And these aren't just lecture >classes, either. Every student implements a whole compiler >and a whole operating system from scratch, working in a team >with one or two other students. >-- >John Shipman/Computer Science Department/New Mexico Tech, Socorro, NM 87801 >(505)835-5301; john@jupiter.nmt.edu Most of the CS people I've known have this background, but that does not mean they've learned how to write useful software in general. A few years ago I had a new CS grad working for me, and while she may have been able to write a compiler she had a great deal of trouble writing simple simulation code, even when the algorithms were provided. And forget about having her take a sketch of a solution and derive the algorithm. _VERY_FEW_ programming jobs in industry involve writing compilers or operating systems: most (at least in my experience) involve using computers to solve various real-world problems. It would be much more useful if CS departments turned out grads with general problem solving and programming skills, rather than aiming them at jobs developing system software at computer companies. -- - Steve Mitchell steve@cps.altadena.ca.us grian!steve@elroy.jpl.nasa.gov ames!elroy!grian!steve "God is licht, an in him there is nae mirkness ava." -- 1 John 1:5
matloff@gandalf.Berkeley.EDU (Norman Matloff) (07/24/90)
In article <1990Jul23.060010.20406@grian.cps.altadena.ca.us> steve@grian.cps.altadena.ca.us (Steve Mitchell) writes:
%derive the algorithm. _VERY_FEW_ programming jobs in industry involve
%writing compilers or operating systems: most (at least in my
%experience) involve using computers to solve various real-world
%problems. It would be much more useful if CS departments turned out
%grads with general problem solving and programming skills, rather than
%aiming them at jobs developing system software at computer companies.
This is really shortsighted. Very few people *write* an OS, but almost
everyone *uses* OSs. A good knowledge of how an OS works is essential
to making good use of one.
Normjohn@nmt.edu (John Shipman) (07/24/90)
Steve Mitchell (steve@grian.cps.altadena.ca.us) writes: +-- | _VERY_FEW_ programming jobs in industry involve writing | compilers or operating systems: most (at least in my | experience) involve using computers to solve various real-world | problems. It would be much more useful if CS departments turned out | grads with general problem solving and programming skills, rather than | aiming them at jobs developing system software at computer companies. +-- I agree with you, general skills are what we aim for. The point of requiring a large compiler project and a large op sys project here is not simply to try train people for compiler and op sys jobs, however. There is a tendency for new programmers to think that once they have written a 200-line program, they understand how to program. But while it is possible to get 200 lines of ``spaghetti code'' working, such bad habits will be a real obstacle to bringing up a 2,000-line program, not to mention a 20,000-line program. In my opinion, much of the value of these large projects is in getting people used to programming-in-the-large. Simply assigning projects in compilers or operating systems is not enough; as educators, I feel it is important to use these projects as vehicles for convincing people of the need for clarity, modularity and top-down design. -- John Shipman/Computer Science Department/New Mexico Tech/Socorro, NM 87801 (505)835-5301; john@jupiter.nmt.edu
bzs@world.std.com (Barry Shein) (07/24/90)
From: steve@grian.cps.altadena.ca.us (Steve Mitchell) >_VERY_FEW_ programming jobs in industry involve >writing compilers or operating systems: most (at least in my >experience) involve using computers to solve various real-world >problems. It would be much more useful if CS departments turned out >grads with general problem solving and programming skills, rather than >aiming them at jobs developing system software at computer companies. The issues of compilers and operating systems are directly relateable to many other problems. Every time you sit down and try to put a little interpreter front-end on your program you're facing a lexical analysis and parsing problem. Some of the more interesting graphics programs (e.g. those used to inexpensively, but realistically, generate foliage) are generated by grammars expressed in BNF's (a compiler topic.) Go ahead, write a little program that verifies and classifies a typed in number as correct integer or float or e-notation etc. It's a parsing problem, or at least very simply solved once you understand such things. Is that really out of the realm of "reality"? As a matter of fact, any time you sit down to do a transformation of F(INPUT)->OUTPUT (kinda rare, huh?) where INPUT can be bounded by a function and the transformation must be rigorous you're basically writing a compiler. Who cares if it's a textual program being input or a signal stream (didja know that some of the better work on automatic EKG analysis used parsing approaches to the problem?) or whatever is generating the input. And finite state automatas show up everywhere, not just compilers. Any network protocol is written down as a DFA, no real difference, nothing unique about compilers. Operating systems courses generally teach about concurrency problems (among other things), something that comes up constantly in data bases. There's no difference, at a conceptual level, between OS ideas like critical sections and atomic writes, concurrency control, multi-stage commits etc. And deadly embrace is a critical issue in any shared resource, nothing special about OS's other than that they are careful to bring the issue up. Avoidance, detection, correction, recovery, much more than just OS issues. I think you're very wrong. That you ran into an individual that wasn't very good at what you needed hardly proves the point. You singled out some of the most useful courses in a CS program. -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
conrad@wucs1.wustl.edu (H. Conrad Cunningham) (07/24/90)
In article <37714@ucbvax.BERKELEY.EDU> matloff@heather.ucdavis.edu (Norm Matloff) writes: >In article <1990Jul23.060010.20406@grian.cps.altadena.ca.us> steve@grian.cps.altadena.ca.us (Steve Mitchell) writes: > >%derive the algorithm. _VERY_FEW_ programming jobs in industry involve >%writing compilers or operating systems: most (at least in my >%experience) involve using computers to solve various real-world >%problems. It would be much more useful if CS departments turned out >%grads with general problem solving and programming skills, rather than >%aiming them at jobs developing system software at computer companies. > >This is really shortsighted. Very few people *write* an OS, but almost >everyone *uses* OSs. A good knowledge of how an OS works is essential >to making good use of one. Almost everyone uses compilers, networks, text editors, word processors, database systems, windowing systems, electronic mail, etc., etc. The list grows longer every year. Using the argument above we should have a required course on every piece of technology that we use. That's ridiculous and "really shortsighted"! I will, of course, agree that computer science graduates need a sophisticated working knowledge of the major pieces of technology that they use. But that should not require our CS curricula to read like an inventory of the currently important technological artifacts. CS curricula should be focussed on principles rather than specific technologies. Emphasis should be given to concepts which cut across several areas of technology, instead of arbitrarily breaking CS into many technology-oriented subfields. Instead of core a course on "operating systems" why not a course on "concurrent programming". Such a course could unify important concurrency-related concepts drawn from operating systems, programming languages, database systems, networks, algorithmics, computer architecture, computation theory, etc. Couldn't such a course be more useful as well as conceptually cleaner. -Conrad ------------------------------------------------------------------------------- H. Conrad Cunningham | Title: Assistant Professor Dept. of Computer & Info. Science | Telephone: (601) 232-5358 Fax: 232-7010 The University of Mississippi | Internet: cunningham@cs.olemiss.edu 302 Weir Hall |-------------------------------------------- University, MS 38677 | Home: Rt. 1, Box 81, Oxford, MS 38655 ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- Dr. H. Conrad Cunningham | Title: Assistant Professor Dept. of Computer & Info. Science | Telephone: (601) 232-5358 Fax: 232-7010 The University of Mississippi | Internet: cunningham@cs.olemiss.edu
amanda@mermaid.intercon.com (Amanda Walker) (07/25/90)
In article <BZS.90Jul23214608@world.std.com>, bzs@world.std.com (Barry Shein) writes: > The issues of compilers and operating systems are directly relateable > to many other problems. Indeed. I'd say that the most useful skills I brought to the commercial world were ones that many people classify as "theoretical," including: - Automata theory - Code optimization techniques (since most commercial compilers couldn't optimize their way out of a paper bag) - Algorithms and analysis of their behavior over the time domain - Concurrency issues - Denotational and axiomatic semantics and, most importantly, - A tendency to read CS theory books and journals for fun This kind of broad background can be extremely useful, even in "boring" applications. I once worked with someone who didn't know that different sorting algorithms had different performance characteristics--he ended up using an insertion sort on a several-megabyte database, and it ended up taking 11 hours per run :-). He had an excellent handle on the mechanics of coding, but he didn't have the conceptual background to apply it as effectively as he could. That particular experience seemed to make an impression, though :-), and I have a feeling he pays more attention to "theoretical" issues these days... -- Amanda Walker <amanda@intercon.com> InterCon Systems Corporation
matloff@winnie.Berkeley.EDU (Norman Matloff) (07/25/90)
In article <1990Jul24.140502.17990@cec1.wustl.edu> conrad@wucs1.wustl.edu (H. Conrad Cunningham) writes: >In article <37714@ucbvax.BERKELEY.EDU> matloff@heather.ucdavis.edu (Norm Matloff) writes: >>In article <1990Jul23.060010.20406@grian.cps.altadena.ca.us> steve@grian.cps.altadena.ca.us (Steve Mitchell) writes: %>%derive the algorithm. _VERY_FEW_ programming jobs in industry involve %>%writing compilers or operating systems: most (at least in my %>%experience) involve using computers to solve various real-world %>%problems. It would be much more useful if CS departments turned out %>%grads with general problem solving and programming skills, rather than %>%aiming them at jobs developing system software at computer companies. >>This is really shortsighted. Very few people *write* an OS, but almost >>everyone *uses* OSs. A good knowledge of how an OS works is essential >>to making good use of one. ^Almost everyone uses compilers, networks, text editors, word ^processors, database systems, windowing systems, electronic mail, etc., etc. ^The list grows longer every year. Using the argument above we should ^have a required course on every piece of technology that we use. Nope. Those are different. When I said that people "use" OSs above, I meant that their programs make calls to OS services (either directly, or via the compiler inserting code to do so). That is why people need to know what an OS does -- so that they can make good use of those services. By contrast, rather few people write programs to call on the "services" of a word processor. :-) >should not require our CS curricula to read like an inventory of the >currently important technological artifacts. An OS is not a "technological artifact." As I said, almost every program (except for "embedded applications") makes OS calls. I didn't say that the students should become proficient at a particular OS, by the way. Just general principles, though references should be made to specific systems so as to make the concepts concrete. And those general OS principles *are* general -- they do apply to many of those applications you mention. >Instead of core a course on "operating >systems" why not a course on "concurrent programming". There's a lot more to OS than concurrency. BTW, why have a CS major at all? I'm not being snide here. If you really feel that universities should not be "technology schools" (which I agree), why not go all the way, and not have a CS major at all? Let the companies themselves provide training courses. Norm
rick@hanauma.stanford.edu (Richard Ottolini) (07/25/90)
In article <37743@ucbvax.BERKELEY.EDU> matloff@heather.ucdavis.edu (Norm Matloff) writes: >BTW, why have a CS major at all? I'm not being snide here. If you >really feel that universities should not be "technology schools" >(which I agree), why not go all the way, and not have a CS major at >all? Let the companies themselves provide training courses. Stanford and MIT agree with that. MIT only added a CS major in the 1980s and Stanford still doesn't have an undergraduate degree. Programming was considered a vocational skill better learned before college. Both universities do offer graduate degrees on the more theoretical side. ( CS does not have a monopoly on lopsidedness. I've met "electrical engineers" who've never soldered together a circuit and geophysicists who could tell the difference between limestone and sandstone. Excess emphasis on theory and specialization. )
conrad@wucs1.wustl.edu (H. Conrad Cunningham) (07/26/90)
In article <37743@ucbvax.BERKELEY.EDU> matloff@heather.ucdavis.edu (Norm Matloff) writes: >In article <1990Jul24.140502.17990@cec1.wustl.edu> conrad@wucs1.wustl.edu (H. Conrad Cunningham) writes: >An OS is not a "technological artifact." As I said, almost every >program (except for "embedded applications") makes OS calls. I didn't >say that the students should become proficient at a particular OS, by >the way. Just general principles, though references should be made to >specific systems so as to make the concepts concrete. > >And those general OS principles *are* general -- they do apply to >many of those applications you mention. I do not deny the importance of the practical side of computer science education -- either for those students who go into industry or for those who go directly to graduate school. "Book learnin'" needs to be supplemented by some "down-to-earth" experience for the concepts to be fully appreciated. Also it is unnecessarily elitist to ignore the reality that CS graduates need to get jobs. Neither do I deny the importance of a working knowledge of operating systems. (I have made my living for many more years as a "systems programmer" than as a teacher/researcher.) But I could probably make an equally strong case for the importance of the study of programming language design. Perhaps others could argue strongly for their pet technologies or subfields. CS programs need to be organized around the significant concepts of computing (whatever those may be). Case studies, laboratory exercises, individual/group projects, co-op work experiences, etc., should illustrate and provide practical experience in use of these concepts. My primary complaint against the current approach is the unnecessary fragmentation of CS into subfields organized around technologies. We need more computing generalists, not more specialists in arcane subfields who can't talk to each other or can't recognize the same problem when it appears in different trappings. For several years I worked in the aerospace industry. I often was involved in interviewing new CS graduates. We wanted to hire people for "software engineering" positions to design real-time embedded control systems for aircraft and support tools needed to assist in this work. I didn't expect to find many with experience or specific knowledge of our applications, but I hoped to find open-minded professionals who could apply a strong general knowledge of computing to challenging applications. Unfortunately, many of the stronger grads that I saw were only interested in writing operating systems or compilers or in being "knowledge engineers". Many seemed to feel that you couldn't be a real computer scientist unless you were involved in such activity. The weaker grads I saw were little more than Pascal, Cobol, C, or Pascal hackers. > >> Instead of core a course on "operating systems" why not a course on >>"concurrent programming". > >There's a lot more to OS than concurrency. > I agree and didn't mean to imply that. Perhaps the course should be entitled "control programming" or "coordinated computation". The focus should be on the process of developing such programs, not on the products themselves (e.g., on an operating system, programming language runtime, robot control system, etc.). Perhaps the actual content would not be much different from what you have in mind for an operating systems course. >BTW, why have a CS major at all? Before we answer this question perhaps we should define what CS is. ... Some people would argue that the whole idea of a "major" or of a "field" is wrong-headed--that it introduces an arbitrary and unhealthy compartmentalization of knowledge. -- Conrad Cunningham, University of Mississippi CIS Dept.
dgil@pa.reuter.COM (Dave Gillett) (07/29/90)
In <1990Jul24.140502.17990@cec1.wustl.edu> conrad@wucs1.wustl.edu (H. Conrad Cunningham) writes: >CS curricula should be focussed on principles rather than specific >technologies. Emphasis should be given to concepts which cut across >several areas of technology, instead of arbitrarily breaking CS into >many technology-oriented subfields. Instead of core a course on "operating >systems" why not a course on "concurrent programming". Such a course >could unify important concurrency-related concepts drawn from >operating systems, programming languages, database systems, networks, >algorithmics, computer architecture, computation theory, etc. >Couldn't such a course be more useful as well as conceptually cleaner. Hear, hear! The CS grads I've known who "didn't work out" in professional employment had taken all the courses, but didn't seem to have abstracted the concepts, and so couldn't see how to apply them to the job at hand. On the other hand, it's amazing how many people manage to get a CS degree without any clear understanding of how memory, registers, and pointers interact at a practical level. I hesitate to call such people "professional programmers", but when that's what they get paid for and they have CS degrees, how's an employer supposed to tell the difference? Dave
windley@ucdavis.edu (Phil Windley) (07/30/90)
In article <279@saxony.pa.reuter.COM> dgil@pa.reuter.COM (Dave Gillett) writes:
Hear, hear! The CS grads I've known who "didn't work out" in professional
employment had taken all the courses, but didn't seem to have abstracted the
concepts, and so couldn't see how to apply them to the job at hand.
Having taught introductory classes for freshmen for several years, I can
testify that its much easier to NOT teach abstraction. I did and it cost
me a lot of office hours. Most of the students were not at all comfortable
with abstraction to any degree (these werer people who had, for the most
part, tested out of at least one calculus class). Any time I got abstract,
I had an office full of students wailing and crying about how this was "so
hard!"
I'll continue to teach abstraction because I think its one of the core
principles of the field, but I can see why some introductory courses are
simple "please program a blackjack game" kinds of programming classes.
--
Phil Windley | windley@iris.ucdavis.edu
Robotics Research Lab | ucbvax!ucdavis!iris!windley
University of California, Davis |