Sub Ubi

I’ve been teaching I2LR (Intro to LEGO Robotics) for the better part of 3 years now. This last semester, I successfully captured lots of rich data that is virtually impossible to mine in my lifetime. Kinda cool what you can do with a little bit of Perl, Scheme, and a 75 TB tape silo.

There are a number of vignettes that are of interest from this semester, which is partially how I break down the data in my mind: what, in this qualitative sample of I2LR, is of interest, and what lessons are learned from those moments. One of those moments was mid-semester, when I stopped and said “what would really make the remainder of this course great for you?” The students responded, and we shifted the focus of the course to accomodate their desires. As a result, attendance was nearly perfect, and the students were all engaged and active for the remainder of the semester.

The last day of class was another excellent moment. I let them work for a bit, so they could coordinate for their final presentations. Then, I started by giving them a little bit of background on Chickering and Gamson’s Seven Principles for Good Practice in Undergraduate Education. This excellent article is a distillation of a good deal of work by these two authors, and I try and keep in mind at all stages of the educational process, from design to implementation. I put this to the students, and asked them first where they thought I succeeded, in their opinion, in I2LR, and why. This was a good discussion. Then, I asked them where I missed. This, too, was a good discussion; the image provided here is a bit of the board as it evolved over the course of the discussion.

Then, we segued into discussion of what should be kept, tossed, and added to the course. This was a fascinating discussion as well, as students I knew and had worked closely with all semester gave me some very good feedback on the course, and were very honest and open about all aspects of the experience. I’ve done this every semester, but this is the first semester I’ve done such a good job of capturing the entire conversation.

I’ve transcribed this discussion, and think it could make an excellent reflection paper on the semester. It would be an opportunity to introduce the SIGCSE crowd to Chickering and Gamson (they’ve never been cited before in the literature, despite the fact that they’ve been writing since the early 80’s), as well as introducing the course, the guiding theories behind it, and an intimate, qualitative view of student’s reactions to such a course.

Thoughts?

This summer I’m mentoring a high school student for 6 weeks in a research project. His project is to implement a small language for programming the LEGO Mindstorm. Because there are incredibly powerful (and easy to use) tools for processing language constructs in Scheme, we started his Jedi training there. In 2 weeks, we were recurring on lists and constructing/deconstructing complex structures. Just what you need to work with a language tree.

Now, his language won’t be a full language; it will be an ‘embedded’ language, or a ‘little’ language, if you prefer. It could, effectively, be considered little more than a few Scheme macros; but, to say it was ‘little more than’ implies that a few Scheme macros can’t completely change the face of a language. Either way, it is a good challenge, and an interesting one, for a high school student.

If we backpedal just a bit, the reason Brooke and I thought this would be a good project was because of the pitfalls we didn’t really avoid (by choice) in the design of an event-based language for programming the Mindstorm (or, the addition of syntax for defining event handlers in Scheme). With the help of one of my students last Spring (a senior CS major), we realized how our program would allow students to easily write programs with serious concurrency issues, leading to race conditions and other nastiness that students probably shouldn’t encounter early on. Or, should they? (In the end, we thought this could be good–subject of a different post.)

This led to more thought on my part, and more discussions between the two of us; from conversation with some other peers, state machines and similar constructs were brought up for systems control, because they don’t fall prey to the same concurrency issues that you face in event-based paradigms. I also liked this because they had a very visual nature. Furthermore, they represent an important tool and embody some important concepts in CS.

Now, we have two languages for programming the Mindstorm; well, three if you count our “native” Scheme implementation. In working with Jacob this summer, we’re realizing that we don’t like having to teach all of Scheme (or a bunch of it) just to play with the LEGO. What would be nice is if we could start with a little language (or two), or preferably one that grows with the student, until we segue into full(ish) Scheme, and can do really interesting things in exploring multithreading, concurrency, and other systems concepts.

And while the systems issues (normally only presented in upper-level OS courses, where they are presented in the abstract), we are also very interested in the possibility for SICP-esqe language implementation for the Mindstorm. That is, we can lead the students full-circle from the little language they start with, into Scheme, and then into implementing languages in Scheme for the Mindstorm; we can bring them all the way around to implementing the language they started with, or even language constructs/paradigms of their own design.

As a paper, I was thinking we’d actually co-author with Jacob (the high-school student), so as to include some of his writing and work (plus, a good experience for him). We’d present a bit about the compiler, the platform, the summer project (as an exemplar–here is where we’d have Jacob do some of the writing), and then segue into where the research on this is headed.

Or, put another way, I think the teaching of metacircular language implementation on the LEGO Mindstorm (or any robotics platform, for that matter) would be an excellent subject of research. It is more focused than what I’ve been doing, and there are lots of things going on very applicable to real CS concepts and issues in education.

This wouldn’t exactly be a “look what I did” paper, because Jacob’s project is an exploration into this area. We haven’t done any “research” into using it with students, however. The compiler itself is an interesting tidbit (we’re calling it “Scorth”), and the applications/future research I believe is promising, as it extends ideas of SICP and EOPL (learning PL by implementing languages) as well as being consistent with the spirit of the LEGO (learning by building, Papert et. al.).

Thoughts?

I have two paper ideas that I need to create time to work on. I wanted to bounce those ideas past y’all for feedback/brainstorming before I dive into them. Because we’re moving from Indiana at the start of August, and moving overseas at the end of August, I’m concerned about time. To get either/both of these papers done in time for a SIGCSE/ITiCSE submission, I need to, generally speaking, get them right the first time around. Almost.

I’ll post each idea as a separate post, so discussion can happen on each of them in turn.

It seems we need to move a few things along on CS-ED. A few possibilities include:

• I write some how-tos re: the links/resources pages, and we each start taking charge of

  some resources available on the net. This could be good if we each focus in some area

  related directly to our research, as it will force us to do a little Google/ACM DL crawling. If we haven’t already,

  anyway.

• I get the Wiki running (I have to do that anyway), and we start hashing on some

  topic(s) of interest.

• We pick an article, and do a virtual reading group thing with it. Requires the

  Wiki again, I think. Could also be a book or longer piece. A real reading group would

  involve someone presenting material; if we could organize these kinds of things

  into on-line summaries of various readings (linking in discussion), it could become a good reasource

  in the long-term.

Those are a few things that come to mind immediately; cast some votes.

And no, setting up a voting booth script is not an option.

Today, the program

(begin (motor-set 5 1 0) (motor-set 5 1 2))

was sent to the RCX, and it executed the code described. This turned on the two motors, causing

the RCX to plough into the tower. Fortunately, no minifigs were present, and noone was hurt.

Work continues on tying the compiler into the DrScheme environment.

I’m wondering if we should be getting some more theoretical discussions going on here at some point. That, and we need some

active posters to their blogs besides the two of us…