State of Computer Science at Purdue...address

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:

1. 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.
2. 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.
3. 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.
4. 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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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:

1. 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.
2. 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).
3. 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.

Pittsburgh takes a dump on education

It's been awhile, I can't sleep, and even though I posted this on Facebook, I think it merits repetition, even if it's late-night, drowsy, nonsensical repetition.

A post appeared on Slashdot today titled, "Students Are Always Half Right In Pittsburgh. A curious title, but what's truly astounding is what the article is about. Apparently, Pittsburgh public schools are, in a no-child-left-behind fashion, are going to be limiting the lower bound on grades to 50%. Seriously.

The reason is relatively obvious; the Post-Gazette article quotes a spokesperson saying, "We want to create situations where students can recover and not give up." Quite a noble reason, I suppose. Yet, the consequences seem to be alarming. Wait, no they aren't, because "it's not grade inflation." Guess that settles that. Or not. Slashdot commenter Jason Pollock explains just how bad this system actually is. Essentially, you can easily get a passing grade, with very, very little effort. The example is somewhat incorrect, since grades are done differently than simple overall percentages, but the effect is the same.

I don't know how this managed to come about, given the fairly obvious ethical concerns, never mind the fact that you only need a 20% in each grading period to pass a class. It scares me that so many high level officials in the Pittsburgh area seem to agree with institution of this policy. The solution to the goal thoroughly destroys the essence of a proper education. Incentive to actually learn material is diminished, when students are always "half right" anyway. There aren't many ideas that I can think of that would be less apt to striving for "Excellence for All."

It's not like trying to help students boost their grades is a new subject. Giving free points for no work is simply not the correct answer. One district made students redo homeworks until it was A or B material. While I think this could be a good idea, to some extent, it sounded like they actually were given an A or B in the end. While it's great that they learn the material, grades don't mean much if everyone gets an A or B. The basic concept, however, I agree with: Give students opportunities to make up bad scores, rather than just giving them away for free. Giving remedial homeworks, allowing a redo of homeworks for added partial credit, or some forms of extra credit are all better, logical, ethical alternatives. I just hope that this decision is contained, if not reversed.

The difficulty of Lisp

An blog post on the difficulty of learning Lisp recently appeared on Reddit, which argued that Lisp was actually not very hard to learn. Unfortunately, to be honest, the reasoning totally sucks.

I think the "Lisp is hard" idea is general bunk. It’s different and looks funny (but, hey, if you can stomach C++, what can’t you take!) but getting started in Lisp is no harder that any other language. In fact, its easier to get started in Lisp than it is in programs that require a separate compilation step.

Of all of the points to argue why Lisp would be easy, this is certainly not a very good place to start. A hello world application indicates nothing about the difficulty on learning a language. Well, almost nothing. Java's hello world is often cited as indication of how difficult it is for some to learn Java, but I don't think the converse applies. I do agree with the author, though. It's going to take a lot of work of some sort to start convincing people otherwise. Mark Guzdial, a long-time teacher now at Georgia Tech, wrote a post about the best paradigm for teaching programming, saying:

Supporters have argued that a functional approach is most like mathematics (and is thus more familiar) and that non-mutable variables lead to more easily maintained software, are easier to understand, and are more likely to be provable. A paper at ESP by Michael Eisenberg and Mitchel Resnick showed how hard functional programming is for students. If the students are comparing functional programming to mathematics, it’s not obvious and even if it’s happening, it’s not clear that it’s helping.

Unfortunately, the article was published in 1987 and isn't even available at ACM's digital library. Funny enough, the five comments at the time of this writing all agree that Lisp is not hard. The general consensus seemed to be that Lisp makes other languages hard, that learning Lisp first would make other languages harder. I find this somewhat difficult to believe, and very subjective at best. It may certainly have an impact (to a degree) on what language you prefer, but as to increasing the difficulty of learning, there probably isn't much research in that area. It's similar but more radical to the debate over whether learning object-oriented programming before procedural programming (Java, C) is better.

Indeed, some of the resistance to learning Lisp is probably FUD of some sorts. It's probably also somewhat related to many universities' reluctance to teach a language that isn't used in the industry, which doesn't use Lisp because universities don't teach it, ad infinitum. However, it's certainly unfair to argue about ease of programming with hello world programs.

The Scheming senior

Life has been busy once more, since school started. For some reason, I thought it would be a good idea to take three CS classes (software engineering, programming languages, and cryptography) as well as music theory. Music theory appears to have homework due every class, which sucks, even though it's pretty easy so far. In addition, being a senior now, I have to start worrying about what direction I want my life to go in next year. Of course, being me, I'm still rather indecisive over graduate school versus industry.

Research, to be honest, is so far basically what I made it out to be—boring. It didn't help that I picked a topic that I wasn't particularly interested in, but I'm doing my best to stay interested. Professor Mathur seems to be very passionate about what he does, which helps my motivation a bit. Even though it's not that exciting (calling it flat out boring is also an exaggeration), I guess this is a good experience for me to actually have a mentor that's been in the field for years. Hopefully I can get the motivation to finish this research project and publish a paper at the end of the semester, which would look nice on a resume for grad school. Weekly meetings should boost my motivation, at least a little bit.

Classes are kind of "meh" right now. Software engineering is definitely a lot less exciting than I thought it would be, and kind of wish I had taken something else instead. The project is some sort of grunt work from HP that has to do with finance. It definitely sucks compared to the project binder that we saw, which was a game of some sorts. From what the programming languages book is saying, the class will get more interesting as time goes on, but the current chapters are boring. Cryptography is pretty interesting; it's probably the most interesting thing right now. Music theory hasn't gotten past playing scales, so it's not very exciting. Playing on the keyboards on Friday is kind of fun despite the simplicity, since I haven't played piano in about seven years now.

Perhaps the most interesting thing that has happened lately (at least to me) is the arrival of my latest shipment from Amazon, consisting of:

• The Little Schemer, 4th ed.
• Serenity, Collectors Edition
• The Design of Sites

The Design of Sites is more to get some inspiration for web design, since I clearly suck at it. I guess this is necessary, since the web is the wave of the future. Or whatever. It seems to be very illustrated, but I haven't really looked too carefully at it, yet.

Serenity came out recently, which I couldn't resist buying, even though I already own the original edition. Firefly is one of my favorite series, and extended scenes and more bonus features makes an already awesome science fiction universe even more legen—wait for it—

Last, but certainly not least, I've already gone through two chapters of The Little Schemer. The book takes on a very peculiar format, based purely (at least so far) in Q&A format. They ask questions that you can hopefully answer and give explanations for each answer. For a fairly advanced programmer like me, this is amusing at first, but tiring in some spots. I was hoping for a book that I could read cover to cover, but this doesn't seem to be the book. Not that I'm disappointed with it at all, I just don't feel like reading through levels of recursion that are obvious to me.

This brings about an interesting pedagogical method; Friedman and Felleisen take an approach that depends on the human ability to recognize patterns. It seems like if you ask enough questions, the reader should be able to figure out what a certain function does. I had kind of an advantage of already knowing what some of them did, so playing a game of 20 questions was a bit overkill, but I wonder how this teaching method would apply to a more inexperienced student.

Actually, I already use this method somewhat with students. Whenever a student asks me a question that I deem should be obvious or already known from previous labs/lectures, I bombard them with questions until they figure it out. Unfortunately, this doesn't always work, possible due to a few reasons:

• The student is lazy. This might be a mean thing to say, but I think it's true. Graduate TAs that run consulting hours complain about students being unable to debug on their own, which I believe should be fairly intuitive. I've even had someone cry, possibly to get me to write the project instead.
• The student doesn't really understand the language. Compared the Scheme, Java is pretty complex, and some students never really properly learn some language constructs (e.g. the static keyword). This presents a huge problem when you get errors like, "non-static variable referenced in a static context." This is more of a lack of knowledge than reasoning ability, so this is where I throw my hands in the air and tell them to read the textbook.
• I'm not asking enough questions or I'm asking the wrong questions. This is quite possible; unlike the concepts presented so far in this book, so it's not always possible to ask an exhaustive list of questions to make the student reason through exactly what mess he/she has just made.

Regardless of the potential for failure, I think this could be applied to some specific topics for students to look like. The static keyword is probably a good target to start with. It is not as difficult to make an exhaustive list of questions for the students to "pattern match" through for one single concept, but I guess it's too late to use this kind of method when they're working on projects midway through the semester. Hopefully I can get some spare time to concoct an article for using the static keyword, and get some response from students on how beneficial it was.

Anyway, this has been a very random grouping of topics and I think I've poured out my heart and soul enough for tonight.

Dary.

How to get the wrong people in your computer science program

A humoring thread came up on the Something Awful forums that I almost forgot about. The thread is about those schools you see that advertise on television ("Come to ITT Tech!!! Make some gamez!!!!!"); everyone who has seen those ads on TV probably deduces that they aren't very good at what they do (why else would they be advertising?). The University of Advancing Technology made a highly amusing blunder on their website:

Eating is a serious pastime at UAT. Lunchtime is never a quiet, reflective time for college students in general. But at UAT, it's a noisy, rollicking journey down the highway of fun. It's not uncommon to witness students engaged in vigorous Guitar Hero contests, or watching the latest anime on the big-screen. Or you can eavesdrop on impassioned conversations about the merits of C++ versus Linux.

Enough said, I think.

Java as a first programming language

A thread on the Something Awful forums came up recently about a high school, second-year computer science/programming course. The author was requesting help to convince his teacher to switch said course from using VB6 to C#. There were a number of suggestions and alternatives given (Java, VB.NET, Python, Scheme), but that's not as relevant to the CS environment at Purdue (thread is here if interested). I got into a couple of discussions about C# and Java, and it brings me back again to imagine what Purdue would be like if we didn't teach Java as a first programming language.

The issue I brought up was an argument against teaching students how to write procedural code in a purely object oriented language. In particular, someone suggested that teaching procedural code in C# was easy, since you could simply add the static keyword to class methods to write non-object oriented code. I argued that teaching the static keyword before telling students what it meant was a particularly bad idea. I've never been a fan of teaching stuff out of order (who is?), but it seems impossible to teach things in order in Java. This is plainly visible by Java's hello world program:

class Main {
    public static void main(String[] args) {
        System.out.println("Hello world!");
    }
}

This is incredibly ugly, and C# is guilty of the exact same thing. For beginners, I don't think this is acceptable. Unfortunately, all compiled languages that I know of are guilty of this to some degree; on the other hand, scripting languages can do hello world programs in one line. When you introduce this Java program to a student, here is what new programmers tend to think:

1. What is public?
2. What is static?
3. What is "main"?

The list can continue (what is System, out, println, etc.), but the point is, there are a lot of questions to be answered that can't be answered without covering material that they aren't ready for. In particular, I believe the static keyword is a real killer, even for some people who've programmed before (obviously not in depth). Instead of reiterating everything I said in the thread, I'll just copy and paste like the resourceful (read: lazy) person I am:

I think the static keyword versus other language syntax is slightly different. Why should you have to teach the static keyword first in an object-oriented language? In terms of thinking about objects, static "breaks" the OOP paradigm. One of the C# compiler devs even argues that the static keyword shouldn't exist. Obviously you need some way to differentiate between instance and static methods, but I never really liked to use of the word "static" to do so. Maybe it's just me, but when I hear the word in a general context, I take it to either be in terms of static you see in TVs, or static as in unchanging, the latter of which is due to static/DHCP IPs. Are people really supposed to be able to tell what "static" means, just offhand?

OOP languages like C# and Java are actually backwards in terms of expressing methods and their arguments. If you were to write OOP code in C, the "instance" methods would be the ones with the extra typing (the first parameter being the object type), and the static methods would simply do the opposite. In Python, declaring methods is the exact same way. All instance methods in Python begin with a "self" whereas static methods simply don't have a self. You can also call instance methods with static syntax, which gives some insight into just how OOP methods are actually defined.

As far as learning is concerned, I think Python is better for teaching the difference between static/instance methods (other topics are debatable). I really don't like telling my students, "oh, don't worry about this huge, gigantic header you have to write for your main method--or what a main method actually is. You'll learn that later!" {}, (), [], and <> are introduced in a more appropriate order (though funny enough, I do have students that still don't get the paren), so I don't think it's [as] relevant.

A post from another user probably summarizes very well:

introducing students to computer science through languages which introduce syntax issues long before they introduce computer science concepts is a recipe for failure, and I completely agree. Aside from the utter boneheadedness of an "objects early" or "objects first" approach, you're giving students a gigantic chunk of boilerplate code and not explaining what any of it does. Seriously, just think about it: a student is not going to be thinking in object-oriented terms right off the bat, so how do you explain what this "public class" and "public static void main" business is? The Javaschool answer is "we don't, we just tell them that it's not important and they'll understand it later." This is not an acceptable approach.

From what I've observed, Java is taught at Purdue (and other schools) for a few reasons:

• Java is the number one language used, at the moment
• Java is heavily involved in other courses (for Purdue, often data structures and compilers), and not teaching Java would have a severe impact on the curriculum
• It's a good gateway to other statically typed languages, unlike Python and company, because of syntax similarities

There was, however, a comment by the same user above, regarding Java in computer science programs:

I've been doing a lot of research into computer science education recently (I'm more or less rewriting a computer science curriculum for my college), and there have been numerous studies which show poor computer science retention rates in Java-based computer science programs (equivalent to ACM CS1 core) that have improved substantially when the course syllabus was switched to a simpler language like Python or Scheme which allows students to focus on computer science concepts rather than fighting with language syntax. Pummel them with Java later.

While the idea of teaching a language that isn't statically typed bugs me, maybe it's just my upbringing in C. As far as static methods in classes go, I would certainly agree that Python does a better job of getting the idea across, as said in my quote above. However, I also think Python offers a lot of freedoms that aren't available in C# and Java (as do most scripting languages), which might increase the difficulty of learning statically typed OOP; nevermind the syntax differences between Python and "C-family" languages.

On the other hand, Python's enforced proper block indentation also brings something refreshing to the table. I've seen some extremely bad indention in Java (literally different levels on each line in a block!), and I think Python has taken a good step by enforcing uniform indentation. Unfortunately, we don't see this in most languages, so this is a nice plus to using Python as a learning language.

Unfortunately, I'm still not sure teaching Python as a first language is a good idea. I sure don't like Java (for anything), but then again, I don't know of any languages that I would rather teach students that have advantages that are substantial enough to merit a change in a class syllabus. I don't think functional languages will ever fly here, regardless of how pretty or ugly they look; the idea of CS180 is to prepare students for CS240, which transitions from Java to C. I don't think the Pythonic way of doing things will prepare students for C; it may teach you how to program, but as much as it makes no sense, I'm guessing it would just pass along the problem to the CS240 instructors. And we all know what kind of monster that would awaken.

Apparently computer science at Purdue sucks (Part 2)

Here's a response to several posts (linked) about Purdue CS from "I'm a 10!":

Non-CS CS students

I'm sure the statistics agree that the percentage of students that enter without any computer science background and stay is much lower than the percentage of students that enter with prior experience. I would also argue, however, that part of it is because those students enter CS without knowing what they really want. I've used this argument a lot, and it might not be true [anymore], but I think a lot of students come into our department because they think they're good with computers; this is patently incorrect reasoning. I think for people interested in CS, they should try to get into programming before they leave high school to see if it's really for them. Of course, sometimes it's formally impossible to do so.

While I'm one of the fortunate that had AP Computer Science offered at their high school, not everyone does. One of our CS180 lab instructors came to Purdue with no formal experience, because his school didn't offer it. This is a commonly cited reason for not having experience, but I don't think I buy this as an excuse. In most situations, I find it hard to believe that a high school student doesn't have the time for some self-teaching; I also believe that if a student is unable to teach him or herself, it might be a sign; after all, software engineering is hard. This is not to say that it's impossible, or that people with no experience entering CS at Purdue will fail, as a counter-example is provided above, but I don't think it's making it easier on anyone. To me, computer science is one of the few areas where you can get some real, practical knowledge before entering college. I'm fairly ignorant about other fields, so it could be one of many.

Of course, to shift all of the blame onto the students is probably biased elitism. I think the curriculum could use an overhaul, but such a task is time-consuming, bureaucratic, and not likely to happen. There are a lot of issues at hand, and I daresay that it's impossible to solve them all. Primarily, not all professors that teach classes want to be there. From what I understand, all professors are supposed to teach at least one class a semester, but not all professors are interested in teaching, much less teaching undergrads. The same goes for TAs; I've heard of a number of graduate TAs that don't seem to put much effort into their teaching, or their knowledge of the subject is restricted to an inapplicable domain, or some other random problem. Is it impossible to find grad students that care and actually know something? I don't think so. I've come across several good TAs over the years; perhaps they're just a minority. In all reality, this applies to undergrad TAs as well. I've seen some TAs who either don't care, don't actually know enough to be very good TAs, or just think that students that ask questions are dumb. Since I think I'm taking over as lab admin next semester, I sure hope I get a say in who will be on my lab staff.

Course syllabi also vary significantly from professor to professor. While I understand that professors have different teaching styles, I don't think it's a very good idea to have such a significant difference. For example, I took CS251, our data structures class, in the fall, which is off-semester. The class was a piece of cake and I hardly had to study for it. The kids who took it in the spring had incredible amounts of work, including building a web server using certain data structures, etc. While I think it's cool to work on practical projects like that, I think it's unfair to the students who have to do significantly more work for less return. The objective of the course should be learning about data structures, their run times, and how to implement them. All of the extra stuff is nice for the very advanced students, but adds incredible stress to everyone else.

Administration

I can't really comment much on this, since I'm not in the USB and have zero interaction with higher administration, but I'm guessing it's related to my statements above, since the higher administration are a subset of the faculty. I have no idea what caused a strained relationship between the administration and the USB, but I really fail to see why bygones can't be bygones. It seems that both the students and the faculty know what's best for the students, which just causes a deadlock in improving our CS curriculum.

The new building

To some degree, I agree that the new building has had a negative impact on the little sociality that our CS department had. I think the lack of a new undergrad lounge is kind moot point, since it's [kind of] migrated to the small area outside of the advisors' offices as well as the computer labs, where a lot of people seem to do work. I'm pretty sure the administration knew that the commons wouldn't be occupied by many CS majors, but I guess they didn't have much else to do with that space besides make it look pretty. Besides, the commons brings girls into our building, what can be so bad about that?!

My real issue with the new building is the bureaucracy that's been added to the advisors' offices. There's a secretary outside of that block now, and we have to sign in and out and set up appointments to meet our advisors; I would label this as being very close to the pinnacle of ridiculous. I don't think the advisors have ever had any trouble doing all of the work they needed with an open-door policy (which closes when stress levels rise), so who thought it would be a good idea to formalize social interaction with our advisors? I used to visit my advisor very frequently, and now it's reduced to one visit every few months; usually it's just to schedule my next semester. This sort of alienation between the students and the advisors is the last thing the department needs.

Apathy and entitlement

Apathy, as partly mentioned above, is a big kicker for the students and faculty. The faculty might not care, but the students often don't have more motivation than to complain on a newsgroup or to their own peers. The CS feedback panel hosted by the USB on a yearly basis shows little attendance from students that have issues with the way things are done, and sometimes the ones that do show up have very little constructive feedback to give. Even if there was a larger attendance and more feedback, does the faculty even care? Does anyone read their course feedback? I've read mine from teaching a CS158 (C for engineers) lab as well as for MA366 (ODE), but I've never really seen any active caring in CS180 about what sort of feedback TAs get. Is it like this for all classes/professors? No, but probably a majority.

My own conclusions

Despite all of this prose that looks like a bucket full of complaining, I'm actually not as dissatisified with CS as I seem. I've passed all of my classes and have started learning new stuff lately, which is good. Education and how to better teach in a CS180 lab are specific areas that I'm interested in, as a TA. I feel like it's my duty to try and reduce the number of people that drop out of CS because of CS180, but what's the use if they just drop out when they get to CS240?

I've jumped to conclusions before, but I wonder if other universities have these problems. It seems like a university with a CS department that genuinely cares about its undergrads would be a utopian department. Unfortunately, I don't think these universities exist.

Apparently computer science at Purdue sucks

Being a CS major at Purdue, I hear a lot of complaints about the way things are done. Often times, they're from people I don't know well, or from people that have made a bad first impression on me; regardless of what I think of them, sometimes they're just unfounded complaints, too. However, worse has come to worst when I hear complaints from what I see as the smartest of the department--usually honors students, but not always. If we're turning off the brightest light bulbs in CS, how are we supposed to retain student interest in CS? Being a junior now, I don't see many people that are very excited in my classes. Unfortunately, this trend has started to appear earlier in the years (our excuse is compilers), even down to the freshmen. One of my former students recently posted a note on Facebook about his beef with Purdue CS:

So many people are greedy, they are here to get a degree so they can make money, not to learn / change the world for the better / etc...

This is undeniably a true statement. Though, I would argue that its common in any major; after all, this is America. Essentially, we're forced into this philosophy (or into academia, or being a FSF junkie of some sorts, or whatever), and really this is a whole new discussion.

Academically repressive, exhausting and depressing.

This one is harder to really comment on. In recent years, CS240 (C Programming) has had a new professor (to the class, not to teaching) and a new set of TAs teaching the class. It's been getting terrible feedback from students, and I suspect that this statement is really the result of taking CS240. This class was pretty much golden when I took it, since I was under the instruction of Dr. Brylow and a capable set of lab instructors, but has since changed. While I can't comment on the teaching style of the new instructors, I can comment that the material has changed from historical teachings for the worse. Unfortunately, some students think this true of all CS classes they take. This is also a story for another day.

Of all the cs students I have met in my class, none have any love for the craft of programming. They all see it as a chore, and I don't blame them based on how our courses are taught.

This probably goes back to the "greedy" point. Most people in general seem to lack a real passion for what they do. As far as classes go, I think part of it is related to the lack of practical knowledge that's taught, in addition to excessive amounts of work and occasionally unreasonable constraints on assignments. Unfortunately, the latter is not easily fixed; for example, one constraint that was deemed unreasonable by another student in the class was the ban on using string library functions on assignments. This student is a talented programmer (also a former student of mine), but people who have never programmed before need to learn how to write these functions. Unfortunately, it slows the learning experience for advanced students, and the test-out process for classes is strongly discouraged/not allowed.

However, I would also say that there are still a group of students in CS that do enjoy programming. I'm more familiar with the upperclassmen, but I'm sure they exist in the freshmen ranks, as well. Difficult to find? Sure. It's not atypical for a CS major to be pretty anti-social.

TA's dont care. This is mostly because TA's have a bazillion things to grade though, which is more of a university problem of making classes huge. But TA's could make it easier on themselves by not being such strict graders.

This also seems to be a more recent development, which is somewhat unfortunate. For all of the CS180 TAs (at least this semester), however, I would argue that they put a lot of effort into trying to give the students a good learning experience. This comment probably is also related to CS240, and I can't comment. I've had a great track record of TAs, and most of the ones that I've had are extremely helpful when the situation arises, and are very knowledgeable and interested in doing a good job.

Though, when it comes down to grading, I might be inclined to disagree. I don't think a TA needs to be relaxed in grading. After all, if a student does something wrong, a TA should point it out to prevent future mistakes (say, for personal enrichment). If he/she ignores mistakes, is the student really garnering a good learning experience? I guess I don't really mean, "take off points for everything," as much as, "point out all visible mistakes to the student." It's still in the grading process, but it doesn't necessarily have to affect the grade. I stand by this firmly, as I see plenty of students who have had TAs that won't do this sort of thing, and write what I believe to be terrible code (where terrible may or may not be hyperbolic). For example:

public boolean foo() {
    boolean b = bar();
    if (b == true) {
        return true;
    }
    else {
        return false;
    }
}

This is a simple piece of code, it's pretty obvious what it does and I see this frequently, and it's not semantically "wrong". It drives me insane. It isn't that bad, but I believe it's indicative that something weird is being taught in class. I feel like I'd be committing a mortal sin if I didn't tell my students not to do this.

Most CS students are hardcore gamers, which alienates me somewhat from their ranks, because that is there primary social activity.

You can probably find CS students that don't game a lot and don't drink a lot (like me, except my reason for not gaming is time constraints, and believe it or not, laziness), but they really aren't high in numbers; this, I would agree with. However, they can still be found, I think. The CS department does a decent job of hosting events where you can network with other CS majors, but a lot of people don't take advantage of them. I'd say that this would be a better way to meet students, than in a classroom environment. Yes, we are quite often anti-social, but we're CS majors. You can meet other people at clubs that you're interested in, and I'm sure they'll be less socially inept.

It doesn't help that we're in the middle of a large corn field known as "Indiana," but I think people can find other things to do (movies, card games, whatever). Of course, I'm not an expert in these things, so I can't say much.

Another student (also of mine, what a trend) posted a comment:

Why don't we make CS fun and actually work on projects that are in interest to us?

I think the simple answer is, "It's extremely difficult." CS classes [unfortunately] have to cater to a wide variety of students: people who care, people who don't care, people who don't actually know how to code that have somehow survived X semesters where X > 1, etc. Making assignments that interests everyone is impossible. It's hard to cater to even a majority; how do you calculate what a majority is? Some people are interested in theory. Some in practical material. The debate goes on, and in the end, the instructors decide. In the end, the entry-level classes tend to be very boring for people who have prior experience; this is unavoidable, which sucks, sure. Even if you could test out of these classes, there would be a number of indignant people who failed the test out for X class, because they "knew everything" about said subject. It boils down to intro classes being boring, and advanced classes being, well, less boring. Less difficult? Probably not ever.

Another student some time ago suggested that CS352, the infamous compilers class, be removed from Purdue. Reasons cited:

1. Really really hard
2. Nobody remembered anything

My answer to one is pretty blunt: boo hoo. To the second, I think our department head responded correctly in saying that it's the student's fault. I hardly see how the curriculum is at fault for this. I'm somewhat biased in that I was probably the only person in my class who liked the stuff taught in compilers, but whatever. It was something new, which was refreshing.

But speaking of this student, complaints about the CS curriculum here can be addressed in a few ways:

1. Mid-semester reviews
2. USB feedback panel
3. Complaining to your advisor

I think the feedback panel is the most valuable, since it's a collection of faculty and sometimes advisors that listen to what you have to say.

I've wasted too much time on this now, and now I'm going to fail my OS exam since I haven't studied.