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?