The Future of Programming

Here’s a talk I watched some months ago, and could’ve sworn I’d written a blogpost about. Ah well, here it is:

Bret Victor – The Future of Programming from Bret Victor on Vimeo.

It’s worth the 30min of your attention if you have interest in programming or computer history (which you should have an interest in if you are a developer). But here it is in sketch:

The year is 1973 (well, it’s 2004, but the speaker pretends it is 1973), and the future of programming is bright. Instead of programming in procedures typed sequentially in text files, we are at the cusp of directly manipulating data with goals and constraints that are solved concurrently in spatial representations.

The speaker (Bret Victor) highlights recent developments in the programming of automated computing machines, and uses it to suggest the inevitability of a very different future than we currently live and work in.

It highlights how much was ignored in my world-class post-secondary CS education. It highlights how much is lost by hiding research behind paywalled journals. It highlights how many times I’ve had to rewrite the wheel when, more than a decade before I was born, people were prototyping hoverboards.

It makes me laugh. It makes me sad. It makes me mad.

…that’s enough of that. Time to get back to the wheel factory.


Units and Data Follow-Up: Pokémon GO in the United Kingdom

Hit augmented-reality mobile gaming sensation Pokémon GO is now available in the UK, so it’s time to test my hypothesis about searches for 5km converted to miles in that second bastion of “Let’s use miles as distance units in defiance of basically every other country”:


Results are consistent with hypothesis.

(( Now if only I could get around how the Google Play Store is identifying my Z10 as incompatible with the game… ))


Units and Data: Pokémon GO

Topical Data Post: Pokemon Go

I live in Canada which means we hear a lot about things that are United States-only. The latest (and the largest, outstripping in volume and velocity even the iPhone (which I may misremember being the last must-have-thing back in 2007)) is the hit augmented-reality mobile game Pokémon GO.

One gameplay mechanic of Pokémon GO (I am told) revolves around hatching eggs. These eggs hatch not after a certain period of time, but after you have walked a certain distance with the application open on your phone.

The kicker is that the distance is measured in kilometres, a unit whose use the United States and United Kingdom have evaded (yes, despite the latter’s metrication since 1965). People in the United States are being confronted with unfamiliar distance units of 2km, 5km, and 10km.

This, via some Twitter jabs, lead me to Google Trends and a prediction: what if Pokémon GO’s release date in a region that still uses miles as a unit of distance could be detected simply through the rise in search volume for the term “5km”?

So far, the data for the United States is consistent:5km

I await the UK launch date to follow-up.


On Repeating Oneself

This is in response to ppk’s blog post DRY: Do Repeat Yourself. If you’re not interested in Web Development or Computer Science, or just don’t want to read that post, you may stop reading now and reward yourself with a near-infinite number of kittens.

A significant middle part of my career was a sort of Web Development coming from a Computer Science background. Working on the BlackBerry 10 Browser (the first mobile browser that was, itself, written as a web page) we struggled to apply, from day 0, proper engineering practices to what ultimately was web development.

And we succeeded. Mostly. Well, it was alright.

So maybe PPK is wrong! Maybe webdev can be CS already and it’s all a tempest in a teapot!

Well, no. The BB10 Browser had one benefit over other web development… one so great and so insidious I didn’t even notice it at the time (iow, privilege): We only had to build the page to work on one browser.

Sure, the UI mostly worked if you loaded it in Chrome or Firefox. That’s how we ran our tests, after all. But at the end of the day, it only needed to work on the BB10 version of WebKit. It only needed to be performant on the BB10 version of WebKit running on just a handful of chipsets. It only needed to look pretty on the BB10 version of WebKit on a handful of phones in at most two orientations each.

We could actually exhaustively test all of our supported configurations. In a day.

And this is where true webdevs would scoff. Because uncertainty is the name of the game on the Web. And I think that’s the core of why CS practices can’t necessarily apply to Web Development.

When I was coding the BB10 Browser, as when I do other more-CS-y stuff, I could know how things would behave. I knew what would and would not work. (and I could cheat by fixing the underlying browser if I found a bug, instead of working around it). I knew what parts of the design were slow and were to be avoided, and what cheap shortcuts to employ in what situations (when to use layers, when to use opacity, when to specifically avoid asking the compositor to handle it because the shaders were quick enough (thanks to mlattanzio, kpiascik, tabbott, and cwywiorski!)). I even knew what order things were going to happen, even when the phone was under load!

In short: I knew. Because I knew, I could operate with certainty. Because of that certainty, we wrote a browser in about a year.

But I know webdev is nothing like that. I’ve been on cross-browser projects since and tried to find that sense of certainty. I’ve tried to write features for screens of bizarre dimensions and groped for that knowledge that what I’d done would work wherever it needed. I’ve struggled to find a single performant and attractive solution that would work on all renderers and have felt the sting of my CS education yelling that I shouldn’t repeat myself.

I still scoff at the bailing-wire-and-ducttape websites that litter the web and bloat it with three outdated versions of each of a half-dozen popular frameworks. But, like the weather, I know the laws that motivate it to be so. Complaining is just my way of coping.

The question becomes, then, is there anything CS that can be applied to webdev? Certainly test-driven development and other meta-dev techniques work. The principles of UI design and avoiding premature optimization are universal.

But maybe we should be thinking of it the other way around. Maybe CS should accept some parts of webdev. Maybe CS educators should spend more time on uncertainty. Then CS students will start thinking about how much uncertainty they are willing to accept in their projects in the same way we already think of how performant or cross-platform or maintainable or verifiable the result needs to be.

I hope a few CS graduate students pick up PPK’s call for “Web Development from a Computer Science Perspective” theses. There’s a lot of good material here that can help shape our industries’ shared future.

Or not. I can’t be certain.


Mailing-List Mush: End of Life for Firefox on OSX 10.6-8, ICU dropping Windows XP Support

Apparently I’m now Windows XP Firefox Blogging Guy. Ah well, everyone’s gotta have a hobby.

End of Life for Firefox on OSX 10.6-8

The Firefox Future Releases Blog announced the end of support for Mac OSX 10.6-10.8 for Firefox. This might be our first look at how Windows XP’s end of life might be handled. I like the use of language:

All three of these versions are no longer supported by Apple. Mozilla strongly encourages our users to upgrade to a version of OS X currently supported by Apple. Unsupported operating systems receive no security updates, have known exploits, and are dangerous for you to use.

You could apply that just as easily and even more acutely to Windows XP.

But, then, why isn’t Mozilla ending support for XP in a similar announcement? Essentially it is because Windows XP is still too popular amongst Firefox users. The Windows XP Firefox population still outnumbers the Mac OSX (all versions) and Linux populations combined.

My best guess is that we’ll be able to place the remaining Windows XP Firefox users on ESR 52 which should keep the last stragglers supported into 2018. That is, if the numbers don’t suddenly decrease enough that we’re able to drop support completely before then, shuffling the users onto ESR 45 instead.

What’s nice is the positive-sounding emails at the end of the thread announcing the gains in testing infrastructure and the near-term removal of code that supported now-unused build configurations. The cost of supporting these platforms is non-0, and gains can be realized immediately after dropping support.

ICU Planning to Drop Support for Windows XP

A key internationalization library in use by Firefox, ICU, is looking to drop Windows XP support in their next version. The long-form discussion is on dev-platform (you might want to skim the unfortunate acrimony over Firefox for Android (Fennec) present in that thread) but it boils down to: do we continue shipping old software to support Windows XP? For how long? Is this the straw that will finally break WinXP support’s back?

:milan made an excellent point on how the Windows XP support decision is likely to be made:

Dropping the XP support is *completely* not an engineering decision.  It isn’t even a community decision.  It is completely, 100% MoCo driven Firefox product management decision, as long as the numbers of users are where they are.

On the plus side, ICU seems to be amenable to keep Windows XP support for a little longer if we need it… but we really ought to have a firm end-of-life date for the platform if we’re to make that argument in a compelling fashion. At present we don’t have (or at least haven’t communicated) such a date. ICU may just march on without us if we don’t decide on one.

For now I will just keep an eye on the numbers. Expect a post when the Windows XP numbers finally dip below the Linux+OSX as that will be a huge psychological barrier broken.

But don’t expect that post for a few months, at least.




Firefox’s Windows XP Users’ Upgrade Path

We’re still trying to figure out what to do with Firefox users on Windows XP.

One option I’ve heard is: Can we just send a Mozillian to each of these users’ houses with a fresh laptop and training in how to migrate apps and data?

( No, we can’t. For one, we can’t uniquely identify who and where these users are (this is by design). For two, even if we could, the Firefox Windows XP userbase is too geographically diverse (as I explained in earlier posts) for “meatspace” activities like these to be effective or efficient. For three, this could be kinda expensive… though, so is supporting extra Operating Systems in our products. )

We don’t have the advertising spend to reach all of these users in the real world, but we do have access to their computers in their houses… so maybe we can inform them that way?

Well, we know we can inform people through their browsers. We have plenty of data from our fundraising drives to that effect… but what do we say?

Can we tell them that their computer is unsafe? Would they believe us if we did?

Can we tell them that their Firefox will stop updating? Will they understand what we mean if we did?

Do these users have the basic level of technical literacy necessary to understand what we have to tell them? And if we somehow manage to get the message across about what is wrong and why,  what actions can we recommend they take to fix this?

This last part is the first thing I’m thinking about, as it’s the most engineer-like question: what is the optimal upgrade strategy for these users? Much more concrete to me than trying to figure out wording, appearance, and legality across dozens of languages and cultures.

Well, we could instruct them to upgrade to Linux. Except that it wouldn’t be an upgrade, it’d be a clean wipe and reinstall from scratch: all the applications would be gone and all of their settings would reset to default. All the data on their machines would be gone unless they could save it somewhere else, and if you imagine a user who is running Windows XP, you can easily imagine that they might not have access to a “somewhere else”. Also, given the average level of technical expertise, I don’t think we can make a Linux migration simple enough for most of these users to understand. These users have already bought into Windows, so switching them away is adding complexity no matter how simplistic we could make it for these users once the switch was over.

We could instruct them to upgrade to Windows 7. There is a clear upgrade path from XP to 7 and the system requirements of the two OSes are actually very similar. (Which is, in a sincere hat-tip to Microsoft, an amazing feat of engineering and commitment to users with lower-powered computers) Once there, if the user is eligible for the Windows 10 upgrade, they can take that upgrade if they desire (the system requirements for Windows 10 are only _slightly_ higher than Windows 7 (10 needs some CPU extensions that 7 doesn’t), which is another amazing feat). And from there, the users are in Microsoft’s upgrade path, and out of the clutches of the easiest of exploits, forever. There are a lot of benefits to using Windows 7 as an upgrade path.

There are a few problems with this:

  1. Finding copies of Windows 7: Microsoft stopped selling copies of Windows 7 years ago, and these days the most reliable way to find a copy is to buy a computer with it already installed. Mozilla likely isn’t above buying computers for everyone who wants them (if it has or can find the money to do so), but software is much easier to deliver than hardware, and is something we already know how to do.
  2. Paying for copies of Windows 7: Are we really going to encourage our users to spend money they may not have on upgrading a machine that still mostly-works? Or is Mozilla going to spend hard-earned dollarbucks purchasing licenses of out-of-date software for everyone who didn’t or couldn’t upgrade?
  3. Windows 7 has passed its mainstream support lifetime (extended support’s still good until 2020). Aren’t we just replacing one problem with another?
  4. Windows 7 System Requirements: Windows XP only needed a 233MHz processor, 64MB of RAM, and 1.5GB of HDD. Windows 7 needs 1GHz, 1GB, and 16GB.

All of these points are problematic, but that last point is at least one I can get some hard numbers for.

We don’t bother asking users how big their disk drives are, so I can’t detect how many users are cannot meet Windows 7’s HDD requirements. However, we do measure users’ CPU speeds and RAM sizes (as these are important for sectioning performance-related metrics. If we want to see if a particular perf improvement is even better on lower-spec hardware, we need to be able to divvy users up by their computers’ specifications).

So, at first this seems like a breeze: the question is simply stated and is about two variables that we measure. “How many Windows XP Firefox users are Stuck because they have CPUs slower than 1GHZ or RAM smaller than 1GB?”

But if you thought that for more than a moment, you should probably go back and read my posts about how Data Science is hard. It turns out that getting the CPU speed on Windows involves asking the registry for data, which can fail. So we have a certain amount of uncertainty.


So, after crunching the data and making some simplifying assumptions (like how I don’t expect the amount of RAM or the speed of a user’s CPU to ever decrease over time) we have the following:

Between 40% and 53% of Firefox users running Windows XP are Stuck (which is to say, they can’t be upgraded past Windows XP because they fail at least one of the requirements).

That’s some millions of users who are Stuck no matter what we do about education, advocacy, and software.

Maybe we should revisit the “Mozillians with free laptops” idea, after all?