Building a ship in a bottle

Lately I’ve been having a lot of discussions with people about Computer Science education. Everyone I’ve spoken with is passionate and excited about broadening the reach of CS education, which is really exciting to me: it’s exactly what I want to help with. One thing I’ve been frustrated by, from time to time, is not having a common understanding of what Computer Science education is. I’m not going to say I have the one true definition, but I thought I’d document my thoughts on it so that folks know what my perspective is.

One boon for marketing CS education is that everyone has an amazing supercomputer in their pocket, which can (and often does) run amazing programs; immersive games, augmented reality planetariums, music instruments, social media, and on and on. Being able to say to someone “I can teach you how to make these things and more – only limited by your imagination” is a great lure. It’s also misleading, and here’s where my analogy comes in. I think a smartphone and all of its apps are a lot like a phenomenal Ship in a Bottle. Offering to teach someone how to make an App is a lot like teaching someone how to make a ship in a bottle, without teaching them how to make a ship outside of a bottle first. Sure it’s possible, but it’s missing out on a number of opportunities:

First, you’ll never be able to make better looking ships in a bottle than you can outside of a bottle. If you want to innovate – make new, cool things that have never been seen before – you should experiment making those things outside of a bottle first, then once you’re happy with them, figure out how to get them assembled inside of a bottle.

Second, to have any chance of getting a novice shipbuilder to make anything they’ll consider acceptable inside of a bottle, you’ll have to give them a lot of parts pre-made, already in a form that can be put in a bottle. After your lesson, if they want to reproduce the experience at home, they’ll have to start with the same parts, which are essentially ship in a bottle kits. If those kits aren’t available, they’ll have to figure out how to back-fill the knowledge to construct them.

Third, and this is where the analogy stretches its limits, if bottle technology changes, the kits immediately become obsolete, and only folks who know how to build these things from scratch will have any chance of keeping up with technology.

For me, the notion of building a ship in a bottle is very much like getting a program to run on any computer, not just a smart phone. Taking a high-level idea of a game, an application, a musical instrument, and turning it into the 1’s and 0’s of the machine code for a specific computer, is a lot like building a ship in a bottle. Computers are crazy time-and-space dilating machines that require processes be expressed in very specific ways (the machine code), and when they are, those processes run at almost-unimaginable speed.

Teaching someone “game coding” using a high-level framework is akin to giving them a Ship in a Bottle Kit, and maybe even a bottle with a hinged bottom. After the class, if you give them a real bottle and raw materials, (no framework), they won’t be able to reproduce that experience.

I’m not saying these experiences are bad at all. In fact, I think they’re great for giving students a sense of “here’s where we’re headed,” and “cool stuff is possible.” But if the only focus is on using kits, students will be fundamentally unprepared for the world where computers, operating systems and languages change with a 3-5 year cycle.

So, what am I advocating?

Teaching someone how to build a ship outside of a bottle includes:

• Teaching them about how all computers work, all the way from gates, through logic and memory, up to machine code,
• teaching them about decomposing big problems into smaller steps, and assembling those steps into solutions, and doing so in the context of actually solving problems,
• teaching them about algorithms: use, implementation, analysis (Big Oh)
• teaching them about abstraction: using and creating your own,
• … and more. I think this is very much aligned with the current notions of computational thinking, and the recent AP CS principles curriculum.

An example I particularly like is Google’s CS Unplugged, which is an extreme example of learning about computer science concepts outside of the bottle of computers. Their activity with a Binary Sorting Network can be done on a playground with chalk, and blows kids’ minds when they come out sorted, regardless of what order they start with.

Systems like MIT’s Scratch might seem too much like a ship in a bottle kit in my analogy, but in my (admittedly limited) experience, once a student gets Scratch, they understand programming in a fundamental way. Scratch turns syntax – the icky, in-the-way stuff about programming – into a puzzle-assembly problem, so the students can focus on what they want to express. Later, when they are ready for textual-based programming, the syntax of those languages, when laid out with discipline, actually looks a lot like the similar Scratch program. Brilliant design on their part. The key to making this work is to keep the students exploring, make sure they keep learning from cool projects they like on the website, until they can pretty much create anything they want.

When teaching programming, I wholeheartedly recommend (when possible) teaching more than one language in a short duration. When I took Intro to CS at UC Berkeley (in 1984!), they taught us Scheme and C in the same year. Looking back on the experience, I think it was really clever: I learned the things that are fundamentally the same between the two, and also the things that are way better in one than the other. Choice of language is a choice of tool, and Mr. Natural’s “get the right tool for the job” was drilled in to me by my hippie dad from an early age.

While it’s totally okay to teach “writing Apps”, or “coding webpages”, it’s important to realize and advertise the limitations (and strengths) of these approaches. Knowing how to “code a webpage” was a lucrative skill in 1999, but quickly became irrelevant as Web technologies advanced. Similarly, we’re way past the time when simply writing an App and uploading it to Apple or Google is the road to a career. The role of teaching these things is to give an early glimpse at what’s at the end of the journey of a CS education. The peril of only using those approaches is that you’re on a never-ending treadmill of needing to take the next class when a new framework or web technology takes over, making your previous skills irrelevant. To stand the test of time, classes like this should include  fundamentals of usability and visual design, not just HTML, CSS and Javascript. On the games side, spend some time investigating what makes an activity fun, not just how to animate sprites using frameworks. Bonus points, on the games side, would be to include learning principles of physics, using a physics simulation framework.

One quote that resonates with me, often misattributed to Edsger Dijkstra, is “computer science is no more about computers than astronomy is about telescopes.” I think this quote may have been mis-used to try to push CS into Math departments, and is at odds with the accurate observation that the pre-eminent professional society dedicated to CS is named The Association for Computing Machinery. I think it’s safe to say that CS is something new: we spend too much time arguing about whether it’s a science, a branch of mathematics, an engineering discipline, or a vocational discipline – it’s all of those things. If you leave any aspect out, you’re missing out on something. Combining them isn’t easy, but if we manage to do it, we’ll be totally surprised at the kinds of things future generations will be building in these amazing bottles.

I’ve got a lot more to say on the subject of CS education, and even about the analogy (compilers are like CNC machines-in-a-bottle), but I’ll stop here for now.

Addenda: less than a week after writing this, I received the latest issue of CACM, and in it was a nice piece titled “Misconceptions About Computer Science.” I think there’s a lot of overlap in philosophy, and I’ve also got some stuff to learn from the authors who have been thinking about these issues for longer than I have, but I was encouraged.