How to crush it in COMP 105

Four years ago, I took COMP 105 (Programming Languages) in my last semester at Tufts, and the first half of that class almost torpedoed my whole final semester into disarray. I was regularly starting the projects for the class late and working on them solo, a lot of the more theoretical questions on homework went unanswered, and any time I caught up in 105, I fell behind in my other classes. All-nighters were both frequent - and ineffective.

Despite how the first half went, the second half was an epic rebound to the proudest C I've ever gotten on something, and 105 turned out to be incredibly useful for learning new languages. You really can get a lot out of 105 even if you have no plans to be an academic, so I'm writing this blog post to give some tips on how to get the most out of this class and become an excellent polyglot programmer. The tips all seem pretty obvious, but I saw firsthand that following them was pivotal to changing 105 from a nightmare class to one of the coolest classes at Tufts!

Talk to everyone

Easily the #1 piece of advice I've got for anyone in 105 is to talk to everyone who has something to do with the class. The biggest mistake I made in the beginning of 105 was that I didn't start doing pair programming on 105 projects until after the midterm. As a result, it took forever to understand the material and I couldn't finish most of the assignments, leaving quite a few questions unanswered with no credit. Talking to everyone, however, was the crown jewel of my mid-semester comeback.

While COMP 40 is considered the pair programming class in Tufts CS, I would actually say 105 is more deserving of that title. 40 has long assignments, but not much theory, so a 40er could solo pretty much any of COMP 40's projects with a few extra hours. 105, on the other hand, is more theoretical and has more new concepts to delve into, like operational semantics and the theory behind type systems. Because of that, in addition to a second set of eyes for faster bug-spotting, pair programming adds a second person to think about the concepts with and trade ideas. That'll more than double the speed of you and your partner mastering the material and figuring out how to finish the projects as your two brains throw the wrong ideas at each other until they turn into the right ideas.

Besides pair programming, “talk to everyone” also applies with showing up at Halligan for TA and professor office hours. The TAs are all former 105 students, and unlike in 40, they answer questions from everyone at once, rather than one programming pair at a time. As a result, when I started going to office hours I was getting answers not only to my own questions, but also hearing answers to other people's questions, which were in my blind spots. Not to mention, by going to TA office hours you'll get to know more of your fellow Tufts CS students, so that's another win.

WARNING: While communication was key to doing well in 105, make sure you read up on the academic integrity rules for the class! The big ones I can remember are that you can't show your code to anyone else or read anyone else's code, and you have to cite anyone you shared ideas with when you send your homework in, but obviously, follow all the rules so you have a clean transcript.

Keep up the habits from 40

If you already took 40, basically anything that helped you succeed there also works in 105. As I mentioned, pair programming and working in Halligan consistently save you a lot of time. Besides that, there's a big takeaway from COMP 40's design documents. They're not part of your grade in 105 like they were in 40, but in 105 (and on the job), taking the time to clearly specify what you want your code to do is a “secret sauce” to rival the peanut sauce from Stir Fry Night at Carmichael. That planning helps as you're thinking about how to solve the problems on the project and figuring out whether or not your code works. If you haven't taken 40 yet, you can also get in the habit of specification by getting your feet wet learning test-driven development (TDD). Many popular languages have frameworks for that, like JavaScript (Mocha), Go (standard testing library), and Ruby (Minitest). Knowing TDD, by the way, also happens to be a great skill to have for coding on the job!

Another important habit 40 taught was to document your code well. Documentation is part of your grade on 40 and 105's coding assignments, so if anything it gives you more points. But like with specification, it forces you to think more about the code you're writing during the period of time where you're stuck figuring out how to make it work. Moreover, if you can only get some parts of a programming problem solved, documentation will help the TAs understand what your thought process was as you were writing your code.

Finally, the design documents and pair programming in 40 made it really hard not to start early. In 105, as Norman said in the first lecture when I was there, starting early is more useful in 105 than in a lot of other classes. I'm totally with Norman on that; since a lot of 105 questions are theoretical, you'll want those questions to enter your head as soon as possible. That'll get your brain to start working on them, and you'll also figure out what you're stuck on so you can ask good questions at professor and TA office hours!

Read before lecture so you know what the experts are saying

Something else I found when I was in 105 is that any time I did the reading before class, I was able to follow along. If I hadn't done the reading beforehand, though, I would fall off the lecture about halfway through, which meant I had to do a whole lot more reading afterward to pound the ideas into my head. Even if the material doesn't make sense the first time you read it, it'll make more sense hearing it in class if you're seeing it the second time there.

If you're taking 105 as an undergrad, you'll probably be seeing a lot of the concepts in the class for the first time, like the theory and mathematical notation of how programming languages work, and how interpreters in those languages work to give you features like higher-order functions, type systems, pattern matching, and type inference. Your professor will be someone who really knows this material well, so you'll want to be able to follow along so you can learn the material from an expert. While it can be tough to find the time, if you invest in doing the reading ahead of time, you will have already wrestled with some of the theory and had it in your head going into lecture. Then even if you don't completely have the lay of the land on the material, you'll still be able to pick up where you left off.

Where to go after 105

Like I said at the beginning of this blog post, my favorite thing about 105 is that it sets you up to quickly learn any new programming language you want, and with so many languages popping up, it's a great time to do just that. I highly recommend learning more functional programming with the knowledge you will have gotten in 105 since it's getting popular even in imperative languages. On my job at Diffeo, which uses Go, our utility libraries include toolbelts of functions that take in other functions as parameters for actions like database interactions and caching. Functional features are also being added in newer versions of Java and C++, so functional programming is here to stay.

Haskell is the main language I recommend learning straight out of 105 because it has all the best features of Standard ML like pattern matching and type inference! Also, while Haskell is stereotyped as something only academics use, that's rapidly changing; startups like Helium, an Internet of Things startup, use Haskell in production, so if you thought ML's type system was cool, don't be discouraged by Haskell's reputation. You can check out the video below to hear about how Helium uses Haskell in production.

If you were new to functional programming before 105, this class also teaches you how to tackle new programming paradigms, so you can use that to learn concurrent programming, where you write code to do things simultaneously. Functional languages like Erlang and Elixir are natural fits for concurrency since they offer the safety of working with immutable data. But these days concurrency is becoming easier in imperative languages too. While pthread.h is a nightmare to work with in C, Go uses a “share memory by communicating” style for intuitive concurrency, and Rust's ownership system guarantees safety when working with your concurrent code, plus a sweet inferred, generic type system.

By the way, if you're gonna be at Tufts or close to Boston after 105, you're in a city with AWESOME programming communities. You can find a Boston group on Meetup for just about any language you want to learn, so you can meet professionals in your favorite languages, learn how to code in them like a pro, get your own projects off the ground, and even give tech talks. If you're learning a language, going to these meetups is a great way to really bring the language to life!

If you're in 105, while it'll be a hard class, the challenge will be worth it for becoming a polyglot programmer. Make yourself a regular at office hours, pair program, do the reading in advance, and do what you did to succeed in 40, and the class will get a whole lot easier, and you'll get more out of it. Best of luck, Jumbos, and stay slothful!