In the light of the Raspberry Pi project’s attempt to reintroduce kids to the idea that a computer is something you program, I thought I’d share with you something from my own childhood. Specifically, a book:

Unlike more modern children’s books, it doesn’t state a target age, but I believe it’s aimed at junior school children¹. As you can see, it’s illustrated by with lots of little cartoon robots acting out the various operations that occur in a computer. And it teaches you machine code.

I can imagine some readers reaching for their pedantic hats. “This man is a fool,” they’re thinking, “who clearly doesn’t know what ‘machine code’ is. He obviously means ‘assembly language’.”

Au contraire².

You see, in the mid-eighties, computers weren’t quite so impressively specced as they are today. Unless you had the Rolls Royce of home computers, the BBC Micro³, you wouldn’t have had the luxury of an assembler. You had a BASIC interpreter, and you considered yourself lucky. The book provides a listing for you to type in. This isn’t an assembler, of course: it’s just a program that allows you to type in bytes, in hex, to be poked into consecutive locations in memory. Once you’ve learnt hex on page 11, of course.

In 48 uncrowded, extensively illustrated pages, it goes from explaining things like binary and the difference between RAM and ROM, through addressing modes and registers, to writing real (if simple) machine code programs. In two different architectures, on half a dozen mutually incompatible computers. This is an impressive scope for such a slim book, made even more ambitious when you consider it’s aimed at children.

The important message is that this level of depth doesn’t scare kids off; instead, they lap it up (some of them, at least). By all means provide simpler material for those without the time, inclination or ability to tackle the complicated stuff. Just make sure you provide something challenging to keep the interest of those who can.

Today saw the official launch of the Raspberry Pi low-cost computer. Although there have been a couple of hiccups due to the distributors not expecting the phenomenal levels of demand¹, it’s still a big day for the project, and a testament to the months and years of the hard (and unpaid) work of everyone at the Raspberry Pi Foundation².

However, it’s worth remembering that the project is not about cheap computers for hobbyists (although that’s a useful side-effect); it’s about giving kids the tools with which to learn to program. To that end, here’s a video from the BBC’s Rory Cellan-Jones (who has also written a great article about the launch):

Yesterday, Matthew Bloch, MD of Bytemark Hosting¹, tweeted:

next stop: no installations on your own computer from outside the walled garden. A free desktop is much more important.

He was referring to Apple’s announcement that they’ll soon be requiring all apps sold via the Mac App Store to implement sandboxing. Broadly speaking, this strictly limits what an individual app could do once installed - for example, it can’t access files outside it’s own area without going through the standard save and restore dialogs. Mac OS X’s younger sibling, iOS, has had even stricter sandboxing in place since it first allowed third-party applications. It also has another property, namely that the App Store is the only way to install applications under iOS. Matthew’s worry is that Apple’s adoption of one iOS policy (sandboxing) on the Mac suggests that they’re likely to adopt another, and forbid installation of non-App Store apps.

Personally, I think the two are separate issues. Sandboxing is a sensible policy in its own right. It’s a key component of the success of the iOS App Store - the fact that you don’t need to worry about the developer’s incompetence or malice before downloading that 69p impulse buy. Relatively few applications actually need to do things that sandboxing prevents, like alter system settings. For the rest, sandboxing allows the ease-of-use and convenience that iOS users have grown used to.

It’s not like sandboxing is even a new idea. Not only did Java applets (remember those?) give it a go in the late 90s, but Mac OS X’s own version has a lineage stretching back to chroot jails, introduced to Unix in 1979. The idea that every program a user runs has to be able to do anything that that user is not an absolute, and there’s nothing inherently wrong with a user choosing to restrict the facilities available to specific programs. All modern systems do this to an extent, by restricting root privileges to programs explicitly granted them. Sandboxing could be thought of as simply a more fine-grained version of the same idea.

Restricting installation to only the official App Store, on the other hand, represents a significant break from the current status quo. At present, if I want to install a random piece of software from some shady corner of the internet on my Mac, I am free to do so, and live with the consequences. Channelling all installations through the App Store (and Apple’s somewhat mercurial review process) doesn’t give me this option. For many users, who just want to get work done, and don’t want to worry about maintaining their computer, this might be a reasonable trade-off, but for others (such as myself), it is not. However, it’s important to remember that this isn’t an all-or-nothing distinction. For example, I’d want Galcon Fusion to be sandboxed, but still build Emacs myself. If I lose the option of installing arbitrary software, though, the range of things I could do on Mac OS as opposed to another system would be severely curtailed. I don’t think there’s much risk of this happening, for two reasons.

Firstly, the people that such a move would alienate - developers, designers, and those who see themselves as power users - are the sort of people who are willing to pay a premium for high-end hardware. Whilst not as numerous as general consumers, this group must still be a significant source of profit for Apple, and so they’d need a good reason to abandon them. Furthermore, many of these users are the very people who keep the App Store stocked with high-quality products. Driving them away would, in my opinion, be a significant own goal.

Secondly, and more importantly, why do they need to? Apple already sell a walled-garden OS for people who want it, and the devices that use it sell pretty much as fast as Apple can manufacture them. They don’t need to sneak a walled garden in via the back door, because they’ve already kicked down the front. My expectation is that Mac OS will be increasingly seen as a “Pro” platform, and iOS as the way for general consumers. This is arguably no bad thing, as it allows people to use computers for what they actually want to do without having to worry about servicing and maintaining them (I touched on this in a previous post). As John Gruber points out the Mac/iOS division allows Apple to cater for those of us who want the flexibility offered by a general purpose system, whilst not burdening everyone with the attendant complexity. And if at some point they choose to stop catering for us, there are plenty of others who will.

Update: Mathew has responded on his blog. He makes some interesting points. Most importantly, he points out that Apple already charges developers $99 per year. Root access could be restricted to these developers (and anyone who paid the fee could join them), whilst not providing it for regular users. The latter would effectively be handing over both the hassle and the control of auditing the software on their machine to Apple, a bargain that many people would consider reasonable (and one that most people already make with, for example, their email).

The fallout for developers would be that they could no longer rely on end users being able to install software themselves, and therefore everything would have to go through the App Store, with Apple taking their 30% cut. For many small developers, this again is a good bargain - the simplicity of the App Store, plus the trust user’s have in it, are worth Apple’s cut (and the small but non-zero risk of running into problems with the review process). However, as Matthew points out, big developers such as Adobe and Microsoft are less likely to be happy, and could go as far as abandoning the platform.

That’s a key reason I don’t think that Apple are likely to go down this route. Over the last decade, Mac OS X has gone from having the scantest selection of third-party software to having arguably the best. Part of this has come from the kinds of small commercial developers that are a natural fit to the App Store, but it also comes from big-name applications like Office and Creative Suite. Losing these applications would be a significant blow to the platform, and I’d be surprised if the additional App Store revenue would make up for it. Indeed, it’s not at all clear that there would be any additional revenue, given that the change would result in users leaving a Mac OS that no longer met their needs.

More importantly, the end result of this game makes no sense. Why would Apple turn Mac OS into another iOS, when they already have iOS? If people are choosing between a hassle-free/locked-down device (depending on your perspective) and a more flexible/fragile one, why would Apple not want a product on both sides? The only reason would be that one side doesn’t make enough money to justify pursuing. I don’t think that’s the case, but if and when it is, I wouldn’t expect them to turn Mac OS into iOS. They’ll just stop selling it.

In conclusion, I don’t expect Apple to remove the ability to install arbitrary applications from Mac OS in the foreseeable future, not through any moral compunction or fear, but simply because I don’t think it would increase their profits in the long term. I could be wrong about this; Apple clearly know their business better than I do. We’ll see.

In the past two weeks, there has - justifiably - been a lot of coverage of the death of Steve Jobs. However, two other computing pioneers have also died during that time. Dennis Ritchie and John McCarthy were not the household names in the same way, but their contribution was arguably more fundamental. Whilst Job’s work made modern computing accessible, Ritchie’s and McCarthy’s made it possible. They created, respectively, C and Lisp, which are essentially the Greek and Latin of programming¹.

In a field which values the new over the old to an almost pathological extent, these two languages have lasted for decades. If someone embarking on a new software project tomorrow using, say, PL/I, it would seem like an obtuse exercise in nostalgia. Use C, on the other hand, and nobody would raise an eyebrow. Lisp’s influence is less obvious, but arguably more profound. Whilst you can still use it in unadulterated form, relatively few people do. However, the popular dynamic languages that all the cool kids are using - Python, Ruby, JavaScript - are essentially Lisp in new clothes².

The origins of the two languages are instructively different. C was created to solve an immediate practical problem - writing Unix in a portable way. Moreover, it was targeting relatively modest hardware, the PDP-11³. It therefore lacks some of the bells and whistles that, even in 1973, “real” languages were thought to need. However, instead of limiting its scope, this resulted in an elegant simplicity that has seen it adapt to four decades of hardware improvements whilst many “real” languages have fallen by the wayside.

In contrast, Lisp wasn’t intended to be a language to solve a particular practical problem. It wasn’t intended to be a programming language at all. McCarthy had written a paper outlining a theoretical system for formally describing algorithms. Fortuitously, he didn’t make the “theoretical” part clear to one of his grad students, who promptly went off and implemented it on the department’s computer, creating the first Lisp interpreter⁴. What had started as a mathematical model of programs turned out to be an amazingly flexible and powerful way to actually write them.

What both languages have in common is that they each have a small, conceptually coherent core. Because it’s small and coherent, the programmer is able to internalise the basic concepts of the langauge. This done, they’re free to concentrate on the task at hand, rather than the details of the language. This is also why they’ve lasted so long - simple, clear ideas date far less quickly than specific technologies.

You might wonder why, in an post about two men who have recently died, I’ve not said much about their lives. The reason is simple; I didn’t know them, and so I’ll leave the biography to those who did. Like millions of other people, though, I do know their work. Both have had an enormous impact on a field that touches the lives of almost everyone, and will continue to do so for a long time to come.

Here’s a quick demo I’ve put together, showing the RaspPi running as a VNC client:

The setup is a slightly unusual one; instead of the client connecting to the server, it runs in listen mode, and the server initiates the connection. This allows the RaspPi to be used as a kind of shared, network display. The software on the RaspPi end is TightVNC, which is available in the Debiam ARM repository. On the server side, I used Vine Server, as the built-in server on Lion doesn’t support reverse connections (if you want to use the normal client/server arrangement, the built-in server is fine).

The reason that VNC supports this back-to-front arrangement is interesting in itself. ORL (later AT&T Labs Cambridge), the birthplace of VNC, also took a significant interest in location-aware computing, firstly with the Active Badge, which could track users to the granularity of a room, and then with the Active Bat, which could do so within a few centimetres. I worked at the lab for a year before starting my PhD (which they sponsored), in the project exploring the sort of applications you could build with this sort of technology.

One of the simplest and most effective was display teleporting. If you wanted to show someone your screen, you just held your Bat (or, in earlier versions, your Badge) against their monitor and pushed a button. Hey presto, via the magic of VNC reverse connection, there it was. Even though this application hasn’t exactly become ubiquitous, the reverse connection mode that was added to VNC to support it has remained a standard and useful feature. The location-aware technology lives on as well.