I spent a good chunk of time this summer working on my high school computer science program’s website. I did it partly because I love tinkering with web stuff, partly to work on WordPress skills going but mostly because I think it’s critical to my teaching practice.

Ordering my goals for the site helped me figure out how to organize things.  Here’s what I came up with:

1. Provide access to learning materials and assignments to current students (replace textbooks)
2. Empower students to interact with the content and each other
3. Allow parents to easily monitor their students’ learning and deadlines
4. Highlight student successes
5. Advertise to prospective students
6. Communicate with Seattle’s computing community
7. Provide access to materials for other teachers to use

When I visited schools in the area before committing to teaching, I was appalled to see a lot of old textbooks.  Sadly, public school budgets tend to only allow for new books every five to ten years which in a changing field like computer science is not always appropriate.  I decided that my courses would have to operate without conventional textbooks so that I wouldn’t feel chained to obsolete materials.  This makes a lot of teachers look at me as though I were crazy, but I find it freeing.  There are several free textbooks I pull readings from but mostly I rely on content made available by college computer science instructors.  I mix and match to meet the needs and interests of my students and they know to always look at the online calendar for their class to find out what we’re doing.

The biggest changes I made in the site’s organization involved making advertising more upfront.  I hope it can now serve as a communication tool with prospective students and the Seattle-area computing community.  I’m particularly happy with the ‘beyond the classroom‘ section which will allow me to highlight interesting internships, college classes, competitions, etc students are involved in.

Overall, students have responded very positively to having a mostly paper-free experience in my classes (I surveyed them about it).  As computer science instructors, I feel we have a responsibility to model effective leveraging of computing tools.  What better way than by establishing a web presence for our programs?

The Scratch interface.

Scratch provides a drag-and-drop environment for experimenting with programming and building sophisticated interactive artifacts.  Programming constructs are represented as blocks that can be dragged onto a scripts area to control the behavior of particular objects on the “stage.”  Scratch provides all the common constructs from imperative languages — definite loops, indefinite loops, conditionals, variables, etc.  It also provides a nice model for concurrency and message passing which are traditionally considered advanced topics partly because of prohibitively complex syntax but of course also because getting it just right is truly difficult.  Lots of niceties are included like ways of accessing mouse and keyboard events or producing sounds.

A big complaint about Scratch has been the absence of means of abstraction: message passing is the best way to get something subroutine-like and the world objects are independent instances with no way of capturing commonality.  In other words, there are no functions and there are no classes.

This lack of means of abstraction is a mixed blessing.  On one hand, if we consider one of the major concerns of computer science to be managing complexity, then the Scratch model really fails to provide exposure to a huge chunk of the field.  On the other, what we have now is an environment in which children and adults who retain a sense of childlike wonder truly can be expected to discover and create entirely on their own.  There are no hidden menus and nothing that really behaves any way other than what would be expected. That, to me, is very exciting, because it allows me to get my rambunctious 9th graders problem solving right away.

Now, thanks to Smalltalk programmer extraordinaire Jens Mönig and the vision of Brian Harvey from Berkeley, there does exist a version of Scratch with means of abstraction and it’s called BYOB.  I don’t know whether this is a measure of the excitement for the project or just of how much the WWW is still run by computer scientists but it currently comes out as result 6 for the search term ‘BYOB’ on Google, before songs and allusions to tasty beverages.  There also exist a pretty nice Scratch wiki page and a manual.

(I should note that lots of people will point to Alice as an example of a drag-and-drop programming interface that has always included abstraction through classes and methods.  I think there’s a lot in Alice that detracts from the problem solving experience including 3D reasoning, too much focus on animation details and lots and lots of bugs.  I’m also not a fan of teaching OOP early.  Basically, I don’t like it so I won’t say any more about it, but it’s worth checking out.  Similarly, Squeak is Scratch’s more powerful but less intuitive parent.  There are also several other Scratch spinoffs that offer some of the same functionality and more.)

BYOB brings higher-order functions, nested lists, recursion, type checking, nested sprites, a basic OOP model and other goodies to the Scratch world.  Clearly, BYOB is an extremely powerful tool that gives a better sense of what computing can achieve.  That said, I don’t think I’m going to use it for teaching.

I’m very excited about abstraction.  I find it thrilling to think that a bunch of ever-richer abstraction layers have gotten us from bursts of electrical current to Facebook and self-checkout machines at grocery stores.  I want to share that excitement and that sense of infinite possibilities with my students as much as possible.  I’m also a pragmatist (or is it a defeatist?) — I understand that many of my students have never been taught to think abstractly and are very limited in that domain.

What I think is fantastic about Scratch is that it provides a context in which programming is concrete.  We can focus on expressing ideas precisely and ordering their substeps which students in my intro class also often have very little experience with.  The results are immediate: a cat draws a square, the background flashes, etc.  That’s a skill set that will be useful to students no matter what they end up doing with their lives.  Sure, they don’t immediately dive into the big ideas of computer science, but they make significant steps in that direction.  I find it exciting when they discover limitations of Scratch and complain about them (“Ms. Maaartin, why can’t I just make lots and lots of cats from one blueprint?!”) because I find it a nice segue to more traditional programming languages.  BYOB ups the ceiling on what can be expressed but I feel that once one has a deep enough understanding to want things like anonymous functions and have a true need for them, a drag and drop interface gets in the way more than anything.

Creating an input to a custom block.

I found the interface for creating a custom block pleasantly straight-forward — someone has clearly spent a lot of time thinking about how to make a really quite complex idea relatively easy to work with graphically.

In this example, I chose to create a reporter block named ‘double’ and then hovered my mouse over it to get the option to add an input.  I clicked on the orange ‘+’ on the right and got the dialog box titled ‘?.’  By default, the dark gray advanced options are collapsed and the input is untyped.  When the dark gray box is opened, I can choose a type for the input and control its scope.  Again, lots of power here, but also a lot of need for instruction to get anywhere near being able to use it effectively and deliberately.

I was creating this very simple procedure so I could double the contents of a list.  Map is a custom reporter and it takes a function and a list (in this case an anonymous one) as parameters.  What the heck is a reporter and how is it different from a command?  Maybe my initial confusion shows my lack of education and I haven’t yet dug too deeply into exactly what’s going on, but it looks like a reporter is a first class procedure that returns (“reports”) something and so it’s treated as a value to be used as part of expressions.  That’s in contrast with a command which is directly executed and can’t be used as part of an expression.  What’s interesting is that a difference is made between ‘reporters’ and ‘predicates’ — procedures that return booleans but there’s no differentiation between integer, string or list reporters.  Not sure what the ramifications of that are.

Clearly, there’s an elegance to what’s going on here, but my wrist really hurts from clicking everywhere.  Part of it is that I’m learning as I go, but even doing all this as efficiently as possible requires lots of digging around in menus and clicking and dragging.  Of course, I may be biased because I tend to like tools that let me use the keyboard — command line, Emacs, LaTeX — they may be slower for basic, novice use, but they’re much faster for complex applications by power users.  I guess I kind of see most of programming as a power user type of action.  Scratch managed to provide a limited enough subset of programming that I could see it as a nice novice tool but now BYOB is going into a territory I’m less comfortable with.

BYOB takes a lot from languages like Scheme which are celebrated as teaching languages because their core is small but expressive.  BYOB may still have a small core, but with it comes the need to understand and use lots of different kinds of dialog boxes and menus and radio buttons.  With BYOB, it’s not just a matter of learning the syntax for a define statement, it’s a matter of knowing and understanding all of the clicks and decisions needed to create a procedure.  And there are a lot.

I feel like students who really understand the ramifications of means of abstraction will also understand that typing keywords can often be more efficient than using GUIs.  On the flip side, I suspect that students who just see a lot of pretty colorful icons and are excited to make things move around on the screen will miss the implications of many of the deeper concepts BYOB tries to convey and are likely to get confused and frustrated by all the clicking and menus.  To me, some of the million dollar questions are

• whether students get more excited about the pretty Scratch animations or by the pretty pictures generated through, say, the Racket “world” Teachpack which lets students create visual programs using function composition in a variant of Scheme,
• whether the knowledge students acquire through using a drag-and-drop interface like BYOB transfers to more typical languages,
• which of having to click around a whole bunch and having to memorize syntax and worry about parentheses or white space is less frustrating for novices.

It’s not clear that these can really be separated out and studied in any reasonable way or that anyone would be interested in doing such analysis without devolving into rants about when recursion should be taught but a girl can hope…

I’m curious to see more examples of BYOB used for instruction.  Dan Garcia and Brian Harvey have been using it to revamp Berkeley’s non-majors intro to computer science course and are calling their offering the Beauty and Joy of Computing.  This fall’s class is one of the 5 pilots for the proposed new AP Computer Science: Principles course.  I’ve heard of Josh Paley, great instructor from my former high school, using it with middle schoolers.  What else is out there?  What niche does it fill?

Bottom line: I challenge anyone who takes an objects-first approach to teaching introductory programming to provide an account of the order in which concepts are introduced tied to the CS principles they illustrate and to articulate reasons for their ordering based on cognitive load for the students (a paper reference will do, too).

I recently spent a deeply engaging and thought-provoking week learning about the TeachScheme curriculum with Kathi Fisler from Worcester Polytechnic Institute and Shriram Krishnamurthi from Brown.  Both have worked with the curriculum since its inception at Rice around 15 years ago.  During that decade and a half, they have contributed to incremental refinements and seen it taught at hundreds of high schools and colleges. My initial thoughts on the workshop can be read here; I’ve now been reflecting on the material for a few weeks and offer some higher level thoughts.

What’s your course’s underlying philosophy?

The authors of the TeachScheme curriculum note that “college is the only time in a programmer’s life when he is exposed to principled ideas on a regular and rigorous basis” [1].  Unlike most approaches to teaching introductory programming, which can be labeled as ad-hoc at best, TeachScheme is based on several ideas woven through all aspects of the highly-structured curriculum:

• Use of design recipes as a way to systematize the programming process and provide students with a starting point
• Testing as an integral part of programming
• Introduction of syntax only as needed to illustrate broader principles
• Use of an environment which provides error messages appropriate for a learner’s level

While these underlying ideas may seem fairly simple and language-agnostic, I think it quickly becomes obvious that they are not frequently followed in CS1 courses and more subtly, that many modern languages actually guide instructors away from them.

Take the focus on testing, for example.  A Java instructor might say “Aha, I’ll just introduce JUnit early.”  Unfortunately, understanding JUnit requires a lot of background knowledge on things like inheritance, static methods, reflection… sure, one could probably use it just fine by pattern matching, but I think that process takes away from the simple goal: figure out whether an algorithm does what it’s supposed to.  For a beginner, the challenge in testing should be figuring out appropriate test cases, not expressing them.  Worse even is that much of Java code, whether it’s object-oriented or not, includes changing variables and various kinds of output.  These make verifying whether a certain piece of code works as intended potentially quite difficult.

What about introducing syntax in a measured, systematic way?  That’s something I strongly value because I think students with lower computing self-esteem (girls and ethnic minorities) are particularly hard-hit by syntactic ambiguity.  A lot of my hot-headed boys will play around until they figure out how a particular construct works and not be phased if it doesn’t match their initial expectations but I’ve seen many girls think they were dumb simply because I hadn’t properly explained all the possible errors they might encounter in using a new syntactic element.

Most advocates of languages other than Java pounce on “public-static-void-main-string-bracket-bracket-args” as a prohibitively convoluted way of starting a program.  In practice, though it’s irritating and I hate having to introduce it without being able to give much explanation initially, I don’t find that particularly alarming for students — I have them learn it as an incantation and/or copy it and eventually they do understand all parts.  That said, I think the incantation is symptomatic of a broader problem of dependency: lots of constructs in imperative languages are interconnected.  For example, to have any hope of using an iterative construct (while or for loop), a student is going to need to understand the syntax for variable assignment and mutation (storing a value in a variable and changing it).  Even worse, to reliably use variables, a student will need to understand things about memory.  So many levels of knowledge and understanding are required that we can’t get to solving problems — we’re stuck with syntax and semantics.  Python, PHP, C and your favorite obscure imperative language all include these challenges.

Racket: a Scheme variant

As I mentioned in my last post on the workshop, the ideas which have guided the creation and refinement of the TeachScheme curriculum really resonate with me.  In fact, there’s a lot of overlap with the principles that guide my own instruction but I’m all too aware that I constantly make significant compromises.  For example, I don’t have students use formal testing methodology but I have them diff their output (both text and graphical) to expected output.  That’s certainly not as systematic or scalable as I would like.  Another example of a compromise is the previously-mentioned main method header — I accept that I’ll explain it throughout the semester but I still grind my teeth a little at night because of its initial lack of clarity.  My practice is peppered with these uneasy compromises primarily dictated by the fact that I teach procedural languages.

In contrast, the originators of TeachScheme have been unwilling to compromise on the underlying principles.  They are able to do this by using Racket, a variant of Scheme.  The language has been modified to reflect the needs of the curriculum.  For example, it has a check-expect function which can be used inline with other Racket code to compare the result of two expressions:

This makes testing functions simple and systematic.  I think the fact that the language and environment support this style of testing allows some great early conversation on a fundamental principle of computer science: algorithm correctness.

I’ve also attempted to use this trivial example to illustrate the design process emphasized by How to Design Programs, the free textbook that uses the TeachScheme philosophy.  Most approaches to teaching programming rely on showing lots of examples for students to learn from.  TeachScheme is based on the notion that ” implicit learning does not work well for the majority of students. Most students are not the type of learner who can extract abstract principles on program design from a series of examples” [1].  Instead, we should explicitly describe the process of going from a problem statement to a program.  In the example above, I’ve got a comment at the top that includes the types of inputs and outputs (the contract) as well as a short purpose statement.  Writing those comments and the tests were part of the design process.  Of course, this becomes much more meaningful when operating on more complex data such as lists of CDs:

I think the first thing to notice is that a complex data type is defined concisely using a struct at the very top.  There’s no need for a constructor or default values as would be the case if writing a corresponding class.  This enables the discussion of representing and manipulating fairly complex data without getting bogged down in syntax and concepts like mutation.

The three comments following the struct definition certainly look a little odd but they have their reason.  The first block is a “template” for writing a function that processes a CD.  This is an example of a technique used to reduce the “blank page anxiety.”  If a student writes this template, they can see that the only things that can possibly be done by a function that operates on a CD are manipulating its title, its count or its category.

The second comment block defines what a list of CDs is.  Again, kind of weird for those not used to functional programming, but it has its elegance.  There’s no need to define a new data type for a list of CDs, hence the comment status.  The cons function is used to build linked lists “on the fly.”  The comment is again used to reduce “blank page anxiety” and guide students who are getting lost.

The third comment block defines a template for what a function that consumes a list of CDs should look like.  Unsurprisingly, my total-stock function looks awfully similar to it.

I also wrote some sample data as well as a check-expect BEFORE writing the total-stock function.  With the framework in place, writing the function is very simple and verifying its validity is even simpler.  This may seem like a lot of work for a three-line function but it pays off as examples get more and more complex.  For example, take a look at a filesystem assignment.  I attempted it in an ad hoc manner and got bogged down in all the mutually recursive data definitions.  With the templates, I was done in no time.

Why isn’t it more popular?

Principles may be front and center, but TeachScheme is not a fashionable approach.  First of all, the functional programming paradigm is not very common.  A quick glance at the charts on langpop.com shows imperative and OO languages like Java, C, C++, PHP, etc at the top and functional languages like Lisp, Scheme, Haskell, etc, pretty low on the ladder.  That can be discouraging for students who hope to immediately be able to get an internship or write something that looks like a Windows native application.

Secondly, the signal to noise ratio in functional programming is very high.  In other words, programs are generally quite short, but every line requires deliberate thought.  I think that makes a lot of people shy away from it and treat it as harder than imperative programming.  Related to that, there’s a kind of inertia: if instructors learned procedural or OO languages first, it’s only natural that we’d be uncomfortable reaching out of our expertise, especially to something we have considered harder.  I think the sacrifice here is that although functional programming leverages existing math knowledge, algebra is already quite hard for a lot of people, thus not easily available for transfer.  I also think most people consider software in terms of what it does rather than what it computes and that lends itself better to imperative programming — do this, then change that, then call that routine, etc.

Unfortunately, I suspect the real reason TeachScheme isn’t more prominent has more to do with egos than with technical merit.

Scorn is not a good advertising tactic

Before going to this excellent workshop, I had heard of TeachScheme but generally not in a very positive light.  One of the other workshop participants summed it up in a way I really liked — “scorn is not a good advertising tactic.”  First of all, most of the functional programmers I’ve known, from high school and beyond, have been incredibly brilliant and unwilling to suffer fools, otherwise known as people-who-program-in-PHP-omg-that’s-a-disgusting-language — people like me.  As a result, I was, as many people are, mostly intimidated by functional languages.

Then, there is an aura of religious zealotry and inflexibility around the TeachScheme materials.  I think a lot of people feel threatened by the vague “if you don’t think this is the right way to teach intro CS you are dumb” vibes exuded by the project.  I don’t know quite where those come from, but I don’t think I’m the only one who has felt them.

My next steps

I’m going to be using the TeachScheme curriculum in the fall with my advanced AP class composed of students with some prior programming experience.  I think they’re a good group to focus on principles with because they have enough background to grasp the implications of these principles.

I’m a little more willing to compromise, though, and I’m not ready to make a complete switch.  That said, I think I can be more deliberate about using a lot of the principled ideas in my procedural to OO classes in Java and Python.  It’s also become even more clear to me that starting with objects first is not of interest to me — I think the sacrifices are too great.

Above all, I’m going to continue my search for a single other coherent approach to teaching introductory programming which has gone through such methodical review.  I’m disappointed not to have found any; pointers would be appreciated.

1. M. Felleisen, R. Findler, M. Flatt, and S. Krishnamurthi, "The structure and interpretation of the computer science curriculum," Journal of Functional Programming, vol. 14, iss. 04, pp. 365-378, 2004.

Inevitably, teaching programming requires a choice of language and then of development environment (IDE).  Although I tend to think that good courses can be taught in a wide array of languages and IDEs, it’s clear that some will make teaching and learning easier than others.  I’ll even go as far as to say that I believe a teacher can improve his/her effectiveness simply by taking the time to deliberately decide what’s important in an IDE and then choosing between different options based on his/her criteria.  In my Java-based courses, I like to use jGRASP and eventually introduce Eclipse.  My criteria for selection:

1. Has a small learning curve
2. Does not hide anything major from students (main method as program entry point, for example)
3. Offers basic debugging support (establishing breakpoints, seeing variable values)
4. Allows students to easily transfer source files between computers
5. Runs on any operating system students are likely to have at home

There are several things others may be interested in that are NOT criteria for me:

1. Is a “professional” environment (each company has its idiosyncratic setup, I don’t care to teach apps and I trust students can learn on their own)
2. Provides code completion
3. Provides code/algorithm visualization
4. Allows for easy applet creation

I’ll start by briefly discussing the two IDEs I prefer and then give some of my insights into others I have thought about.  I’m very interested in what others would have to say on this matter.

jGRASP

jGRASP ArrayList visualization

I start my students out with jGRASP and I recommend it without reservations.  The interface is very simple and students really only need to learn two buttons: compile a program (a green plus) and run it (a running red figure).  jGRASP doesn’t attempt to do any file management and doesn’t require programs to be contained in a project, though that is an option.  This means that nothing is hidden from students and that they can manage their Java files as they would any other.  Furthermore, it runs anywhere Java runs, so students can work from home in a familiar environment.

The debugger is very simple to use: breakpoints are dropped by clicking in the margin of a particular line and a ladybug icon starts the debugger.  An arrow allows for stepping through as the lines being run are highlighted.  All variables are shown with their values in a side bar, as is the call stack.

I tend to use a lot of hand drawings and ask my students to hand-draw code visualizations when debugging but I can imagine many teachers getting excited about jGRASP’s object visualization capabilities.  I haven’t used this much but there’s a nice tutorial on viewers on the jGRASP site.

jGRASP is not used in industry, but I don’t think that really matters.  Everything a student learns using jGRASP will transfer to a more powerful IDE.  There’s no code completion, but I consider that a feature — I don’t want my students relying on it early.

I show my students a slightly modified tutorial written by Marty Stepp early in the semester.  Using the AP CS Gridworld case study with jGRASP is trivial and I show my students a couple of screenshots to help them get them going.

jGRASP is the tool I reach for when I want to write a quick bit of Java for a personal project, a proof of concept or something like that.

Eclipse

I introduce Eclipse when we get to multi-class projects.  At that point, managing files in jGRASP is getting a little annoying and students know enough different classes that they’re having trouble remembering relevant fields and methods.  They’re really impressed by code completion and can see the power of a full-blown IDE complete with plugins, version control support, etc.

The truth, though, is that Eclipse is unnecessarily unwieldy for small projects with a handful of classes.  Its file management process is confusing and students often end up with duplicate files and have a hard time with version control.  It works much better with a formal version control system like SVN or Mercurial but I’m not interested in taking time out of programming to teach tools in CS1.  In practice, a lot of students try Eclipse, think it’s pretty cool, and then come back to jGRASP because it’s just friendlier.  I think that’s ok.

Eclipse is the tool I reach for when I want to work on a larger project whether it’s in Ruby on Rails or for the Android mobile platform.

DrJava

If I weren’t using jGRASP, I’d be using DrJava.  It’s one step simpler than jGRASP and doesn’t include visualizations.  I don’t use those much in jGRASP anyway but I just find the jGRASP interface a little more comfortable.  It’s really a matter of taste as I think both fulfill my criteria.

BlueJ

BlueJ class relationship visualization.

BlueJ is designed specifically for teaching Java object oriented programming and I teach objects late so it really would make no sense for me.  It’s hard for me to really evaluate the IDE since I disagree with its fundamental premise: that objects are the place to start when teaching Java.  I think, though, that it’s likely the best option for a teacher who has chosen that particular approach.  Students can start creating classes and instantiating objects without having to worry about writing a main method or understanding what objects really are.  The idea is that they can experiment and develop mental models that way.

As seen in the screenshot, each class is represented by a tan box and class relationships are represented by arrows, making a UML-like diagram.   I do think it’s very useful for students to see the relationships between their classes.  Static methods can be called by right-clicking on one of the classes.  Objects are also instantiated in the same way and they can be seen as red boxes at the bottom of the window.  Right clicking on an object allows instance methods to be executed.

Supporters of the IDE and related methodology claim that the visualizations really help students learn OOP.  A recent paper by Bennedsen and Schulte (BlueJ Visual Debugger for Learning the Execution of Object-Oriented Programs?) found that students learned just as well with manual tracing of code.

NetBeans

I’ve used NetBeans for Java mobile development and I was fairly neutral about the experience.  Like Eclipse, it’s high-powered and full-featured.  I don’t think it suffers as badly from file management weirdness but it doesn’t have as many plugins for it.  People who like NetBeans really like NetBeans.  Again, though, I think that presenting a professional IDE gives too many opportunities for students to get lost exploring features instead of learning to program.

Command line

A lot of instructors seem to use the command line tools (javac, java) for building and running programs students write in something like Notepad.  I love the command line for my own use but I think it’s too hack-y for most students.  I want to make sure they have access to syntax highlighting, bracket pairing, etc, and at that point, why not add a compile button?  I would stay away from command line tools primarily because I suspect they intimidate students who are not comfortable with computers and give students who are already confident something to brag about (“let me show you this command I know…).  That takes away from problem-solving.  For someone who insists on this method, I highly recommend Notepad++, a Windows text editor.

From a purely practical standpoint, many K-12 labs restrict access to the command line.

After being plowed down by an SUV while commuting on my scooter, I did the natural thing and bought myself a Kawasaki Ninja 250R.

It’s a perfect bike for me but it still has involved a bit of a learning curve.  Starting with a scooter got me used to being on two wheels but it also encouraged some habits that don’t work out so well on a motorcycle.  For example, I had a tendency to park with my front wheel to the curb instead of backing in.  With the scooter, that worked marvelously but I’ve had a couple of embarrassing moments taking 5-10 minutes to pull the bike out of a parking spot.  Turns out it’s a little heavier.

I’ve also had to learn to shift and though that’s mostly been smooth sailing, I have a tough time with hills and using my back brake and not stalling and not falling over.

So naturally, on a beautiful ride to Mercer Island, I was going up a really steep hill to a stop sign, forgot to shift down, stalled, had my wheels ready to make the next turn and slowly tipped over, cursing the whole way down.  Not a big deal, but the right footpeg bracket — the piece that attaches the pedal and brake to the frame — was a victim.  We fashioned an amazing rope brace and I was on my way.

The complete truth is that it was Yaw who did the splinting as I stood around and watched.  It was my bike and I know how to tie knots but he grabbed the rope, got to work, and I just made encouraging remarks.

I was happy to find the replacement piece for $60 on cheapcycleparts.com and put in an order right away though I knew I’d be out of town for a month.  I had to beg Yaw not to fix it before I got back.  On my return, we went down to the garage to inspect the damage and Yaw expertly kneeled down, cut out the brace and started narrating what the fix would entail.  I essentially had to chase him away just to get near the bike.  He said he’d check in with me in an hour and did not seem terribly convinced that I’d be successful.

The fix required removing five bolts and an e-clip, putting the replacement piece in and putting the fasteners back in.  It took me about a half hour and most of that time was spent trying to get enough leverage to loosen the bolts.  When I came back upstairs to wash up, Yaw’s comment was “already?!”  Unsurprising since his initial analysis of the work to do turned out to be wrong.  For some reason, he essentially wanted to take apart everything there was to take apart, whether required or not and I’m sure he would have taken much longer to get to the same results.

I think that for whatever reason, mechanical tinkering and computer-based tinkering are typically similar in the reactions they illicit in women and the men around them so this story may have some relevance to how I approach women in my computer science courses.  Some things that occurred to me:

• There’s significant value to taking the time to design a good solution before rolling up one’s sleeves.  I need to be even more deliberate about encouraging this in my students, particularly in my boys who have more of a tendency to grab the keyboard and head off in the entirely wrong direction.  Similarly, I need to celebrate the students who do good design work — typically my girls.  This may be where some of what I learned at the TeachScheme workshop will really come in handy.
• I need to watch the tone boys use when talking to girls about their attempts and successes.  Yaw is a pretty amazing guy all around and about as far from sexist as one can be but the way he said “I’ll check in on you in an hour” was not very encouraging.  Similarly, his reaction when I came up implied he didn’t think I would be successful.  That can be damaging and I don’t want it happening in my classes.
• I may want to discourage mix-gender pairs, as strange as that seems.  An analogous situation occurred in my AP class this last year — a really high powered boy/girl pair went to work on a neat quiz game for their final project and though the girl often had better instincts as to how to design their code, she didn’t trust herself and tended to defer!  In the end, the boy spent most of the time at the keyboard, the same way Yaw made my string-splint.  She may have had a better overall experience working with another girl.
• On the other hand, I may want to encourage mix-gender pairs and be more deliberate about coaching the girl to assert herself.  I really did enjoy fixing my bike but to get there I had to put my foot down and I think it’s important to do that sometimes.

In the end, I fixed the bike and had some interesting thoughts about teaching while Yaw made lunch but I’m still a little puzzled — I’m not bad mechanically, I enjoy working with my hands and I’ve definitely spent more time in a shop than Yaw has.  So why do I systematically defer when things need fixing or tinkering with?

I’m in Rhode Island for a week-long training on using the TeachScheme curriculum, a set of materials and philosophies for teaching introductory computer science (or is it programming?).  I was able to come all the way out here for one of the free summer workshops through National Science Foundation funding — very cool.  I’ve been hearing about TeachScheme for a while and a couple of teachers in the Seattle area whom I know and love have used some parts of the curriculum to good success.  My interest was sparked by looking over the freely-available textbook (How to Design Programs) and seeing the promise of a structured, deliberate approach to teaching programming.

Almost everything I know about computer science pedagogy I learned through watching Stuart Reges and Marty Stepp teach University of Washington’s CS1 course several times as their teaching assistant.  The course is popular, is more gender-balanced than most CS1 courses, and contributes to attracting high-caliber CS majors.  I don’t think it so much matters that it’s taught in Java, that Stuart uses an overhead projector and Marty uses PowerPoint slides or that jGRASP is the IDE of choice.  What has become clear to me is that the power of the course they have built comes from it being rigorous, deliberately building up complexity, offering lots of opportunities for practice and including a lot of support through TAs and frequent office hours.  Also, both instructors know their material inside and out and value consistency and predictability over the “wow factor.”

I think that this philosophical background meshes nicely with the values of the TeachScheme curriculum (yes, it’s ENTIRELY appropriate to talk about philosophy and values when discussing CS1 courses).  There’s definitely a lot of emphasis on building concepts one by one and increasing the complexity in a calculated, reasonably-paced way.  That may seem obvious, but I’m looking at more and more books and course outlines that feel like a bunch of ‘cool’ things are being thrown together without much regard for cognitive overload.  Several courses seem based on the idea that once a concept is introduced, students can experiment and learn related concepts on their own.  I think the unfortunate side-effect of these poorly-structured courses is that they are particularly discouraging for people without high confidence in their computational abilities — women and minorities.

Our primary instructor for the workshop is Kathi Fisler from WPI.  She knows her material inside and out and values consistency and predictability over the “wow factor!”  She has us meet in the classroom for morning and afternoon lectures followed by lab sessions.  Her lectures involve a lot of code writing on the board and are highly structured — I love it.  Writing code on the board allows Kathi to use color, arrows, annotations, etc and I feel that the students are more engaged because we’re acting as live interpreters.

We’re really being treated as students: Kathi is giving lectures at a faster pace than she would in CS1 but I feel like they’re still pretty close to what students would see.  There’s very little “meta” talk about what she’s doing and we’ve been asked to keep pedagogical questions and concerns for Thursday.  I feel strongly that this is the best way to teach a workshop, probably mostly because I believe in general that teaching is one of those things that’s better taught through apprenticeship rather than in formal classrooms.  Kathi could talk our ears off about effectively using a whiteboard but I think it would really fall flat.  Instead, she’s showing us the way she does it and while it really resonates with me, it may not with others and they’re free to ignore it in favor of other things she’s showing us at the same time.  One teacher/student commented that erasing the white board was taking time which wouldn’t be the case with an interactive white board (a bargain at ~$2,000).  Kathi’s quick response: “it’s valuable reflection time for students.”  Thank you for that.  It’s refreshing to see a highly-effective, low-tech approach to presenting content.

An important piece of the curriculum is the idea of a “design recipe” — a systematic approach to writing functions  that solve particular problems.  It goes something like this (off the top of my head, so I may not use their terms):

• What’s the data like?  (if there’s a data structure of some sort involved, describe the contents and write examples)
• What  are the parameter and return types?  What’s a short description of the function?  (write as comments)
• What are some example calls and what should their results be? (write out test cases to be executed later)
• Write the body based on templates implied by the data types
• Run the tests

The idea is that an instructor will refuse to look at a student’s code if he/she doesn’t have comments and test cases.  This piece is fabulous and I certainly intend on emphasizing it more with my students no matter what language I use.

Of course, the early emphasis on data structures points to what really makes this curriculum stand out — it’s based on teaching a functional language.  This is where everyone’s blood pressure goes through the roof.  In CS1, there has been a big debate on whether to teach objects early or later but I don’t think there’s been a terrible lot of noise on whether procedural or object-oriented paradigms are even the right ones to teach.  (Side note: to me, this is really an issue of paradigm and not of language.)

I think there are a lot of very good reasons to teach in a primarily functional paradigm.  Some off the top of my head:

• Small language core (often true of functional languages, definitely so of Scheme)
• Don’t need to worry about side effects at first (dealing with data mutation can be entirely mind-boggling)
• Close analogy with algebra functions
• Early access to complex data types

I also have a lot of concerns:

• Functional programming implies certain idioms and ways of thinking about problems.  They’re much less typical than procedural idioms.  This may or may not matter depending on the intended goal of a course.
• Relatedly, how much transfer is there to other paradigms?  Do students really understand recursion and data structures or do the templates and the syntax trivialize it to the point of preventing students from learning it as a transferable problem-solving technique?
• Is )))])])) scary?  I don’t think about parens much writing a program but they really boggle my mind when I’m reading code.  This may be a failure on my part, but I’ve found it’s almost easier for me to re-write simple functions than to reason through reading them!  Yikes!
• As nice as the templates are, I still think it’s very rare for people to naturally think recursively beyond looking at recursive data structures.  Again, do students actually learn recursion in a broad sense?  Does it matter?  I also tend to believe there’s a lot of value to learning iterative constructs.

There definitely is one underlying philosophical point I need to address before being able to figure out how much of a concern these concerns really are — what are the goals of a first programming course?  Is it simply that students have a great experience?  Is it that they build flashy things?  That they be able to get an internship?  I didn’t think that ‘applicability to the real world’ was that important to me but I’ve got 5 students doing technical internships this summer and it’s really rewarding for them.  2 of them have a Java background and are working in C# and 2 of them have a Python background and are working in Perl.  What if they had learned Scheme?

I’m really liking what I’m seeing so far but I’m not ready to become a convert just yet.  That said, there are lots of things I will without doubt adapt and use.  What I may be converted to believing and advocating for is that the functional paradigm is a good way to leverage and expand on students’ algebra knowledge.  Emmanuel Schanzer, whom I mentioned in my CS/IT post, is going to tell us about his middle school outreach program tomorrow.  I’m looking forward to seeing this material again from a slightly more informed perspective.

Yesterday was a long day well spent at Google headquarters for the Computer Science Teachers Association‘s annual Computer Science & Information Technology Symposium.  It was a fairly modest gathering — I think there were about 200 of us (soon to be 10,000) – but a lot of great folks came out and there were fantastic conversations inside and outside of sessions.

Spaf on “Soup to Nuts”

Gene Spafford, of security fame, kicked things off with a keynote covering interesting puzzles to get students thinking out of the box as well as ideas on how to inspire students by showing them what can be done with computer science.  Examples included training soldiers with Segway-based robots and discovering security holes that make power plants vulnerable to cyber attacks.  Overall, it was an interesting, engaging talk.  There was a lot I recognized from Ed Lazowska‘s talks and materials I already use which I found comforting in some way.

Code as a Metaphor for Computational Thinking

I then went to Owen Astrachan‘s Code as a Metaphor for Computational Thinking session.  As he opened, he said he’d let us decide whether the talk was actually about computational thinking because he wasn’t sure.  Interesting to hear him say that — I have a hard time with the “computational thinking” label because I haven’t seen a satisfying explanation of what it is.  The talk was centered on three examples that involved reasoning about existing computational artifacts, writing some related code and then analyzing that code.  At one point, he said something to the effect of “if you don’t write code in class, students won’t know how to do it.”  I appreciated that and do believe that there’s something very powerful about seeing a (relative) expert go through the process of writing a program, making mistakes, verifying it, using tools like IDEs appropriately, etc.  I’m very suspicious of instructors who talk about code without demonstrating how to write anything.

The first example he discussed involved online gambling.  He started by mentioning that it’s a good place to talk about the legal code as it relates to computing.  It’s also a good opportunity to show some interesting code for labeling hands — he showed us a flawed example of an “isPair” function that returned true even when the hand should really be considered a triple or better.  We talked through different ways of resolving this issue and lots of good design ideas came out.  My only concern would be that poker tends to be a high-income, white, nerdy male sport… using this example would require careful thought on how to present it without alienating anyone.  I don’t really know poker and my first reaction was “yawn” though I warmed up to it once we got to the code.  There really are interesting things that come up, here.  One audience member suggested that the problem could be fixed by always calling the hand-testing functions in order of highest-scoring to lowest-scoring.  True, but Michael Kölling of Greenfoot fame rightly pointed out that functions should work regardless of the context in which they’re called.  This is a good type of conversation to have with and between students.  Students can then implement all the hand-scoring functions and compare their runs to expected probabilities, using those to evaluate whether their implementations are correct.  That’s an idea I really like.

Owen’s second example involved Tin Eye, a search engine that lets you upload a picture and find instances of it regardless of size, compression, format, etc.  It’s interesting to speculate on how it works and to try to discover the limits of its tolerance.  For example, Owen suggests that we ask students to use steganography functions to hide an unrelated image into a target image then see whether Tin Eye still recognizes the target.  What if more of the target image were replaced?  What if part of the image were cropped?  One could do something similar with Shazam, a tool for recognizing songs.  I like the “let’s figure this out” feel of this example.

Finally, he discussed an example from the “code of life” — finding repeated DNA substrings.  This is an interesting algorithmic problem that can be discussed free from code and eventually be written as an exercise.  The discovery for me was that Duke has a small set of problems with test sequences available here.  I don’t know what computational thinking is, but what Owen discussed were definitely examples of it.

Pre-AP Recruiting

The next session I attended, “How does your geek garden grow?  Identifying and cultivating the geeks of tomorrow (AP CS Feeder Course)” left a sour taste in my mouth.  The speaker argued that we need to be better at communicating with math teachers and counselors to tell them that we are in fact looking for the bored, disinterested students at the social fringe who never do their homework.  The reason for this is that they may make great ‘geeks,’ which is the type of person the tech industry wants to hire.  Maybe my thinking is clouded by the luxury of having lots of motivated, social students who want to take my courses but I really do want to target the leaders, the social butterflies, the high-achievers as much as possible.  Of course, I want my courses to be inclusive of all, but I feel that targeting unmotivated students at the social fringes is a pretty desperate move and not one I think will do a lot for the image or success of K-12 Computer Science.  The speaker’s suggestion for getting those unmotivated students is to tell them that they’ll make  video games, that there will be no homework and that they’ll pass if they play along.

This makes me uncomfortable but the speaker did report that this tactic has resulted in students finding something that they’re good at and continuing on to be successful in her AP class.  That, I think, is a real victory and something to be celebrated so I’m a little torn.  It’s possible that faced with low enrollment and a lack of strong students I would do the same thing.

A common theme in the talk was “let students do what they want to do so you don’t lose them.”  The course she described seemed like everything but the kitchen sink and heavy on the tools — Visual Basic, Java, Scratch, Alice, Gamemaker… my head was spinning just thinking about it!  Where I tend to opt for structured play and predictability, she really opens things up for students to experiment.  It’s a matter of philosophy and I wish I could go see how things play out in her classroom.

One thing I really appreciated from this talk was getting some good reminders about where teenagers are in their development while they’re taking our courses.  They’re identity-building and striving to find areas they’re successful in so we can have a very powerful effect by providing them with experiences that reinforce their sense of self.

Emmanuel Schanzer’s talk on Functional Videogame Programming was the day’s discovery and I’m glad Michelle Hutton encouraged me to see it.  Emmanuel’s project, Bootstrap, is a full curriculum for using Scheme to bolster algebra learning.  I think I’m going to ruminate on this one and write about it later.

Digitizing The World

The last session I attended was by two teachers from CSTA’s board of directors — current president Michelle Hutton and past president Robb Cutler.  They presented extensions on a cool CS Unplugged activity on image representation.  Michelle’s middle school girls “digitized” color images using graph paper and a color key.  They discussed different algorithms for choosing the color to put in one square and changing the grid size allowed them to discuss tradeoffs between storage space and fidelity.  I like it.  Then, they extended the exercise further by using points to digitally represent 3D objects.  Robb wrote a tool to interpret simple formatted text files and display the objects or scenes so they can be interacted with.  Michelle had her students represent Lego shapes and their classroom.  In a blog post about the exercise, she recounted one student’s inability to believe in her own success — spacial orientation exercises are generally more difficult for we ladies.

I liked their idea of giving “programming-like experiences.”  I’ll have to see whether there’s a way I can adapt the activity or something like it for my high schoolers.  I was also very impressed that Robb was modifying the tool and the text file’s syntax as the girls requested features.  Their requests ranged from function-like syntax (reusable blocks) to naming the tool after them.  Participating in this “client” way must definitely have given the girls a sense of the power of programming and I’d like to see whether I can replicate that experience somehow.

Megan Smith of Google.org

Our closing keynote was by Megan Smith, in charge of Google.org.  She discussed .org initiatives including Flu Trends, RechargeIT, Clean Energy 2030, and PowerMeter and tied those nicely to generating excitement in our students about computer science.  She’s an excellent speaker and closed the day well.  Valerie Barr, an inspirational instructor who has revamped the CS1 courses at Union College, mentioned that Google is hurting computer science by calling its employees “engineers.”  The same point was made to Marissa Mayer when she gave the keynote talk at SIGCSE in 2008.  Megan had a good response but I now read that she’s not a computer scientist at all but a mechanical engineer!  The problem may be partly on the computer science side… we still haven’t defined our field very well.  Engineering brings to mind creativity, construction, collaboration and even I’m not sure what CS should make me think of.

Overall, a positive, inspirational day leaving me with lots of food for thought and wishing I could have spent more time with so many people I admire and enjoy speaking with.

I was talking to my dad about the design of a first computer science course and I said something like maybe I was more inclined to want to teach programming early because it’s what drew me into computer science in the first place.  I started writing some PHP scripts and BASH scripts to solve some specific problems I had and got hooked.  My dad doesn’t think it’s that simple.  He reminded me that I played The Incredible Machines and other games like it.

Bowling balls? Dynamite? Mouse cages? The best building materials.

The neat thing about the Incredible Machines is that mistakes are made.  Lots of them.  Solving the puzzles requires incremental design and experimentation to understand how each component can be useful alone or when combined with others.  I remember feeling frustrated when things weren’t working but also really excited when I finally solved a level.  In retrospect, it does seem like that process is a lot like programming.

Then I played a lot of Zork.  It’s again a puzzle game but has the added twist of being command-line based.

That's right, no pictures.

To me, it was fun trying to figure out what commands were available when and having to visualize where I was and what was around me.  I still have the maps I drew out painstakingly with colored pencils.  I guess I was getting used to a limited command set and a form of abstraction.  I also realized how efficient typing in commands could be and eventually switched to Linux and a very light weight windowing environment.

Somewhere along the way I got involved in personalizing Windows 95.

Yeah, yeah, it's girly.

I never really thought much of it, but to make the Pink Screen of Death I had to change a setting in System.ini, figure out VGA colors and that kind of stuff.  Not super complex, but I was learning about operating systems, data representation, settings, etc.  I also did some fun registry hacking at the time which again got me curious about operating systems, frustrated at Windows, and on to Linux.

Of course, I didn’t just come up with these projects out of thin air.  I was spending a lot of time on Usenet and was perfecting my web searching skills.  Most importantly, I was learning how to learn.  That’s perhaps one of the most important things in computer science given that all of its fundamentals as well as its artifacts are man-made abstractions and that new ones come up every day.

So maybe I didn’t get to programming first.  And maybe what an introductory computer science class should do, in part, is give students an opportunity to be hooked by experiences similar to my own.  How about games like Lightbot 2.0 or Manufactoria?  Customization experiences through CSS?

This summer, I have the opportunity to work with Larry Snyder from University of Washington’s Computer Science and Engineering department on his pilot of the CS Principles course.  I’m thrilled to be part of the process: I’ve expressed skepticism in the idea of a first course in computing without much programming and I’m scared of a reduction in rigor — what better way to address these areas of concern than to be part of the effort to shape the course?

Larry has been working actively on introductory courses since 1997 or so and has written a textbook on fluency with information technology, a concept defined and solidified by a committee which he chaired.  That work has defined what “the average American” should know in order to effectively leverage the growing availability and sophistication of software and hardware products.  The group advocated teaching IT fluency in three areas: skills (how to use a particular product), concepts (underlying ideas that won’t change as, for example, new versions of software come out) and intellectual capabilities (problem solving).

Now we’re tackling a related but not entirely equivalent question: what should “the average American” know about computer science?  In my mind, that’s a trickier question since computer science is a relatively poorly defined field.  Certainly, IT products generally come out of computer science, so there’s a lot of overlap, but it doesn’t feel right to define computer science in terms of its products.  What unites those working on structural problems in graph theory to those working on accessible technology?  I still haven’t found an entirely compelling answer and some would argue that they don’t belong in the same discipline/department.  It’s frustrating to think that I can’t eloquently describe my own field but I have this vague sense that computer science is about process rather than product.  This suggests that a useful way to think of the CS Principles course in contrast with IT fluency might be that it will include an increased emphasis on “intellectual capabilities” built on top of the “concepts” part without much “skills.”

Another interesting aspect of this course is that its goals are potentially numerous and conflicting.  I think it’s pretty straight-forward to define the goals for a programming course — students exiting the course should recognize problems appropriate to solve computationally, should be able to formulate basic algorithms, and should have some syntactic fluency in the language of choice.  There’s some healthy debate to have on how to reach those goals, but I think most people would agree with the basic skeleton.  Furthermore, defending those goals is pretty straightforward.  By formally expressing algorithms, students develop their problem solving skills in a systematic and measurable way.  Programming is fundamentally a creative endeavor and that is a useful and satisfying experience for students to have.  And so on.

What about a breadth course like this Principles one?  What should a student exiting the course know/understand/be able to do?  So far, the course committee has shared lots of high-level notions of what the course should convey through its 7 Big Ideas (reminiscent of Peter Denning’s 7 Great Principles), a set of general practices and a philosophical rationale for the course.  This does not yet imply any specific set of skills and understandings that a student would have exiting the course.  That’s what the pilots are for.

For the UW pilot, to be offered this coming winter, Larry and I are trying to be disciplined about using a form of backward design to try to avoid an aimless romp through “cool stuff” related to computer science.  We are trying to come up with “unit-level” goals that describe the general concept a student should come away with, breaking those down into small skill, knowledge or understanding based goals and writing corresponding sample assessment questions so that we can then work to create the most appropriate learning activities.  I don’t know whether we’ll have the discipline to stick to this process for the development of the entire course but it has certainly helped me focus my thinking and give me hope that we can weave a coherent story.

It’s interesting to ponder whether specific outcomes and connectivity between topics matter all that much.  My sense is that if this were just a college course with the goal of getting freshmen excited about taking a programming course and considering computer science, it might be ok for it to just throw as much “cool” stuff as possible in students’ direction.  I think that for it to be successful as a high school class, though, it will need to be much more clearly based on specific outcomes.  Without those, districts will be reluctant to adopt it (where are the standards it covers?), teachers will be difficult to train (should I use Alice?  Python?  How do I decide?) and students will see it as an ‘easy AP’ to pad their schedule.

To imagined or veritable readers: How would you go about developing such a course?  What are a couple of specific things you believe students marching out of the classroom on the last day should be able to do/explain/use?

I’m glad I went.  It was an interesting glimpse into what other teachers are doing in their classrooms and a good reminder of how important a network and support structure are.  I’m hoping all of us who participated will stay in touch and I’m sure our practice will be stronger because of it.  I also really appreciate the resource CD we were given — lots of great ideas on there.

My expectations were not met, but that’s probably ok.  I imagined from the agenda that there would be both a novice and an advanced group.  Of course, there were too few of us to have both and that’s evidence of deeper problems we need to resolve.  I was hoping for some demos of pedagogical strategies for difficult concepts in tight, well-scripted mini-lessons.  Our instructor talked about what he does and had us work on projects he does with students which was appropriate given our average level.  I was hoping for an opportunity to do some AP-style grading to encourage a rubric-based approach to grading all year and to help normalize our classes across the state.  I thought maybe we’d get some insight into good papers to read about teaching CS1 and maybe some fun activities to do to help teach difficult concepts.

I appreciated the time we had to share ideas and discuss our challenges.  Hopefully we can address some of them over e-mail and help each other grow as instructors.

And if I do go to an AP Institute again, I’ll try to find one with an experienced track.