Category Archives: Education
This is the the last of three posts on the course I regularly teach, CS 330, Organization of Programming Languages. The first two posts covered programming language styles and mathematical concepts. This post covers the last 1/4 of the course, which focuses on software security, and related to that, the programming language Rust.
This course topic might strike you as odd: Why teach security in a programming languages course? Doesn’t it belong in, well, a security course? I believe that if we are to solve our security problems, then we must build software with security in mind right from the start. To do that, all programmers need to know something about security, not just a handful of specialists. Security vulnerabilities are both enabled and prevented by various language (mis)features, and programming (anti)patterns. As such, it makes sense to introduce these concepts in a programming (languages) course, especially one that all students must take.
This post is broken into three parts: the need for security-minded programming, how we cover this topic in 330, and our presentation of Rust. The post came to be a bit longer than I’d anticipated; apologies!
This is my second post on UMD CS’s programming languages course, CS 330.
We introduce Ruby and OCaml as exemplars of dynamic/scripting and functional languages, respectively, in the first half of the course. I described these in the first post. This post covers the third quarter of the course. This part goes over technologies that underpin a language’s design and implementation, in particular regular expressions, finite automata, context-free grammars, and LL-k parsing. It also looks at the lambda calculus as a core model of computation, and operational semantics as way of precisely specifying what programs mean. The last part of the course discusses the basics of software security and coding strategies for avoiding various vulnerabilities. I will dedicate a separate post to these last topics.
I’m very curious for your feedback on the course overall. I welcome suggestions for improvements/adjustments to the content!
Computer science is wildly popular at Universities right now, owing in no small part to the robust job market for CS graduates. This market is driven by the voracious appetite of businesses and the public for “tech.” A consequence of increasing CS popularity is the substantial growth of CS course sizes. Such growth presents a significant challenge to instructors of those courses, as the number of CS instructional staff have generally not scaled linearly with the number of students. How can we teach many more students with roughly the same number of instructors but without a (substantial) reduction in overall quality? One part of my answer to this question is: “clicker” quizzes.
I recently blogged about CMSC 330, the undergraduate programming languages course I (co-)teach at the University of Maryland. That post focused on the content of the course. This post considers the more general question of how to deliver a computer science course at scale, focusing on the lecture component and a key piece of my approach: the use of clicker quizzes during class. I’ll consider other aspects of large course management — student Q&A and grading — in a future post.
I often have the pleasure of teaching UMD CS‘s undergraduate programming languages course, CMSC 330. Taken by every sophomore in our program, it has evolved into a pretty interesting course, and I find myself talking about it with various people I meet. As such, I thought it might be worth writing down what it’s about, in case others might also find the course (or elements of it) interesting or its materials useful. (Most of the course’s materials — lecture notes, projects, exams, homeworks — are freely available at the course homepage.) There is too much to say for one post, so I’ll break it into three parts. This post covers the overview and first 1/2 of the course, and the second post will cover the third quarter, and the last post will cover the last quarter while also making some broader connections.
This year I was pleased to be named one of U. Maryland’s Distinguished Scholar-Teachers (DSTs). This recognition, awarded to a few UMD faculty each year, is given to those who have shown success both in teaching and research. I put a lot of energy into both of these activities, so it was a great feeling to be recognized as a DST.
One of the consequences of accepting the award is that you must give a lecture about your research/interests to a general audience. I gave my talk, titled From ‘Penetrate and Patch’ to ‘Building Security In’, on Monday.
My Department Chair, Samir Khuller, a DST himself, told me that I should aim the talk for an eighth grade level, i.e., an audience with only a cursory understanding of computer science. But of course it’s not quite that simple: only some people who attend will be at that level; many who attend will have a stronger background because they will be interested in the topic. So as I was preparing my talk last week I tried to make it so the generalists would not get lost, and the specialists would not get bored.
The point of my talk is that our cybersecurity woes are often (but not always) due to vulnerable software. While firewalls, anti-virus, and other security products stem the tide of attacks, these products are not addressing the root problem. Once software vulnerabilties are discovered they can be patched, but this “penetrate and patch” approach is not working: unpatched systems remain vulnerable, and even when they are the patched there are probably other latent vulnerabilities that remain. “Penetrate and patch” also doesn’t address the new vulnerabilities that are introduced as the software evolves.
So we need shift our mentality to building security in: We should aim to build software that is free of vulnerabilities (or far more likely to be free of them) right from the start.
To get this idea across to a general audience I used bridge-building as a motivation: We use the best designs, methods, and tools to build bridges that stand up to heavy use and extreme conditions. Then I talked about what software is — basically how it works — and how some software bugs can be exploited to deleterious effect. I showed, at least at a high level, how a buffer overflow works. Then I showed how language design and other PL-style research products are analogous to the best tools and methods of bridge-building, and can therefore help us avoid buffer overflows and other problems. I also described how — through my coursera software security class and the build-it, break-it, fix-it contest 1 — I am trying to encourage this mentality of building secure software from the start, not just leaving security to the last.
I am pretty pleased with how it turned out. Because of having to account for a broad audience, I spent a lot of time on the talk — probably as much as I did on my tenure/promotion talk! My in-laws were in attendance and they told me they understood things pretty well, and that the talk put the trajectory of recent security breaches in perspective.
A link to a video of the talk and slides is here (the proper talk starts at about the 3-minute mark):
The audio isn’t great, and the slides are a little hard to see (but there’s a link to the PDF), but I think it’s watchable. I’d be very curious for your feedback. I hope you will share the link with friends, tech-savvy or not, who might wonder what this cybersecurity stuff is all about, and how PL research and methods can play a important role in addressing it.
- The next iteration of the contest starts Thursday, October 1 — not too late to sign up! ↩
During my tenure as a student and professor, I have been to many talks offering career advice to graduate students. Most of these talks focus on careers in research universities and industrial research labs, and leave out discussion of institutions, such as liberal arts colleges, that are primarily concerned with undergraduate education. This is unfortunate because many liberal arts colleges are highly selective institutions that offer exciting careers that mix research and teaching, albeit in a different way than careers in research universities.
One way to reduce the information deficit about liberal arts colleges is to report on the experiences of those who work at one. This is what we do in the present post. Specifically, I interview Steve Freund, who is a professor of computer science at Williams College, ranked by US News as the top liberal arts college in America. Steve is a highly successful PL researcher, known for his significant contributions to the analysis of concurrent programs. As a result, he is in a great position to give PL Enthusiast readers a view into what it’s like to be a teacher and researcher at a liberal arts institution. Continue reading
Earlier in the summer I discussed a security-oriented programming contest we were planning to run called Build-it, Break-it, Fix-it (BIBIFI). The contest completed about a week ago, and the winners are now posted on the contest site, https://builditbreakit.org.
Here I present a preliminary report of how the contest went. In short: well!
We had nearly a dozen qualifying submissions out of 20 or so teams that made an attempt, and these submissions used a variety of languages — the winners programmed in Python and Haskell, and other submissions were in C/C++, Go, and Java (with one non-qualifying submission in Ruby). Scoring was based on security, correctness, and performance (as in the real world!) and in the end the first two mattered most: teams found many bugs in qualifying submissions, and at least one team was scoring near the top until other teams found their program did not pay much attention to security.
We have much data analysis still to do, to understand more about what happened and why. If you have scientific questions you think we should investigate, after reading this report, I’d love to know them. In the end, I think the contest made a successful go at emphasizing security is not just about breaking things, but also about building them correctly.
In the computing stack, PL sits between algorithms and systems. Without algorithms to implement or computer systems to run them on, there would be no need for programming languages. However, the research communities that study algorithms, PL, and systems don’t really have much of an overlap. This is perhaps unavoidable: computer science is now a mature field, and researchers in mature fields tend to pursue specialized and technical research questions.
At the same time, it seems important that the approaches — assumptions and methods — of different subfields of computing be compatible to some extent. At the end of the day, computer science aims to produce solutions for the whole computing stack. An “impedence mismatch” between its subfields compromises our ability to come up with such end-to-end solutions.
This suggests that the comparative study of assumptions, techniques and cultures of different CS fields (a sort of “comp lit” for computer science) is potentially valuable.
Personally, I have always been intrigued by the relationship between the fields of programming languages and algorithms. In this post, I discuss similarities and differences between these two areas, and argue that their synthesis could be interesting for both research and teaching.
A couple of months ago, we posted about the research program of SocioPLT, whose goal is to study why some languages get adopted more than others. As part of a study, the investigators ranked languages according to their frequency of use in Sourceforge projects during the period 2000-2010. An interesting finding was that among the top 20 languages in these rankings, there wasn’t even one functional language.
Academic PL researchers tend to love functional programming, so many of us would find this fact depressing. However, it seems that we academics are at least partly to blame for this state of affairs. For functional programming to be embraced in the “real world”, universities must teach it. In this post, I show that few universities do. In particular, functional programming is a significant part of the core programming sequence at only 9 of the top 33 American schools, and is not offered at all in about 40% of these schools. Continue reading