Hacker News Reader

Comment by inglor_cz | Hacker News Reader

I wrote a lot of code for Symbian devices once.

The system was extremely efficient on low-powered machines (by which I mean both a slow CPU and a weak battery). As far as wringing maximum performance from hardware-that-be, I have never worked with a better system.

The learning curve of the API was insane, though (and the system dragged a lot of ancient pre-32-bit PSION/EPOC remnants within itself). So was the heterogenity of the devices. Every new device required some rewrite of existing apps, and Nokia pushed out dozens of them. On-device debugging mostly didn't work. Emulators were clumsy and bloated, but still lacked important APIs, such as sound.

At the end of the day, the system was so developer-unfriendly that everyone migrated happily to better pastures.

View on HN

> I wrote a lot of code for Symbian devices once.

I sympathize with you. The learning curve of the API indeed was insane. For example, here’s a description of its at least 8 different string classes (the intro mentions 7, but doesn’t mention RBuf) that you had to know about: https://www.developer.com/mobile/mastering-symbian-os-descri... (and that’s way better documentation than I remember seeing at the time)

It seems that every single Symbian development team that I knew developed their own wrapper around the insane Bufs.

What a loss of productivity, to do the same thing again and again.

It was the most robust way to write c++.

Ownership model in Symbian lead to really good memory efficiency. The testing tools made it really hard to import open source code cos it brought out all the memory correctness issues in addition to the usual porting problems. This was the safest systems code before rust came along.

Most devs did not understand that it was a "take your medicine for healthier code" situation and hated the dev experience

By the time I worked on Symbian, devices were far more powerful than what the Symbian API was designed for (and this was still before the iPhone). It made you jump through hoops that you didn't need to jump through anymore. I wrote a wrapper around their "7 kinds of buffer" API that made it at least a little bearable.

The burning platform memo was entirely accurate although Elop probably shouldn't have Osborned his company with it.

Bringing in Qt, and PIPS (P.I.P.S. Is POSIX on Symbian OS), in a Eclipse based IDE (Carbide), helped make the development experience much better, but then came Elop and ruined everything, with management's board help.

PIPS made it very clear that the way-forward was a unixish kernel/base system - as Apple did, as Android did, and in fact, years before either, as Nokia did with Maemo/Meego.

It was pure facade to say "continue with Symbian because PIPS + Qt". There were a lot of strange quirks in PIPS because the underlaying system/kernel wasn't unixish. And there were a lot of things all unixish systems as of 2008 already did well (multi-CPU, large memory) which Symbian really struggled with. Some of the "small-system optimisation" in Symbian (the single global service message port / queuing system) made it very hard to parallelize/scale out.

Nokia somehow was so uncomfortable with the idea of an opensource "base" that they rather bet on / sold out to Microsoft. But then, this is water down the river, and we will never know whether "alternatives" to the bet they made would have had better returns.

Reply on news.ycombinator.com