The University of Chicago’s Independent Student Newspaper since 1892

Chicago Maroon

The University of Chicago’s Independent Student Newspaper since 1892

Chicago Maroon

The University of Chicago’s Independent Student Newspaper since 1892

Chicago Maroon

Aaron Bros Sidebar

Computer crash course

Introductory computer science sequence drowns students in theory and then blindsides them with practical work.

My major is harder than your major. That claim is made a lot at this University, but I think it’s probably true in my case. I also have to clarify that this isn’t a point of pride for me—I wish it were otherwise. But I’m a computer science major, and thus all too familiar with the practice of turning introductory courses into a crucible to “weed out” anyone in the bottom X percent.

This is in conflict with the basic goals of education: to teach us how to learn and to prepare us for the more complicated material ahead, so that we may actually master it. For premed programs, at least there’s the justification that there likely aren’t enough spots within the profession for every first-year premed, but computer science is a very accessible industry. Everyone has access to the Internet, anyone can learn how to code, and when they do they can command a high salary without a degree, purely on the basis of their technical knowledge.

And yet, given this massive potential for widespread accessibility to programming, our computer science curriculum completely squanders it. At the beginning of fall quarter, my introductory honors computer science class—no prerequisites—was overbooked with more than 70 students. Only 42 remained enrolled in the sequence the following quarter. The professor had that rare combination of genius, experience, and teaching talent, and the students were eager to help each other learn. So what went wrong?

Well, first of all, it didn’t actually introduce us to programming. This isn’t in itself a completely bad thing: It does avoid giving an advantage to those who had already programmed before. The professor decided to teach us a programming language that was sure to be completely different from anything we had ever encountered before. Called Haskell, it was a functional language based entirely on lambda calculus, eta reductions, and lazy evaluation. If you don’t know what any of these words mean, it’s basically a way to write as little explicit code as possible by leading the computer to infer an astounding number of things about how to process your code. Homework and projects, while requiring about 5 percent of the code (the correct answer was often the perfect one-liner) that would’ve been needed in another language, took 500 percent of the time. There is quite a bit of value in learning the theory behind Haskell, but in practice the difficulty of the course led to four people, at most, in the entire class learning Haskell well enough to continue using it in their programming careers. The rest forgot it and never looked back, and many dropped out of the sequence altogether.

While the first quarter was more of a theoretical computer science class than an introductory programming class, the second quarter of the intro sequence was the exact opposite. And this is where not really learning programming in your first quarter becomes a problem. In a few short months, we covered and programmed in Python, C, HTML, XML, turtle graphics, Flex, Yacc/Bison, and XSLT. The mile-wide, inch-deep approach was only possible for me to handle because I had already been coding for many years and knew how to deal with new languages. For those who were truly new to programming, it was absolute hell—in no small part because they had no experience actually installing and getting programs in so many different languages to actually compile and execute on their computers, something that was never covered in class. To anyone taking that class with a Windows computer: I’m sorry.

The implicit requirement that students in this sequence already know how to code, despite the course having no prerequisites, is even more apparent when we consider that 40 percent of every student’s grade was based on a class wiki. The wiki was supposed to serve as a forum where we would post and solve one another’s programming assignments—which we were expected to make up on our own, because we presumably already knew how to code—and be graded on how much work we did relative to everyone else.

Since there was no limit to how much work we could throw up on the wiki, and getting an A in the class was not dictated by a cutoff but rather by your performance relative to your classmates, you had to make the wiki your life. That meant spending 10 to 30 hours a week productively writing “interesting” code, aside from the rest of the coursework (which was quite time-intensive, I assure you), not to mention work for your other classes.

For someone like me, who was working several part-time software jobs and could just post whatever problems my employers asked me to solve and the code for them—and thus effectively get paid to work 60 hours a week on the class wiki, this arrangement was just dandy. Of  a similar opinion were those who had been programming for a long time and had several years of their own code written for previous classes or employers just lying around. The “intro” students with no such advantages, for whom this class was supposedly made, were doomed to a less desirable grade from the get-go.

To recap, the honors introductory computer science sequence has no programming experience requirements, the first quarter is a theoretical computer science class that doesn’t really teach any programming so that those with experience don’t have an advantage, and it’s almost impossible to get an A in the second quarter unless you’ve been coding since junior high. There are very intelligent students who make it through the first quarter of the sequence only to be completely blindsided by the second.

This structure is absolutely FUBAR (look it up). Please, please! At least switch the order of 161 and 162 so that students are programming from day one and have a reasonable indication of whether or not they have the background necessary to complete the sequence. For those who can spend a quarter without programming and still enter the major prepared on the basis of their previous knowledge, 161 is a really interesting class taught by a truly remarkable instructor. But students don’t find out until 162 whether or not their previous knowledge is enough to complete the major. With advance warning, maybe more than two-thirds would end up actually completing the sequence.

David Grossman is a first-year in the College.

Leave a Comment
Donate to Chicago Maroon
$800
$2000
Contributed
Our Goal

Your donation makes the work of student journalists of University of Chicago possible and allows us to continue serving the UChicago and Hyde Park community.

More to Discover
Donate to Chicago Maroon
$800
$2000
Contributed
Our Goal

Comments (0)

All Chicago Maroon Picks Reader Picks Sort: Newest

Your email address will not be published. Required fields are marked *