Sub Ubi

My colleague and friend at UT Austin, Lisa Kaczmarczyk, gave our SIGCSE paper to the students in her technical writing course; in working through the paper, they came up with a number of questions that they thought would be nice to have answered.

They’re good questions, and Christian and I will address them on the Transterpreter weblog over the next week (or so). Some answers may also spill over here as well.

The questions that we’ll be addressing over the next n days are:

1. What is your evidence for asserting that programming these robots will appeal to freshman?
2. How is your particular approach to teaching of higher value than teaching languages and techniques that will be of more general value to the students in industry?
3. Have you come across or do you have any evidence that supports the claim that using these teaching methods works better than the teaching methods currently in place?
4. How well will learning to program concurrently in occam-pi prepare students for real world programming in industry?
5. What is next for occam-pi? Do you expect that it will become an industry standard?

I’ll probably bounce back to this space to address some of the general themes in these questions. It should be fun.

Thanks, Lisa!

I’ve dropped a blurb about our talk at Indiana University over on the Transterpreter weblog.

From here:

There cannot be anyone in the civilised world who does not already know the basic rules of Mornington Crescent, so we shall not insult our readers by re-iterating them here. Suffice to say, if you have temporarily forgotten them, or if you come from, say, the uncivilised world, such as, for example, France, you will certainly pick them up as you go along. Beginners will discover that Mornington Crescent is a little like golf, a little like shove-ha’penny, quite a lot like watching your laundry in the tumble-drier, and most closely resembles feeling around in the dark for a pocketful of loose change dropped in an unlit, damp alleyway on a Saturday night after a few beers. That is to say: frustrating, hard on the right forefinger, disorienting, even more disorienting, sheer hell on the right forefinger, and frustrating… probably in that order.

And I’m off net quizzes.

Just because I wondered how I ranked against Matt.

“Nerd God.” Hmpf.

I enjoy writing compilers.

I don’t enjoy writing parsers.

This is why I program in Scheme. As long as you use an s-expression-based syntax, you don’t need a parser. If only the whole world used Scheme…

I have gone through many, many syntax errors made by the students in my study. Along with writing, I’ve been setting up my last experiment; it involves, among other things, convincing BlueJ to respond to some syntax errors differently than it does now. And this means a new ANTLR grammar.

For example, Given code like

if(noteNumber = numberOfNotes()) {
    // Note number not valid, so do nothing.
}

there’s a number of errors you could report. In the case this came from, the parser complains that it found EOF, where it expected ‘}’. This is awful; I don’t want my parser to tell me that I forgot a bracket; instead, I want it to yell at me for misusing the ‘if’ syntax.

So, by changing the ANTLR production from

 // If-else statement
    |   "if"^ LPAREN! expression RPAREN! statement

to

 // If-else statement
    |   "if"^ LPAREN! expression RPAREN! compoundStatement

I force students to ALWAYS place the first branch of an ‘if’ in a set of curly brackets. While this may sound strict, too many of the students in my study make repeated mistakes with simple syntaxes like the ‘if’. I believe some of that problem comes from poor error message design, and some of it comes from a parser that is too permissive. I don’t want “optional” brackets—if they’re optional, it means a student can make mistakes like the one above and not see that they’ve commented out a required bracket… because the parser allowed it as a valid, optional syntax.

What I’d love to do is be able to track how many times in a row a student generates an error on the same production in a grammar, so I can give higher-level error messages over time; however, I suspect that will be beyond the scope of the study, as every modification and experiment takes considerable time.

The moral of the story? This is going to take a long, long time. More hours than I have available to me, right at the moment. Who knows; perhaps I’ll have an ANTLR epiphany. Or someone out there will drop me a note, and say “What do you need, Matt? I’m an ANTLR guru!”

Ah. To dream.

We’re in the process of automating the test suite for the Transterpreter, but last night Christian ran the entire “cgtest” suite on the Transterpreter by hand.

1236 tests passed!

That’s really great. Most importantly, it means that 99.999% of the cases that our students will encounter successfully pass through our linker, and execute on the VM. Perhaps, before the day is over, we’ll have some code that passes even more tests.

I love being able to give a talk or presentation and not be tethered to my laptop. That’s just awful: too many times, you get stuck behind a podium or lab bench in some awful part of the room, and the presentation suffers because of it. As a result, having some kind of wireless remote for PowerPoint is, I think, a must.

Typically, I’ve borrwed a Bluetooth presenter mouse (made by Logitech) from someone in the department whenever I have a talk to give. They’re great to present with, act as a wireless mouse, and have a built-in laser pointer. They also start at around $100, and truthfully, they don’t fully work with PowerPoint on OS X; you can’t easily “go back” a slide. That, and they eat batteries.

Ok, so that makes it sound like it sucks. While it might not be… great, it is Bluetooth, and doesn’t require my plugging in a dongle. Why did I pay for built-in Bluetooth if I can’t use it?

Enter Salling Clicker. This app is first-class. Simple in design and execution, it does exactly what it says on the box. (Well, it says “Salling”, which is the software author’s surname, and “Clicker”, which is a bit vague.) But really, it performs as advertised, and that’s amazing.

Clicker lets me connect my phone to my laptop (wirelessly, using Bluetooth) and control my laptop. I can start iTunes. Start it playing. Raise the volume in iTunes. Raise the system volume. Then, I can turn on the special visual effects. When I get bored of iTunes, I can shut down the app, and (if I want to) put my whole system to sleep.

In fact, I can control anything on my Powerbook that I can script with AppleScript. And, that happens to be everything. So, Salling Clicker turns a mobile phone (equipped with Bluetooth) into a universal remote control for my Macintosh. Wonder how you’re going to find a “remote control” for DVD player or VLC your Mac Mini? Hmmm…

Enter the Sony Ericsson T68i. This mobile phone has fallen out of favour; I believe I can pick one up on eBay.co.uk for around a tenner. Or, if you know the right people, you can find someone who gave theirs up for dead long ago, and get one for free. Like I did. However, I’m still going to try and pick up another used T68, because it’s just too cheap considering the power it provides when filtered through Salling Clicker. Granted, there’s a lot of other devices that work; for example, all the Palm handhelds with Bluetooth can act as remotes as well.

Oh. PowerPoint? Yeah, Salling Clicker does that too. I can go back and forth through slides, and (with a newer version of PowerPoint) I can get the title of my next slide on my phone. Pretty slick.

(None of this is “new news”; Clicker has been around for a few years, and won a number of nice awards in the Mac community. However, just like my “discovery” of instant messaging and voice-over-IP a few months back, I’m once again being dazzled by technology.)

Caveat Listenor; beware the listener of this talk. I gave a quick overview in the department of the history of robotics and some of the kinds of research that take place in the area of robotics. It is, in no way, meant to be authoritative. It was meant only as an intro to the kinds of things people do with robots, and provide pointers for people to explore further.

It also gives a quick run-down of some of the equipment we have available here to use.

20050201-robo-overview.ppt.zip
(~2MB)