The Power – And Tyranny – of Abstractions

One of my favorite toolkits is the Qt toolkit from Nokia. Qt is a toolkit for developing cross-platform GUIs that is available under both an open source and commercial license. It was first developed in 1991 and led to the formation of Trolltech in 1994. In 2008, Nokia bought Trolltech which caused quite a stir in the Qt community (see the comments on this Qt Labs announcement of the acquisition).

Trolltech had made a considerable investment in mobile GUI and platform development for Qt. The fear was that Nokia would close source Qt and shutdown development of the Desktop side. To their credit, Nokia promised the community they would not do this – and they've been good to their word. Ars Technica (which always has the best coverage of Qt) recently covered the new features coming in Qt 5.

Qt started off as a pure C++ toolkit and with Qt 5, Nokia has made it clear that the future of Qt is now their Qt Quick technology – a declarative GUI syntax with JavaScript runtime. (Sound familiar?)

Before getting into Qt Quick, it's worth stepping back and looking at the big picture – the picture of how Qt relates to its surroundings.

Abstractions and Layers

Qt's original reason for existence is to create a new GUI toolkit abstraction on top of multiple operating systems with their own native GUI toolkits. For instance, on Windows, you would write an application in C++ referencing the Qt QWidget family of controls that were themselves implemented on top of the Windows GDI.

Qt's appeal was that if you wanted to then run that same application on Mac OS X or Linux, you could take your C++ source code and with just minimal changes recompile and run your applications on those platforms. The QWidget control implementations on the other platforms would translate the Qt calls into Cocoa or XWindows calls as needed.

In essence, what Qt did was create a new windowing abstraction in their toolkit on top of the platform's native GUI toolkit. This new abstraction was very powerful for developers that needed to develop applications that were cross-platform and who didn't want to write a completely separate application for each platform.

Everything about this scenario sounds great on paper. The clouds only start to gather when you actually get down into the details. And that's when the abstraction begins to bear down upon you.

The Tyranny of Abstraction

Steve Jobs famously posted his open letter "Thoughts on Flash" during his battles with Adobe. In it, he focuses on the issues of Flash on iOS – but he might as well have been talking about Qt:

We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.

What happens with technology like Qt is you are locked into their abstraction and as a result locked out of the platform's native abstractions – both for good and bad. The good is that you don't have to deal with the platform differences. The bad is that you don't get to take advantage of the platform differences.

The Chains That Bind You

Now don't get me wrong; I'm a big fan of Qt. But you have to be realistic about the tradeoffs that its abstractions impose on you and your project. For comparison sake, take PyQt as an example.

It would be easy to take potshots at C++ but let's just say we prefer Python instead. PyQt layers a Python abstraction over Qt so you can use it from that language. The difference between this abstraction layer between Python and C++ on the one hand and Qt's abstraction and the native platform's GUI on the other is the thickness. PyQt is a very thin abstraction that basically is more of a "translation" than a new abstraction. There is very little of Qt you can not access and use through PyQt.

This concept is what takes us back to Qt Quick. Qt has traditionally been regarded as a "cross-platform application framework". With this new emphasis on Qt Quick, I believe Nokia is taking a serious risk. Qt Quick is not a thin abstraction like PyQt on top of the C++ base. It consists of new concepts, behavior, syntax and languages. In other words it is another thick abstraction on top of the already thick abstraction of the C++ framework.

No Win Scenario?

If Nokia doesn't manage this transition well, I believe they risk turning Jobs lament about Flash on iOS into a prophetic prediction of Qt's demise. If Qt Quick becomes another thick abstraction on top of an already thick C++ abstraction, all of the negative effects Jobs points out will not be alleviated. They will only be compounded – and they are already being felt.

On the other hand, let's say Nokia pulls this off and the result is a new single, coherent, Qt Quick abstraction between your application and the native platform. An abstraction that includes a declarative GUI language. And a JavaScript runtime. Sounds an awful lot like a web browser.

After all of this work, will they end up with something the market regards as nothing more than a proprietary web browser? And at the same time will they expose themselves to new competitors with a non-standard solution in a market dominated by standards-based solutions?

Only time will tell.