My post entitled "Apparently computer science at Purdue sucks" is by far the most popular on this blog. Most of the views seem to come from searching for some combination of "Purdue", "computer science", and "sucks". There's a boatload of negativity in the comments and the post itself is over 3 years old, so I thought I'd give a refresh.
Disclaimer: I am no longer an undergrad at Purdue. I'm a grad student now and have experienced the other side of some of the things mentioned in the comments. However, this also means I'm less in touch with what other people are saying about the undergrad CS program. Most of these opinions are my own.
A few years ago, Professor Mathur took the helm as head of the CS department at Purdue. Let me just say to the naysayers that I believe he has taken our department in a very positive direction and that I would have counted myself very lucky to have some of the things that have been introduced under his watch. To name a few:
- Software engineering specialization. This is one of the first things implemented. Having any specialization at all is a giant step forward. This is/was a bit of a mixed blessing because my experience in CS307 (Software Engineering) was not that enjoyable. Nevertheless, the problem is orthogonal to having specializations.
- Five year BS/MS. I definitely would have stayed for this if it had been implemented before I graduated. Unlike many people, I like class. Having an extra year and getting another degree out of it has no downsides to me.
- Track specializations. This is more or less the next step after the software engineering specialization, from what I can see. The first two years are still the standard core courses (CS180, CS182, CS240, CS250, CS251) plus CS252, dubbed "Systems Programming". From there, it branches out into seven possible tracks. This is much more flexible than before, since people can now get by without taking the "dreaded" compilers. To me, this is unfortunate (because I specialize in programming languages), but I can easily understand the reasoning. This also means that, for example, people who are interested in math-intensive CS can do the Foundations of CS track.
- Conversion of CS177 to Python. This wouldn't have affected me, but this change is huge. They seem to be using Mark Guzdial's media computation book. I definitely think this is a step in the right direction compared to previous iterations of the course (Java, and HTML/Javascript). I would love to TA this class so I wouldn't have to worry about people having horrible indentation.
Of course, we're far from a perfect CS department. If we were, people would stop commenting on my blog and I wouldn't have to write this post. Here are some ideas:
- Reintroduce CS381 as a core course. I see some weaknesses with the introduction of tracks in that you can get by without taking CS381 (algorithms). I can understand removing compilers from the core set of classes, but unless CS251 (data structures) is doing substantially more work, I believe this is a big mistake. Sure, it's an elective in these instances, but I don't consider that to be sufficient. Making this class required sacrifices a lot of flexibility, but I find it odd that anybody would be able to get a degree in computer science without an algorithms class.
- Introduce an entrepreneurial track. This may not be reasonable/feasible, but I just thought of it. Perhaps it should be a specialization that goes alongside an existing track, but I think it would be a good idea to foster the minds of business-oriented students. In particular, I think it should really emphasize the blend of CS and business, from web startups to...not web startups. I don't think this quite fits into a management minor, though there may be a bit of overlap.
- Implement course outcomes. I now feel that course standardization is a necessary evil. Engineering has outcomes, which guarantees that any student that passes the class has at least a basic understanding the concepts taught in the class. This would give a more uniform education to all CS students, since professors would need to adhere to the designed curriculum, which therefore guarantees that any CS alum has at least a basic understanding of all of the concepts in all of his/her classes.
- Kill off Solaris labs. Someone I had numerous disagreements with did make a suggestion that I agree with wholeheartedly, and that is that the G040 Solaris lab sucks and should go away. Dealing with the Solaris terminals has very little benefit to anyone, but it seems they still use it consistently in some classes. Personally, I think the Solaris lab in Lawson that has "real" computers should also be converted to a Linux lab. The Solaris lab has always been a source of idiotic quirks that any CS180 UTA has probably dealt with.
- Update hardware. On a similar note, but not completely related to undergrads, I think we're in dire need of a hardware refresh. The machines we get in TA offices still date back to Pentium 4s. When comparing to what kinds of equipment other universities get, it's just embarrassing. Also, our network shares are tiny, which results in frequent e-mails complaining about partitions filling up. I don't understand this at all, in the day and age that terabyte hard drives can be had for under $100 and quad core computers can be had for less than $400.
- Increase flexibility in the new core. More flexibility in the new core would be a big step forward to people who come in knowing how to program. I won't say I learned absolutely nothing in CS180/CS240, but the amount that I learned was definitely not worth two semesters of work. I had been program MUDs for a substantial amount of time, so I was familiar with C already. I didn't know Java, but I knew C++, so CS180 was not that exciting. Ironically, Professors Dunsmore (CS180) and Brylow (CS240) were among the best I had, but I would be willing to forgo the experience of their instruction in order to take more upper-level classes. I understand that many "experienced" incoming freshmen are overconfident, but an adequate test-out procedure should be enough to filter them out.
Lastly, here are things I will argue vigorously against:
- Keeping course curricula up to date with latest fads. I argued against this in the comments section and will repeat it here. Computer Science to me is not about learning the latest technology (in this case, F#), but learning things that enable you to easily understand the latest technology. Trying to keep up with the latest fads not only pushes lots of pressure to come up with new syllabi, but also has questionable benefit. Putting F# in a curriculum effectively binds people to Windows or forces them to figure out Mono, while OCaml works on multiple platforms.
- Teaching technologies rather than foundations. The other example in the comments was about learning Silverlight. I risk offending people with this part, but oh well. Majors like C&IT are where you go to learn things like this. They are utterly focused on technologies rather than foundations. To put it one way, a C&IT degree is a fish and a CS degree is an instruction manual on how to fish. To put it very bluntly, certain parts of C&IT are what motivated CS majors learn in their spare time. Of course, to some degree this is necessary (when teaching programming).
- Pipe dreaming about infinitely flexible courses. I'm sorry to say that this is thoroughly unrealistic and puts much more strain on already-stressed TAs on grading objectively. Being able to pick your own projects for classes sounds nice, but I haven't seen this implemented effectively in any core classes.
There's one big factor in the equation that I haven't (and won't) address and that's people. How can we make students motivated to learn and faculty motivated to teach? Who knows? Not me. Nevertheless, I think the undergrad CS program has progressed in a positive way. I'm interested in hearing what undergrads that are able to experience the changes have to say.
14 comments:
I'm going to moderate comments on this post. Keep them constructive or don't post at all.
I agree wholeheartedly on the Technologies vs. Roots argument of programming. I have a friend who is a C&IT major and it still astonishes me that he doesn't understand pointers, memory allocation, or other core concepts. I feel that the education of the root languages and concepts has made it easy to adapt to any environment, but for him, he is limited to only Java and .Net and would not be easily able to migrate into a foreign programming environment.
The 381 idea is correct - no other school (even those ranked below us by US News (not that I trust them)) allows a CS major to get a degree without algorithms.
Some of the arguments I heard from students in the course were:
->The course in extremely hard.
->Textbook is too huge and a lot of its content won't be used
GNF (he taught 381 when I took it) offered 3 hours a week (more by appointment) for answering questions and maintained a record of students who came to visit him. He couldn't fill a page with the names of the kids who showed up and still the performance on the assignments was below GNF's own expectations.
I don't know why we are in the process of dumbing down coursework here for unmotivated kids. Probably this is a college of science thing and the CS dropout rates probably don't align well with Physics, Chem retention rates.
Dr. Mathur believes that CS belongs in ECE and the proof of that is MIT + Berkeley + Stanford have made the switch (and made it extremely well) and successfully produced very brilliant engineers / researchers. The resistance to this is probably from the ECE department where the argument is that it would be impossible to cover the material in 4 years. I really wonder how Purdue ECE churns out someone better prepared for further study / industry than say MIT/Stanford etc (i.e. we don't seem to do any better than them). To deal with 6 - 7 abstractions that make up computing, there need not be 2 departments with redundant coursework (some of their programming stuff is a total joke).
Next, we pay too much attention to dropout rates. Maybe Purdue has a responsibility as a public university to try and stem dropouts but it is absolutely necessary to understand that the student is to blame here and too many people with no formal understanding of binary numbers managed to pass out of CS 182 (with a lousy grade, but still..).
The track idea is not without its merits but I can see that in the near future the Foundations track will be closed since no one wants to take it. I predict a similar future for graphics (everyone hates linear algebra) and possibly systems (too much code to write).
Algorithmic classes are really hard. I got an A in CS381, but I'm not sure how. I believe I got B's in CS525 and CS581, which are parallel computing and grad-level algorithms. That being said, I firmly believe making CS381 optional is the wrong approach. I think the department needs to do some brainstorming to figure out better ways to teach CS381 – not make it easier from a homework point of view, but better for a teaching point of view. For example, I think it's a big waste of time to just teach the popular algorithms. For the most part, these are really easy. CS381 is obscenely difficult because the homework/exam is about finding ways to modify the popular algorithms to solve other problems. It may be difficult/impossible to give a process for solving these problems, but it merits thought. Either way, the average grades you see in CS381 are not nearly as bad as what you see in some ECE classes.
I haven't followed the ECE/CS merger very closely, but I agree with the idea. I also agree that some of ECE's programming classes aren't as comprehensive as ours. If they ended up using our syllabi, ECE would probably be even more difficult.
IMO, the fact that people passed CS182 without a good understanding of binary is not the fault of the students but the fault of the system. ECE solves this by using outcomes, which I mentioned as something CS should implement. I think it's a little naive to place all of the blame on the student, though I can easily see where you're coming from. Blaming the student is unacceptable from a pedagogical standpoint because it will eventually result in stagnation.
I don't think a track's popularity will determine its existence. Certainly, Foundations will probably be a sparsely populated track, but there's really no reason to get rid of it. It doesn't really have an upkeep cost that I'm aware of. People might hate linear algebra, but lots of CS majors dream about making computer games. I doubt the graphics track will be that bad. I doubt systems will be have problems either. I didn't even know there was such thing as too much programming...:-)
I firmly believe that CS should be considered a science over engineering. An amazing software developer can be a horrible computer scientist, but a well educated computer scientist is usually just an inexperienced (to employers) software developer.
I personally feel that the foundations track should be a requirement of a computer scientist, there are just too many awesome technologies that created entire successful industries (BSP @ id, MapReduce @ Google, etc.) that were based of important Mathematical observations (applied) by computer scientists.
Really, as long as the track courses offer the "why + proof" and not simply a "how to" it is best for everyone. We're training scientists, not developers.
Hi, thanks for your comment. I've been super busy for the past week, so I wasn't able to reply. While I agree that in theory we're training "scientists," in practice, most of the people in our program don't end up doing science-y things. Keep in mind that the things you mentioned weren't developed by undergrads.
While I think the "science" part is important, I think the engineering training is still valuable to undergrads. Some of the tracks have diluted the original requirements that we had from before, and while I kind of disagree with some parts (the removal of CS381 as a requirement), I can appreciate that not everyone needs a fully theoretical training.
The value of an education in computer science is somewhat inflated. What are you going to learn? That the hardest/most important problem is proving p!=np (or the other case of p=np) That computer science is fundamentally a math problem and you can learn all these trivial theories (Dijkstra's algorithm, dynamic programming, useless O notation, hueristic etc) on wikipedia? That the teacher is only responsible for a syllabus, and you learn everything else by reading on your own time and can ditch class to do more productive things? All these things about TAs not grading easy, classes too hard and other things mentioned on this blog are red herrings. The VALUE of a computer science education is questionable. If there was no wikipedia, I wouldn't actually learn anything from my professors.
I'd like to see a study (although a hard one to conduct). Have some number of students take a course with the restriction of not being able to use online resources (like wikipedia, stack overflow etc). And another group just take classes as they "normally" would (pre 90's style with no internet access). Compare the "success" rates of the two respective groups. How much does the Internet actually play a role?
If you think "all these theories" that you can learn in CS are "trivial," then you are clearly smarter than me and perhaps the value of a CS education is not worth your while. All of the topics you listed are relatively simple (O notation useless? Really?), but not everything is as easy to understand as Dijkstra's algorithm. I think it's insulting to call these theories trivial, anyway. Maybe if you can prove every single one of them then I will accept your opinion that they are trivial. To you.
If the professor is only in charge of the syllabus, he is obviously doing something wrong. If you are able to learn everything in CS off of Wikipedia, congratulations. Most people can't. Wikipedia is a great resource, but there are a number of topics which can be rather difficult to grok on Wikipedia. I don't really understand how you can say that you would learn nothing from your professors if not from Wikipedia. If Wikipedia is how you learn, then you aren't learning from them anyway and something is wrong (or you are very smart).
I don't understand your experiment because both groups sound the same to me.
Also relevant: http://xkcd.com/435/
So I'm in my first year of programming here at Purdue. I transferred in this year after a year of Informatics at IU (don't tell anyone). My programming experience beforehand was nonexistent.
Mathur and CS180 was a great introductory course, and you can tell he cares a lot about the students and curriculum.
I'm sorry to say that since then, every CS professor (Vitek-240 Szpankowski-182) have, from my viewpoint, been dreadful teachers. We are discouraged from speaking to professors directly, told not to use office hours, and left to independently learn, essentially through trial and error. While I understand the benefit of such, I feel students are short changed by not actually being taught. Oftentimes it appears these professors are here for research, and view teaching (at least these low level courses) as more of a hassle then anything.
Additionally, since all classes are on a curve, the grading scale is seriously askew. You typically have former programmers who view the work and labs as trivial because they've already learned all the information and then get excellent grades (from what I read, you fall into this category Dan) and then you have a significant number of students with negligible programming experience who flounder without proper teaching and are evaluated on an uneven scale.
By this, I also believe there should be a testing out procedure in order to help prevent this.
I enjoy seeing comments and opinions from others on this subject though, especially since our experiences have been very different!
Hi Brady,
Thanks for your comment. I am sad that you include my former adviser as a dreadful teacher. I'm surprised that he would avoid speaking to students and discourage office hours, as well. What you state is often true, though: professors are often here for research instead of teaching. That's unavoidable in the current academic climate. I feel I've had a pretty good track record of professors in that regard.
I think you should also understand, however, that some of these professors don't have a ton of experience teaching undergrads and when they do, they often teach more advanced classes. Some professors make the mistake of assuming too much of students, which sounds like kind of what you're getting at. Hopefully you have better luck in the future. Your sample size is small for now and your overall opinion could still change!
I do agree that test outs should be more common. I suggested it several times as an undergrad, but I don't think the faculty were too taken with the idea. I don't remember if I was given a reason why!
I'm a freshman in Purdue thinking about CODOing over to Computer Science. However, after reading all these posts, I'm having second thoughts. A lot of the comments about the quality of professors ring true with the single CS course I'm taking right now, CS177. This class is supposed to be for people who have never taken a computer programming class before and most of them are either math or engineering majors. I personally have taken 2 semesters of computer programming in high school. When Prof. Hoffman explains a new concept to other students, I try to imagine as if I've never learned the material before and see if I understand it, although this obviously can not be done subjectively. I find that it's pretty hard to understand, and he explains the simplest concepts in the most complex way possible. This is not just based on my observations though. Many classmates around me have to ask me or other neighbors who have some programming experience what in the world he is talking about. And a lot of the times when an iClicker question is posted and the results are shown, the class is split 50 50 down the middle or split three ways which shows that people really don't understand the material the way it's being taught. Whenever someone asks a question about something they don't understand, he usually either responds sarcastically or explains it in pretty much the same words he used 5 minutes ago. I have other gripes such as him being a professor in computer science but having horrendous typing speed, poor mouse control, and a lack of knowledge on how to operate windows 7 and having to spend at least a fourth of each lecture waiting for him because of these faults. I assume though that this is mostly because of his obviously old age and that most CS professors aren't like this this. I also find that the TA's are much more helpful and can explain things much easier than he can. I learn just as much if not more in 5 minutes with talking to a TA during recitation or lab than 50 minutes during his lecture. This is partially because of class size but the contrast shouldn't be so large.
Since he is my only context to compare to, I must ask how is Prof. Hoffman compared to other CS professors? Well below Average? Average? Excellent? From the comments I have read, he seems above average which is rather horrifying to me considering this is supposed to be college quality education.
Since I'm not very well versed in computer programming, could you give me a more in-depth description of the tracks, the differences between their specialties, and what job each would be useful for? I'm specifically interested in computation science and engineering, database and information systems, programming languages, and software engineering. Also, are there any other optional courses besides the one that you mentioned (381) that a CS major must take before he graduates?
Sorry for the huge wall of text. I underestimated the size of that first "paragraph" and probably should have split it up.
Hi Anonymous, thanks for your comment. As far as I know, Professor Hoffman never taught a freshman-level class in the 7 years I was at Purdue. I wouldn't be surprised if it was his first time doing so. We need professors that are committed to the intro classes like we used to, but those are hard to come by. When you're always teaching advanced classes, you tend to expect more out of your students than you would freshmen.
And yes, Hoffman is old school. To give you an idea of how old he is, he's been a professor at Purdue since my parents went there for grad school. Doesn't sound like his teaching style is much different from back then. As for how he compares to others, I can't say for sure, as I never had him myself. Personally, I feel like the professors I've had are good enough, but I recognize that my opinion is probably not that close to normal. I was a pretty "ideal" student to a professor in that I rarely asked questions and liked to figure things out on my own.
If you want to get an idea of what's ahead professor-wise, talk to your lab TAs. They're undergrads, so their experience will be more current than mine.
Tracks were implemented after I got my BS, so I have little experience in that as well. My guess is that it really boils down to what you want to learn, rather than what kind of job you want. CS majors aren't typically hired for a narrow skill set, since undergrads are more about breadth than depth. I think 381 is the big one that you should take, but don't take it unless you're in for a serious challenge. I dislike that compilers was made optional as well, but I think algorithms expands your mind a bit more. And again, some of your lab TAs are probably starting specializations now, so you can ask them about it, too.
Post a Comment