Millennium Teacher

H/T: David Wiley

I’ve got the iPhone SDK installed right now, and so far it looks very nice.

From the programmer’s point of view, it’s just another set of Xcode project templates. I’m not a Cocoa/Objective C expert, but Xcode/Cocoa (especially Interface Builder, which isn’t fully functional in the beta SDK) is pretty sweet — as long as you don’t mind limiting your code to Apple products. That’s not a big deal in this segment; the Touch (Alexandre Enkerli’s term) devices are pretty much it, at least until someone starts shipping Android products.

A couple of things I’ve heard and learned concern me, though.

1) Apparently there’s no way under the current SDK to have a application run in the background. Some of the cooler educational applications I can imagine would really work better if they could talk to a server all the time, or at least check in every few minutes. Some have said that this is due to the limited processing power of the Touch devices, but I’m not convinced that’s it. For one, the ARM processors in the Touch devices are more powerful and have more memory than the ones I used to run Linux on in the early 90s <codger voice> I used to run Linux on a 386SX 16 MHz machine with 8 megs of RAM. We didn’t have any fancy “distros” or “CDs”. We had to download the packages one at a time over a dialup and put them on floppy disks! And we liked it!</codger voice>. For another, the Touch devices don’t seem to have a problem decoding and playing music files (a fairly compute-intensive process) while in the background, so clearly the capacity is there.

I suspect this has more to do with avoiding competition for the (lucrative) SMS market than it does with processing capacity. It just seems a shame to have “always on” Internet access, then prevent the device from actually making use of it.

2) Applications are (reportedly) sandboxed from talking to each other at all. That makes some sense from a security standpoint, but is going to make it vastly more difficult to write any kind of mashup or add-on (for instance, a working spam filter for the Mail application).

3) This is the biggie: “No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built- in interpreter(s).”

Domain-specific languages (DSLs) are mini-languages that are designed to solve a specific problem. They’re pretty easy to write in some languages (especially Lisp but also in some modern scripting languages, such as Ruby). The advantage of a DSL is that you can create a mini-language which makes sense for the problem (or which makes sense to your users).
An example that’s been around for a while is the MIDI protocol for controlling electronic instruments. While I wouldn’t necessarily hold MIDI up as a good DSL, the idea is there — MIDI uses terms and concepts with which its users (muscians) are already familiar, rather than having them poke values in registers and hand-control oscillators. SCORM and IMS Learning Design might also be called DSLs, in a way.

Just about every education app I can imagine would benefit from some kind of scripting. I don’t know that I’d want to spend a lot of time writing a cool education app only to have some lawyer at Apple (for example, the one who wrote that clause) decide that my DSL was an “interpreter” and ban it from distribution (especially since the App Store is the only way to distribute your code).

I was excited by the SDK at first. Now, not so much.