Forging The Future 2/5/12 — 8:05 UTC

Students embarking on the study of computer programming, would do well to read How to Learn Programming Languages by Ben Deverett. This short article appearing in XRDS: Crossroads, The ACM Magazine for Students provides a nice overview of why there are many programming languages and how to approach learning one.

We find the advice to consider a language’s historical origins particularly wise, although we would beg to differ somewhat with Mr. Deverett’s recommendations to learn a popular language when you need to use it which seem to make the tacit assumption that you will doing so to turn out a demo or production system (in which context they make perfect sense).

Instead, we recommend that you start to develop a solid theoretical understanding of programming languages before deadlines loom. This is best achieved with a LISP dialect or through reading a solid comparative study of multiple languages.

So goes the common wisdom of many an educator. After all, it is so much more fun to make robotic dogs frolic than to do something as mundane as to write a traditional program.

But there is a real danger here, particularly in lower grades that a robotics course will either devolve into pure play or dead end in frustration turning students off to computing.

The biggest problems in teaching with real world robots are three fold.

First, it conflates programming engineering issues making it impossible to truly know if students are making a reasoning error in their code or are just encountering the unforgiving nature of physical reality. This is particularly apt to humiliate a student at a competition or demo in an environment with different ambient levels of heat, lighting, floor slipperiness, acoustic noise, physical geometry, ventilation system air flows (which can overpower the motors of a robotic blimp), the coincidental presence of target stimuli in the environment (e.g. someone wearing an electric orange T-Shirt that matches the hue of an artificial target) and radio frequency interference from other nearby projects. Any of these factors can prevent a system that worked one day from working on the next and the expertise needed to troubleshoot the resulting systems failure is apt to be beyond the keen of most instructors. Indeed, teams of graduate students have found themselves unable to ferret out the often multiple sources of such failures. So there is little doubt that most students would rapidly grow frustrated if they tried to use real robots as more than RC Cars to play with.

Second, working with tangible artifacts reduces the likelihood that students will develop the right intuitions for thinking about abstractions. Only the most disciplined instructor will be able to keep attention focused on deeper concepts like recursion and the environment model of evaluation with students chomping at the bit to make their bot do something. Instead, the path of least resistance will most likely take the form of simple imperative drag and drop tile based visual languages that will act as inverse parsers to insure that syntactically invalid programs can’t be composed in the first place. Abstraction support in such systems is usually rather limited and, aside from the now defunct Prograph data-flow oriented visual programming language, support for reflection and higher order programming constructs is all but unheard of.

The counter argument to this point is that the use of robotics grounds the curriculum in the real world and offers opportunities for students to look at the interrelationship of topics like Machine Vision, Probabilistic Reasoning, Physics Computations, Planning, and Multi-Agent System Design. (See Preparing Computer Science Students for the Robotics Revolution by David S. Touretzky – Communications of the ACM 8/2010 Vol. 53 No. 8 pp. 7-29 — N.B. an ACM Digital Library Account is required to access the ditial version of this article). The assumption here is that such topics can indeed be made accessible to students outside of graduate research labs. While this may eventually come to pass, Touretzky acknowledges that high school level robotics competitions like US FIRST “emphasize the mechanical engineering aspects of the field at the expense of computer science” and that the robots used in such programs “must be primarily teleoperated because students aren’t being taught the kind of software that would allow their robots to act autonomously.” [p. 28]

Third, there is the economic reality that robots are very expensive short lived devices whose widespread use in schools would drive up property taxes on the middle class and exacerbate the digital divide between rich and poor school districts. With prices ranging from six to sixteen hundred dollars per device, the inevitable desire to have enough robots for students to use them individually or in groups of no more than two or three, and the need to upgrade hardware every year or two to keep students competitive with their peers in other districts, the price of a robotics program could quickly skyrocket. Despite the overall downward trend in technology costs it is far more likely that successive models will offer more tech in the same price range than it is for them to offer the same tech at lower prices.

The digital divide aspect is particularly troubling since poor students will have to settle for relatively blind and deaf mobile boxes while rich students could experiment with sensor laden humanoid robots costing ten times as much.

Touretzky has demonstrated that advanced computing concepts can be integrated into a robotics programming toolkit and deployed by a world class professor at the undergraduate level, but for ordinary K – 12 End User teachers, the robotics path is fraught with danger.

Bearing these risks in mind, systems like Racket – a free scheme dialect with extensive pedagogical support and educator outreach programs – remain the best hope for promoting computing in our schools. If students still want to experiment with robots, there are a number of free hardware-optional simulations available like the Microsoft Robotics Developer Studio.