Comparing Software Carpentry to CS Principles

This post originally appeared on the Software Carpentry website.

A lot of new educational initiatives in computing have sprung up in the past couple of years, ranging from Mozilla's Hackasaurus to the UK rethinking its grade-school curriculum. One of the biggest is the "Computer Science: Principles" project in the United States, which, with backing from the National Science Foundation, is trying to re-define the high school Advanced Placement course. They have some well-grounded ideas about what should be taught and why; how does Software Carpentry compare?

To make the long story below short, Software Carpentry is tackling a subset of the ideas and issues of CS Principles. I originally wrote, "the purely technical subset", but that's not quite right: we do look at communication and collaboration in software teams, at producing information for human consumption, at the aesthetic aspects of programming, but only insofar as these affect correctness and productivity. One reason is that our learners have much less time to devote to this than high school students have for a year-long course. Another is that we're not tasked with shaping young citizens in the way that public schools are, so communication skills and considerations of societal impact aren't our concern. I don't think we cover any big ideas that CS Principles doesn't, which is actually encouraging: if we can hang on five or ten years, we might be able to assume that most of our learners are already familiar with the big ideas, so that we can concentrate entirely on "how".

Computational Thinking Practices

Connecting Computing to society, innovation, and everyday life: not a focus for SC, although we try very hard to connect things to scientific research and researchers' everyday needs.
Developing computational artifacts (which includes writing programs), and applying computing techniques to creatively solving problems: yes.
Analyzing problems and artifacts by applying aesthetic, mathematical, pragmatic, and other criteria: I'd like to see more in Software Carpentry on things like code review, but I don't think we need anything more on algorithm analysis or the like.
Communicating: not really our focus, but we hope that teaching people how to generate web pages, produce and consume RSS feeds, and so on will make communicating easier and more effective..
Working in Teams: also not directly our focus, but again, we hope that teaching people things like version control will help them collaborate.

Big Ideas

Ours are described in two recent posts. CS Principles lists these:

Computing is a creative activity: we says "computing is a human activity", which isn't quite the same.
Abstraction reduces information and detail to facilitate focus on relevant concepts: we say "programming is about creating and composing abstractions", which isn't quite the same.
Data and information facilitate the creation of knowledge: we don't have an explicit equivalent.
Algorithms are used to develop and express solutions to computational problems: well, yeah.
Programming enables problem solving, human expression, and creation of knowledge: I'm not sure this is a "big idea" in the same sense as the others; we don't belabor it, since we think that most scientists already get this.
The Internet pervades modern computing: ditto.
Computing has global impacts: ditto.

Learning Objectives

The student can use computing tools and techniques to create artifacts: agreed.
The student can analyze computational artifacts: we don't do this, but should.
The student can use computing tools and techniques for creative expression: I think this is just a stronger restatement of objective #1.
The student can use programming as a creative tool: ditto.
The student can describe the combination of abstractions used to represent data: this is the realization of our "it's all just data" big idea, so yes.
The student can explain how binary sequences are used to represent digital data: I think this is just a particular instance of #5 above.
The student can develop an abstraction: we fold this into #1—in order to develop artifacts (programs), Software Carpentry learners are going to have to develop and understand abstractions.
The student can use multiple levels of abstraction in computation: as above.
The student can use models and simulations to raise and answer questions: this is a big goal of our course.
The student can use computers to process information to gain insight and knowledge: again, this is a big goal of our course.
The student can communicate how computer programs are used to process information to gain insight and knowledge: we'd like our learners to be able to explain what they've learned to others, not least so that they can run workshops of their own, but it's not a priority.
The student can use computing to facilitate exploration and the discovery of connections in information: as with #9 and #10.
The student can use large datasets to explore and discover information and knowledge: as above.
The student can analyze the considerations involved in the computational manipulation of information: the discussion makes it clear that "considerations" means "tradeoffs", so yes, this is something we'd like our learners to be able to do.
The student can develop an algorithm: if you think that every program is the embodiment of an algorithm, then yes, of course, but if you mean "can derive quicksort on their own", then no.
The student can express an algorithm in a language: yes, of course.
The student can appropriately connect problems and potential algorithmic solutions: specifically, this means that learners can
- identify problems that can be solved in a reasonable time;
- explain why heuristic approaches are necessary to solve some problems in a reasonable time; and
- explain how some problems cannot be solved using any algorithm.
We have explicitly not included this in Software Carpentry, as our experience has been that there's nothing substantive we can teach in the hour or two we'd be able to devote to it that would actually make a difference. Given more time, though...
The student can evaluate algorithms analytically and empirically: I agree it's important, but it's not really our focus—we are definitely not trying to cram an entire CS degree into a short course.
The student can explain how programs implement algorithms, e.g., explain how instructions are processed: this should be in Software Carpentry, but isn't right now.
The student can use abstraction to manage complexity in programs: again, I think learners have to do this to build the artifacts we ask them to build.
The student can evaluate a program for correctness: we should do more of this.
The student can develop a correct program: I hope so.
The student can employ appropriate mathematical and logical concepts in programming: not really—we don't touch on things like pre- and post-conditions, invariants, and the like because we're teaching the craft of programming rather than the science of computing.
The student can explain the abstractions in the Internet and how the Internet functions: not currently part of our core, because we don't think we can teach people enough about web programming in a short course to let them do anything except create security holes. I'd be very happy to be persuaded otherwise...
The student can explain characteristics of the Internet and the systems built on it: as above.
The student can analyze how characteristics of the Internet and systems built on it influence their use: as above.
The student can connect the concern of cybersecurity with the Internet and systems built on it: as above.
The student can analyze how computing affects communication, interaction, and cognition: out of scope—though I hope we're preparing learners to hear what people like Cameron Neylon, Michael Nielsen, and Jon Udell are saying about this.
The student can connect computing with innovations in other fields: not us.
The student can analyze the beneficial and harmful effects of computing: as above.
The student can connect computing within economic, social, and cultural contexts: as above.