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.

The not-as-exciting Austin post

Not to insult Austin or anything, but I'm lazy, and most of the work was done for me already. James posted a fairly comprehensive summary of what went down in Austin.

The only thing I have to mention is that I'm noticing a trend when comparing Purdue's campus to others (such as MIT and UTA). I wonder if it's really just because I've seen Purdue for three years.

The super-exciting Boston post

Yeah, so this post took about 5 days more than it should have. Oh well.

All was quiet from my end of the Internet this past weekend, since I was at MIT visiting my so-very-dear friend, Julia. Of course, like the rest of this year, my airport experience was highly unpleasant at best. I decided to fly US Airways since it was cheap; apparently they were cheap enough that they canceled my flight out on Friday evening without citing a reason, forcing me to fly out at 6:20am on Saturday to be able to spend any significant amount of time in Boston. My flights were delayed a little bit anyway, and filled with crying babies, further adding to the flight fun.

After arriving in Boston, we went to a Vietnamese restaurant around Harvard where I had phở for the first time, along with some sort of beverage made of jackfruit. Phở is basically a beef noodle soup, though there were some ingredients within that I couldn't identify (and thinking back, would probably rather not); it was pretty good, especially since I hadn't had breakfast, despite being awake since 4am.

After lunch, it was pouring extremely hard, so we spent rest of the remainder of the day in the comfort of a dorm room. The dorm is a graduate dorm, and it provides a better environment than any dorm at Purdue ever has (or will); the dorm is replete with computing facilities, conference rooms, as well as apartment-like suites that include kitchens as well as bathrooms, never mind the fact that each room was bigger than a shared double in Hillenbrand. For dinner, I stood by idly and watched Julia cook we cooked chicken parmigiana, and since I'm alive, clearly it wasn't toxic. Too toxic, anyway.

After waking up at noon on Sunday, we had pancakes, eggs, and sausage (read: fat) for...for lunch, I guess. We took a mini-tour around MIT's campus, which was interesting; it's pretty different from Purdue's campus, which I would call boring at best (and smelly during select seasons). To begin, Purdue's campus is fairly confined to a smaller area, unlike MIT (and IU, for that matter); smaller areas aren't very exciting, but I guess it's nicer for walking to class. MIT's campus is a little more widespread and more "scenic," being that it doesn't reside in a town as tiny as West Lafayette. MIT also has some fairly interesting architecture, such as their CS building, which is probably the wackiest building I've ever seen in my life (photo shown below; not mine). More to the point, most of Purdue's buildings are pretty boring (new CS building, anyone?); maybe the architecture is just a novelty that would wear off on me if I saw it every day for four years, though.

MIT seems to have a more interesting history than Purdue does, as well. Maybe it's because of MIT's incredible nerdism that makes them measure bridges in terms of people, but as far as I know, Purdue feels pretty bland in comparison. Not that we don't have our own share of of urban legend to spice up our history, but it seems like our student population is confined typical college activities of partying and tipping cows studying hard. Of course, it's also quite likely that I'm left out of the loop, since I never leave my room.

MIT hacks are also a very interesting part of MIT culture. Putting fire trucks on top of buildings and putting blown up versions of a class ring on a stolen cannon seem to be above things that Purdue students (or administrators) could ever manage. Of course, I'm not exactly an expert of Purdue culture either, so I can't really make too many comparisons, but I think it's safe to say that Purdue is relatively normal; after all, we appear to be a relatively conservative campus.

Of course MIT has its downsides too, such as living through X years of torture, paying more money for one year than I pay for four years at Purdue, and so on. Paying so much more might entitle you to better living quarters among other things (being around generally smarter people, getting a job automatically, you know), but the the painted picture of the academic workload seems...well, crazy.

We walked around Boston for awhile; the weather was much nicer than it is in West Lafayette now. Even though it was overcast, it wasn't raining, and there was a nice breeze to keep the temperature nice. In West Lafayette, it's blistering hot, and I start sweating just walking back to my apartment from work. Lucky for me, I'm not playing tennis anymore, unlike two members of my family, or I'd probably be dead by now. Anyway, Boston was a pretty nice area; I certainly like it much more than I liked New York City when we visited for spring break (possibly because it was snowing and very wet). Boston didn't feel as congested as NYC always did (given that it was a Sunday), and I guess it just felt different (in a good sort of way?) walking around Boston; maybe I felt like I had a smaller chance of getting mugged.

It was kind of weird to see some university residences (MIT Greeks, BU dorms) sitting in the middle of a city, kind of like how Soochow University in Taiwan was right in the middle of a city. The buildings there were also unlike anything you'd ever see around Purdue, partly because some of them are very old compared to anything you would see in all of Indiana. I guess someone decided it would be fun to build housing vertically instead of horizontally to prevent people in Boston from getting fat; maybe I should move into one of those houses.

We ate at a Thai restaurant for dinner (I don't remember any names, I suppose I'm a bad tourist) and I had a yellow curry. I didn't realize they would just give you "extra" bowls of rice if you needed it, and there was an awful lot of curry sauce for just one bowl of rice, but it was still good. The rest of the night was spent watching South Park and failed attempts to get me to follow along with Japanese women doing aerobics and saying really odd things like, "I was robbed by two men" and, "take anything you want." I think their smiling faces indicated that they didn't know what they were saying.

We left for the airport basically right after waking up. My flight back was also delayed at each leg, and I ended up getting back home about two hours later than I should have. I don't know if I just pick terrible times to fly or what, since I don't think I've ever encountered this kind of luck before. At least I wasn't flying Northwest, who appears to be canceling flights like nobody's business, or I'd probably still be in Boston. Alone.

So all of this took way too long to think up and write, and I leave for Austin in a few days to visit James, a lazy bum who hasn't posted on his blog in awhile, all the while thinking he can bug me about my blogging!

CS180: Debugging

One major point that CS180 seems to be lacking teaching students about debugging--understandably so, because it seems like debugging should be a fairly intuitive process. However, when it comes down to programming projects, plenty of students come in to get help with the same situation: They've programmed their entire project, but it doesn't work. The degree to which their programming is hopeless varies by student, but in general, consulting TAs can get exasperated with bad programming practices and helplessness in regard to fixing bugs, be it at runtime or compile time.

One hopefully helpful way to attack this problem will be to have a lab about debugging, which will be fairly early in the semester. What I'm interested in hearing is what people think should be included in a lab like this. Since the lab is planned to be early on, it's difficult to have students attack complex scenarios and fix bugs in them. Perhaps the only thing we can teach them is the "development cycle," which seems to be: edit -> compile -> fix compiler errors -> compile -> run -> fix runtime bugs -> etc. This is pretty natural to students, and I haven't really seen any students who didn't understand that cycle. The problem really lies in the fact that they have no idea how to fix either type of bug.

In most cases, Java tends to spit out fairly reasonable error messages, which means students should be able to figure them out. Do they even bother to read them before calling a TA over? Sometimes I don't think they do--perhaps it would be in our best interest to have them sit on it for awhile, first. I seriously doubt it's difficult to understand what "missing semicolon" means. Another thing that needs to be pointed out is that compile time errors need to be fixed from the top, not bottom. Since one error (particularly syntax errors) can cause an explosion of false alarms, fixing from the bottom is often unhelpful and incorrect. Even though a compiler may spit out 100 errors, that doesn't mean you have 100 errors to fix!

Teaching students to fix runtime errors is, in my opinion, an order of magnitude more difficult. Part of it lies in the fact that some students will have the wackiest implementations you'll ever see that really make no sense at all, but also somehow work--most of the time. JDB is a potentially helpful tool, but this probably isn't something we want to teach this early on (I think it sucks compared to GDB, anyhow). Other ways of finding errors would be via unit tests, print-and-seek methods, or main methods for testing. The first has not been taught in CS180 at all (or in any CS class, for that matter), so the second is usually what I tell students to do. However, they seem to be unable to insert their own prints in strategic location. This should probably be mentioned in the debugging lab, since it's the easiest to teach. Writing main methods that do testing for you is probably a good idea as well, but this isn't as applicable until students get into projects with multiple classes.

The more and more I talk about this topic, the more I see that there might not be a whole lot that could be put into a debugging lab, besides reading. If the lab is to be early on, then we can only teach them a small amount. However, maybe it would be good to write a series of articles on more "advanced" topics for later projects? Good programming habits aren't really taught in CS180 either, for who knows what reason. For example, programming in incremental stages and testing (at the very least, compiling) at each stage will help reduce the bug fixing stress students experience if they try to program all of a project before compiling. Another thing to point out is that having methods be fairly small/contained is a good idea. It could make finding runtime errors a bit easier, compared to having a main method that's hundreds of lines long.

I also thought that having some sort of debugging exercises later on via CS192 might be helpful, but I have no responsibility in that part of the course planning (and at this stage, I don't really plan to). For now, we'll have to assume that we have to teach them everything they need to know about debugging in one very early lab, and put the reset off for individual reading later. Along that note, someone (Ryan, perhaps) mentioned that having a centralized repository for this kind of documentation would be good--would we have any contributors if this were to be set up?

For the tl;dr (or those too confused by my post that should be edited, but won't be), answer these questions:

• What should be in a debugging lab?
• What shouldn't be in a debugging lab but is still well worth knowing?
• Are you willing to write about these things for a central repository?

CS180: Writing easy-to-grade labs

Maybe I'm having delusions of grandeur, but I think this should be possible. I'm currently envisioning a method of writing labs that allows a script to perform automatic grading (yes that's right, I've gone mad) for the ease of the lab TA. A little adjusting to how comments in the skeleton are done can go a long way. I'm kind of lazy, so I'll be using my super-trivial code example that I ranted about some time ago, with two TODOs added:

public boolean foo() {
    boolean b = bar();
    if (b == true) {
        /* TODO 1:  Return true */
        /* END TODO 1 */
    }
    /* TODO 2:  Write an else statement that returns false. */
    /* END TODO 2 */
}

Usually the skeleton code will consist of a bunch of blanks you need to fill in, so if we specify and ending line for said blank, then you can tell what the student typed in for the TODO. This is a pretty simple approach, and allows you to swap out TODO implementations (say, a student's implementation for the solution's), which can be done by a grading script. This method would also take away the problem of TODOs that don't compile by default, which is an issue for students who can't finish their labs. You can test one TODO at a time, using the solution for the rest of the program.

Edit:This doesn't really take away the problem of TODOs that come non-compiling, since students can't test their program until it does. Duh. More on this later, maybe. Suggestions welcome.

Theoretically, this idea could be extended to make a script generate the skeleton code as well, since it seems trivial to extract the text between the comments and call it a skeleton:

public boolean foo() {
    boolean b = bar();
    if (b == true) {
        /* TODO 1:  Return true */
        return true;
        /* END TODO 1 */
    }
    /* TODO 2:  Write an else statement that returns false. */
    else {
        return false;
    }
    /* END TODO 2 */
}

I can imagine creating a directory structure for creating labs (kind of like Rails...except not):

solution/
doc/

From this, the lab spec would be written inside doc (how this will be done is yet to be decided), and the solution in the solution folder. Running a script after the solution is finished would:

1. Extract all of the solution text from the TODOs to create the skeleton in a skeleton folder
2. Create a tests/ directory that has a subdirectory for each TODO, where the author can insert Java programs to test that TODO
3. Generate the lab spec in HTML format in a www folder

This entire structure would be mailed out to all of the TAs, while the skeleton and www folders would be what was exposed to the students. When it came time for grading, you could have a generic script (I hope) that would take a test directory and a solution directory and run tests for each TODO on every student's files, generating text that would be mailed to students.

While automation would probably speed up grading by a lot, I still think there's room for grading things by hand. Emphasis on style, such as proper indentation, non-terrible horizontal whitespace) is much more difficult to automatically grade (if someone wants to write a script to do it, be my guest). Granting partial credit and giving advice for writing better code also has to be done manually, and I think it would be good if TAs at least spent time on this once every few labs (perhaps this should be designated; every third lab, maybe?). This process also doesn't help if we create write-from-scratch labs.

I think I've rambled enough for now; comments welcome, etc.

CS180: Writing and grading labs

Part of my summer goals for CS180 include improving the way labs in CS180 are done. There seemed to be a lack of standard in handling labs over the semesters that I taught, which actually weren't a huge deal, but I think it's a problem worth addressing. Different TAs tended to write their lab specs in different formats, which could sometimes be confusing; some TAs also wrote labs that were hard to grade, which ended up being annoying for all of the TAs. Specifically, the goals I have are:

• Write a spec writing guide (especially since I may be the only returning lab TA)
• Write a lab spec template and source file template
• Write a few labs based on the specs
• Write a lab "best practices" guideline (slightly unrelated)

In addition, a change that will be made this semester is that the last few labs (or at least some labs) will be written from scratch. A complaint I heard was that CS240's labs were hard to deal with, since many of them were written from scratch. This is a silly problem, and students should be learning how to build a program from the ground up.

Grading is also a worthy problem to address; there is no standard for TAs to grade by, which leads to a natural unfairness in the lab grades. I think expecting the lab author to also create a grading rubric is reasonable, and should help TAs grade more fairly and more quickly. If labs are able to be script-graded, I would expect the TA to write a script for it as well.

Another aspect of grading comes in how the student sees how he or she did, and what went wrong. Traditionally, when us old people took it, TAs would print out labs and hand them back; I tried this last semester, and it was a bit cumbersome to manage all of the paper (and wasteful, in my opinion). CS158/9 had its TAs mail students back with comments, which I thought was a better idea, but the way they had us do it kind of sucked.

For the TAs, I think the improvements for a major part seem to boil down to scripting. I imagine Python scripts could be handy for writing grading scripts, among other things. For one, the best way to generate a uniform HTML page for the lab spec is probably to parse some markup that generates the HTML for you, rather than force everyone to hand-edit a bunch of HTML. Or maybe I'm just deluded. Python could probably make a lot of things easier, but more on that later. Hopefully.

Comments on any of the possible changes are quite welcome, as I'm kind of rambling.

CS180: Editors and IDEs?

For some reason, we started using jEdit as our official editor in CS180, since apparently our students weren't hax0r enough to handle Vim or Emacs (we stopped using Eclipse as well, for some reason that I don't really know). Looking back over the past few years, I wonder if jEdit is such a good choice. They tout themselves as a "programmer's text editor," but I think it sucks. We have 25 [apparently theoretically] identical computers in the CS180 lab, but jEdit does wacky stuff like behave really oddly if num lock is on (or off, one or the other), not syntax highlight properly on some computers, etc.

I'm hoping that as the next head/lead/whatever TA, I can persuade the course administrators to change the editor, if I want, but I'm not entirely sure what I would suggest using. The options seem to be:

• Vim
• Emacs
• Pico/Nano
• Eclipse
• IntelliJ IDEA
• NetBeans

Some of these options are laughable (if you ask me, anyway). Using vim or emacs as a main editor is probably still not a great idea; it would be wise to learn in CS180 anyway, but the warring of the two editors means some students would be learning one and some would learn another, as mandated by the instructing TA. This is probably a crappy idea, and students should try both on their own, since the USB has tutorials on both. Pico on lore doesn't have syntax highlighting; I don't really know why we don't use Eclipse (other than I think it can eat poop), IDEA looks interesting (but weaning new programmers on IDEs means they're going to have tons of fun in CS240), and NetBeans? Yeah...

I'm open to opinions, though I wonder if anything will ever come of it. Maybe I'm just posting so I don't feel so lazy.

Interested in teaching CS180?

It's high time I started working on stuff I said I would be working on (progress report: completed 0%). Part of said stuff requires finding enough TAs for CS180 next year. Anyone interested in teaching little freshies Java? Leave a comment if you're interested--I know at least a few of you are TAs. I need three more at least, more to buffer schedule conflicts.

Interested in helping with CS180 but not so interested in teaching/grading? CS180 also needs evening consultants (4-6, maybe more), and I currently have none. Work is usually 3 hours per session. Check the now-outdated CS180 website for example schedule.

More to come about CS180 later, when I'm not lazy or at work.

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.