Structure and Interpretation of Computer Programmers

I make it easier and faster for you to write high-quality software.

Wednesday, September 14, 2011

On Windows 8

Right from the beginning, you have to accept that this analysis is based on the presentation of Windows 8 shown at the //build/windows conference. I’ve watched the presentation, I’m downloading the developer preview but I’m over an hour away from even discovering whether I have anything I can install that on.

My biggest concern

The thing I was most worried that Windows 8 would bring was yet another chance for Microsoft to flub their developer experience. If you think about it, Microsoft’s future now depends more than it has on any time since the 1980s on their third-party developers. Whereas they used to be able to rely on OEM licensing deals (and strongarming) to ensure that people wanted to use their stuff, that’s starting to wane.

Sure, the main desktop Windows-NT-plus-Active-Directory-plus-Office-plus-Exchange core is still going strong. But look at the web stack: servers are IIS or Apache or one of various other servers that support Rails, PHP and so on. They’re hosted on my Wintel boxen or my Lintel boxen or one of various third-party choices (including Microsoft’s own Azure). The client is a browser (based on anything) or a native mobile app on Windows Phone 7 or one of a handful of other native app platforms, including iOS and Android.

Where Microsoft have the potential to win over all of their competitors is providing a consistent developer experience across the whole of their stack. This isn’t about locking developers in, this is about making it easiest for them to do Microsoft end-to-end.

Consider Apple for a moment. They have a very consistent experience for writing desktop apps and mobile apps, with Cocoa and Cocoa Touch. Do you want to write server software? You can do it on Apple kit, but not with Apple tools. You’ll probably use Rails or another open source UNIX-based stack, at which point you may as well deploy it to someone else’s kit, maybe someone who offers rackmount hardware. You can use iCloud on Apple’s terms for distributed storage, but again if you want generic cloud computing or a different approach to cloud storage, you’re on your own.

On the other hand, Microsoft offers a complete stack. Azure, Windows Server, WPF (desktop client) and SilverLight (browser and phone) all have the same or very similar APIs in the same languages, so it’s easy to migrate between and share code across multiple layers in a complete computing environment.

But, would they do that? The one place where Microsoft itself seems to have failed to recognise its own strength is in the Windows division. They “pulled a Solaris”, and have consistently ignored .NET ever since its inception, in just the same way that the Solaris Operating Environment team in Sun ignored Java. That leads developers to think there must be something wrong with the tech if real developers inside the company who made it don’t want to use it.

So when Microsoft (or rather, Steve Ballmer) announced that the Windows 8 SDK would be JavaScript and HTML5, it made me think that the Windows 8 team might have jumped the shark. That stuff isn’t compatible with C# and XAML, or with the .NET APIs. I thought they’d got themselves into the position where their phone is SilverLight, their desktop/tablet is HTML5 (except legacy stuff which is Win32), their server is .NET… ugh.

So what happened?

Well, in a nutshell, they didn’t do that. The need for a new runtime makes sense because the .NET runtime was only ever a bolt-on on top of Windows, leading to interesting compatibility issues (to run App version x you need .NET version y and Windows version z; but OtherApp version a wants .NET version b). But the fact that the new HTML5 stuff is actually layered on top of the same runtime, and provides access to the same APIs as are available in C#, VB and C++ makes me believe that Microsoft may actually understand that their success depends on developers adopting their entire stack.

I’ll make this point clear now: HTML5 is not the future of app development. Its strength is based on a couple of things: every device needs a high-performance HTML engine anyway in order to provide web browsing; and HTML5 should work across multiple devices. Well, as a third-party developer, the first of those points is not my problem, it’s Microsoft’s problem, or Apple’s, or RIM’s. I don’t care that they get to re-use the same HTML renderer in multiple contexts.

The second of those points will quickly disintegrate when every platform vendor is trying to differentiate itself and provide an HTML5 development environment. Did you see that Expression Blend for HTML demo? That’s a very cool tool, but the demo of using “standard HTML5” relied on a keyword called “ms-grid”. Wait, MS? Is that cross-platform HTML? Also observe that the JS needs to call into the WinRT API, so this really isn’t a cross-platform solution.

No, for me the big story is that you can use C# everywhere: currently with .NET in most places and WinRT on the desktop. Any client application can use XAML for its user interface. That’s big for ecosystem-wide development. There’s one thing I need to learn in order to do mobile, tablet, desktop, server and cloud programming. It’s slightly weird that the namespaces on .NET and WinRT are different, and it would be a good strategic move to support the new namespaces in newer versions of SilverLight (i.e. in Windows Phone 8).

What else happened?

I’m not going to talk much about Metro, it’s a well-designed UI that works well. I’m not sure yet how it works if you’re interacting through a mouse or trackpad. I spoke about it before when discussing Windows Phone 7; where I also expressed my belief that sharing the developer experience across desktop and phone was a good move.

What I will point out is that the Windows team no longer think that they can do what they want and people will buy it. They’re noticing that the competition exists, and that they need to do better than the competition. In this case, “the competition” is Apple, but isn’t Google.

Why do I think that? Sinofsky felt comfortable making a joke about “Chrome-free browser experience”, but the iPad was the elephant in the room. Tablets/slates/whatever were summarised as “other platforms”, although you feel that if Microsoft had a point to score over Android they would have mentioned it specifically.


This means that – perhaps with the exception of Office – Microsoft’s complacency is officially behind it. Sure, Windows 7 and Windows Phone 7 were indications that Microsoft noticed people talking about them falling behind. But now they’ve started to show a strategy that indicates they intend to innovate their way back to the front.

While it’s currently developer preview demoware, Windows 8 looks fast. It also looks different. They’ve chosen to respond to Apple’s touchscreen mobile devices by doing touchscreen everywhere, and to eschew skeuomorphism in favour of a very abstract user interface. Importantly, the Windows APIs are now the same as they’re getting 3rd-party developers to use, and are the same as (or very similar to) the APIs on the rest of their platforms.

posted by Graham at 10:31  

Tuesday, September 6, 2011

Don’t be a dick

In a recent post on device identifiers, I wrote a guideline that I’ve previously invoked when it comes to sharing user data. Here is, in both more succinct and complete form than in the above-linked post, the Don’t Be A Dick Guide to Data Privacy:

  • The only things you are entitled to know are those things that the user told you.
  • The only things you are entitled to share are those things that the user permitted you to share.
  • The only entities with which you may share are those entities with which the user permitted you to share.
  • The only reason for sharing a user’s things is that the user wants to do something that requires sharing those things.

It’s simple, which makes for a good user experience. It’s explicit, which means culturally-situated ideas of acceptable implicit sharing do not muddy the issue.

It’s also general. One problem I’ve seen with privacy discussions is that different people have specific ideas of what the absolutely biggest privacy issue that must be solved now is. For many people, it’s location: they don’t like the idea that an organisation (public or private) can see where they are at any time. For others, it’s unique identifiers that would allow an entity to form an aggregate view of their data across multiple functions. For others, it’s conversations they have with their boss, mistress, whistle-blower or others.

Because the DBADG mentions none of these, it covers all of these. And more. Who knows what sensors and capabilities will exist in future smartphone kit? They might use mesh networks that can accurately position users in a crowd with respect to other members. They could include automatic person recognition to alert when your friends are nearby. A handset might include a blood sugar monitor. The fact is that by not stopping to cover any particular form of data, the above guideline covers all of these and any others that I didn’t think of.

There’s one thing it doesn’t address: just because a user wants to share something, should the app allow it? This is particularly a question that makers of apps for children should ask themselves. Children (and everybody else) deserve the default-private treatment of their data that the DBADG promotes. However, children also deserve impartial guidance on what it is a good or a bad idea to share with the interwebs at large, and that should be baked into the app experience. “Please check with a responsible adult before pressing this button” does not cut it: just don’t give them the button.

posted by Graham at 11:00  

Friday, September 2, 2011

So you don’t like your IDE

There are many different tools for writing Objective-C code, though of course many people never stray much beyond the default that’s provided by their OS vendor. Here are some of the alternatives I’ve used: this isn’t an in-depth review of any tool, but if you’re looking for different ways to write your code, these are tools to check out. If you know of more, please add to the comments.

In most cases, if you’re writing Mac or iOS apps, you’ll need the Xcode tools package installed anyway in order to provide the SDK frameworks (the libraries and headers you’ll be linking against). The tools basically provide a different user interface to the same development experience.

A word on IDEs. The writers of IDEs have an uphill struggle, in that every user of an IDE assumes that they are a power user, though in fact there are a wide range of abilities and uses to which IDEs are bent. My experience with Eclipse, for example, ranges from learning Fortran 77 to developing a different IDE, in Java and Jython, using the same app. Visual Studio is used to write single screen line-of-business apps in Visual BASIC, and Windows. Different strokes for different folks, and yet most IDEs attempt to accommodate all of these developers.


CodeRunner is not a full IDE, rather it’s a tool for testing out bits of code. You get a syntax-highlighting, auto completing editor that supports a few different languages, and the ability to quickly type some code in and hit “Run”. Much simpler than setting up a test project in an IDE, and only a handful of denarii from the App Store.


AppCode is the engine from well-respected IDE IntelliJ IDEA, with Objective-C language support. Its language support is actually very good, with better (i.e. more likely to work) refactoring capabilities than Xcode, useful templates for creating new classes that conform to protocols with default implementations of required methods, and quick (and useful!) navigation categories.

AppCode uses Xcode project files and workspaces, and uses xcodebuild as its build system so it’s completely compatible with Xcode. It doesn’t support XIBs, and just launches Xcode when you try to edit those files.

It’s also important to notice that AppCode is currently available under an “early access” program, with expiring licences that force upgrade to newer builds. There’s no indication of when AppCode will actually be released, and what it will cost when it gets there. For comparison, the community edition of IDEA is free while the “Ultimate” edition costs anything up to £367, depending on circumstances.


Emacs’s Objective-C mode is pretty good, and it can use ctags to build a cross-file symbol table to provide jumping to definition like a “real” IDE. In fact, it would be fair to say that emacs is a real IDE: you can interact with version control directly, do builds (by default this uses Make, though you can easily tell it to run xcodebuild instead), run your app through gdb and other goodies.

That said, I think it’s fair to say that emacs is only a powerful tool in the hands of those who are comfortable with Emacs. It’s only because I’ve been using it forever (I actually started with MicroEmacs on AmigaOS, and wrote LISP modes in my Uni days) that I even consider it an option. It’s nothing like an app on any other system: Cocoa’s field editor supports a subset of emacs shortcuts but otherwise emacs feels nothing like a Mac, UNIX, Windows or anything else app. (Before the snarky comments come in, vim is just as odd.)


There are more ways out there to write your Objective-C code than just Xcode. These are a few of them: find one that works well for you.

posted by Graham at 13:46  

Powered by WordPress