Good meeting with my supervisor (Des Watson) on campus today, discussing my dissertation: which is to produce a superoptimiser for the Java Virtual Machine, both to evaluate the approach in the context of VMs (no-one's looked at this yet, as far as I can see) and to look at how practically useful it could be. It's very early days - technically the first week I've worked on it, though I've done a few days here and there to distract myself from revision.

I'm close to having a toy implementation of a working superoptimiser for Java bytecode (though there's a lot to do once that's ready), and I've been working through literature this last week. Tom Crick did some work on using Answer Set Programming to generate formally proven optimal code, and I've revisited an old (and probably classic, by now) Tanenbaum paper on peephole optimisation of intermediate code. The latter is quite relevant because it proposed an architecture which is at least superficially similar to the JVM.

I've also dipped into the world of formal proofs, courtesy of an email chat with Bernhard Reus: Abstract Interpretation, static program analysis, formal verification of machine code programs and Model Checking. Here I'm less confident: a lot of the work seems quite theoretical, that which is practical is not authoritative (understandably so given the undecidability of some key underlying problems), and if it's approximate, then what's the advantage of formal proof over oodles of statistical testing?

Des and I chatted a bit about test data and the need to avoid inadvertently producing algorithms which are tied to closely to test data; he warned me (again) about the complexities that branching code will bring to both equivalence testing and pruning candidate sequences; and we talked about minimal looping routines that could be usefully tested: one to sum the elements of an array, then find min/max elements, and then to sort. I'm not sure if I'll get onto them. My feeling is that I'll manage to get to about 6-7 length sequences in the course of this project, but without a bolt of enlightenment will struggle to go further. Currently a sequence 3 long involves considering 278,614 candidate sequences; one 4 long produces so many that I got bored of waiting for my laptop to count them ;)

I've floated the idea of reverse-engineering algorithms from optimal sequences generated; we reckoned that to do anything useful with this, you'd need 12-16 long sequences of instructions, which feels a way off. Still, Des seemed super-excited and I left the meeting buzzing.

As an aside, this time of year my weekly jaunt onto the green and wooded landscape of Sussex University is an absolute pleasure...

Nice article from Alex May on approaches to ensuring the longevity of digital art (and code in general): "As a digital artist, I now try to write code that should last for a hundred years or more. I don't think of it as egotistical. I see it as a technical challenge."

A little package turned up in the post yesterday - the folks at Blackberry sent me a Playbook to have a little noodle with. Here are some observations from a preliminary noodling.

On the hardware:

• I rather liked the size and shape. Unlike the Kindle and iPad, the primary orientation for the device seems to be landscape, not portrait. This works quite well; it was good for gaming and when held in two hands, my thumbs could reach pretty well anywhere on-screen.
• The edge around the screen is touch-sensitive, and the device uses this to have some nice "stroke onto the screen", "push off the screen" interactions. I think RIM may have missed a trick by not making more of these; one big problem with touchscreen UI is that parts of the screen are hidden by your hands. Making more of touch-sensitive areas to the side, or above and below, would allow for perfect selection of specific areas on screen, or easier scrolling actions that don't obscure any pixels.
• The device is weighted well (it feels balanced) and the back is made of a durable-feeling rubber. Overall it gives a sturdy sensation, unfortunately backed up by a slightly sluggish but reliable UI (I've yet to see a crash).

On the bundled software:

• Visually the UI feels weak: lots of dark colours (shades of blue) make some of the iconography less visible than it should be, and the screen is lower-than-retina resolution - so the pin-sharp clarity I'm increasingly used to just isn't there.
  
• Interaction-wise I felt it was a bit better; there's a nice UI to get across the idea of multitasking apps in the launcher, consistent ways to leave the app you're in and swap to another, good use of animation to emphasise changes in states of applications, and so forth. I think I'd put it ahead of iOS when it comes to app-swapping.
  
• However there were plenty of times in use when I felt I needed reassurance - totally blank screens whilst an app loads, or a spinner and no indication of how long I should wait.
  
• The email client and calendar are both pretty solid - not amazing, but sturdy-feeling. I've never used a "traditional" Blackberry email client so don't know how it compares. Setting up my GMail account was trivially easy.
  
• Bing Maps was, err, quite nice. Less featureful than Google but I like the aerial view with multiple angles, and the maps seemed readable.
  
• The browser works quite well: I gave a few of the Google web apps a go. Reader is usable, but the screen size means that tap targets frequently get muddled up, and I wasn't able to up the font size of the browser to compensate for this.
  

On downloadable apps:

• App World seems to work OK; there's a reasonable catalogue of apps. Is it my imagination, or is there a tendency towards paid-for downloads on the Blackberry? Angry Birds for a fiver seemed unusually expensive.
• There's no Kindle app for the Blackberry. That's a massive loss - when I get a new device it's one of the first things I install. The idea of having a portable which I can't read my books on is a bit uncomfortable.
• I grabbed a free copy of a FPS game: a 400MB download which took some time even over wi-fi, but once downloaded it played well. The Playbook is a good size for a gaming device, fitting comfortably in two hands: I'm not a massive gamer, but I don't think the iPad is quite the right size and shape for that style of play.
• I visited app.ft.com and after seeing a loading screen, was redirected to a /playbook and a 404 page - looks like something at the FT end of things.

One other nice touch: a "welcome" email from RIM with a few links to help, arriving a day after I set up the tablet. Very sweet.

I'm going to give the device a bit more time over the coming week, and report back here. Overall it seems OK, but not enough wow to compete with the iPad head-to-head (I've not really used Android tablets before so can't provide much of a comparison there). Then again, with a £169 price-point in some stores, it's cheaper than most right now...

So this is what developing for Android looks like, eh? Well, it's not like that's anything new - here's the FP table-of-devices back in 2005, and I can assure you that between then and 2010 (when they were all stolen in a couple of burglaries) we ended up taking our selection to over 150.

They all ran different operating systems and had radically different Java runtimes: different devices had different maximum sizes for their JAR files, screen sizes were all over the place, UI elements rendered differently, sometimes important APIs just wouldn't work (ISTR a missing implementation of available() on a Samsung device).

I hope I'm not coming over all Four Yorkshiremen. I don't think many of us who worked through those days and learned how to ship products on a few hundred devices feel too nostalgic.

My point is that even with the diversity of Android devices today, things are way better than they were: fragmentation can't be ignored, but you don't need to test on every conceivable combination of devices. Plus, not all fragmentation issues are down to the device. Here's an interesting piece from the CEO of Zipline making this point: "Yes, there were device differences but most of our problems were rooted in classic software engineering issues. We did see some crashes on specific devices, but the catalysts were devices that have less memory or run more processes which were causing the underlying issues to be exposed more often."

And let's not forget the phenomenal growth in smartphone uptake since the days of J2ME, or the fact that Real People seem to use apps in ever-increasing numbers. The audience is larger nowadays; putting in less effort to reach a larger audience feels like progress to me.

I can't help but notice that the developer TechCrunch interviewed for their story was quite accepting: "We like fragmentation as users prefer choice. We are not big believers that one size fits all". Why did they run a story complaining about the issues, based on a company who had no complaint?

I'm absolutely loving some of Harry Brignull's recent posts: clear, authentic writing, drawing on experiences from real projects. Why don't more people write like this?

Pop over to this one, which talks about the design process for the iPad edition of The Week:

"It tanked bigtime. Suddenly I realised that usability testing is only fun when it rips apart someone else’s work! When you’ve spent weeks selling the idea to your client’s stakeholders, it’s pretty depressing.

Looking back on it, we made the classic architect’s mistake of designing for a fictitious user behaviour that only existed in our heads."

I think there's still a tradition of businesses not admitting to their mistakes; maybe there's a fear around legal liability or admissions of negligence underpinning this, maybe it's ego.

I felt I had to pretend everything was perfect during the early years of FP, and I like the fact that this is changing: that organisations like MDHub exist to let business owners discuss failures and problems with each other behind closed doors; that some people and companies openly take a philosophy that "if you're not failing occasionally, you're playing it too safe"; and that there's even a conference where failure stories are showcased for us all to learn from. More of this, please.

(Oh, and whilst I have your attention here's another tasty treat, via Alex G: the ancestors of GPS).