(I’m reposting these from discussion.epoc.C++, since it’s not available on the net)
I've now programmed Symbian for three years, and have an extended (150 KLOC) codebase that does various fairly complex things (a client-server blackboard, serialization framework, network protocol implementations, several GUI applications, resource handling, watchdog, stack tracing, platform integration). In the beginning my productivity increased as I grew familiar with the conventions and libraries, but I hit a productivity wall maybe 1,5 years ago. Everything still takes a *very* long time. Every time I need to do something new, use a library I haven't used before or interact with a new part of the platform it's the same thing: components are not documented (most of AKN, b-trees, customizing CActiveScheduler, using Debug APIs), the things actually necessary are called 'non-public' (data calls, caller id, cell id, full-duplex audio, profiles, Shared data, vibration, bluetooth control) which means there is _really_ no documentation although things _do_ work when you figure them out, or buggy (Bluetooth stack crashes, phone loses all GSM connectivity if two pieces of code try to open a GPRS connection at the same time, phone freezes/reboots if you make a mistake with some APIs, having an MMS Mtm open when a multi-attachment MMS comes in sometimes makes the reception fail). This is of course all Series-60 - no wonder most of the hobbyists are on UIQ/SonyEricsson - but most consumers are on Series 60.
But it's not just Series 60. The abstraction level of things on Symbian is too low, and it's really difficult to raise it in your own code. This is 2005 and we are still having to manually calculate string lengths; recover from database rollbacks; deallocate resources; write RPC stubs and proxies (the packing of arguments to messages); divide components into DLLs remembering all of the IMPORT_C/EXPORT_C, binary compatibility, UIDs etc; code explicit state machines; remember both to add headers and LIBs; regenerate makefiles from MMPs; write our own build scripts to handle multiple platforms and binary-compatibility; guess from numeric (and undocumented) panics and error codes what we did wrong; read headers, headers, headers. And the justification we get from Symbian is that this is all in the name of making things work and stable on limited resource devices - but it _isn't_: the devices are unstable and bloated as hell - did you notice that although the 6630 has twice the processor and memory of the 6600 it doesn't actually _feel_ any faster? It won't cut it. 'Nobody writes for Symbian for fun' says Nokia and it's true. You won't get innovation, small cool apps, startups, and totally radically new things on Symbian. They will happen on something else, where it _is_ fun. I saw the two guys who implemented Seamful games (http://www.equator.ac.uk/index.php/articles/c93/) write two new location-based, mapped UI apps in less than a day on Windows Mobile (or whatever they are calling it today). These were connecting to multiple external devices, pulling data from a web service, playing dynamic audio and had good response times. I don't care if it was Java or .Net. I do care that it would have taken me two weeks to do the same on Symbian. Maybe it doesn't matter to Nokia and Symbian. What they (and the operators) want are consumer devices that they can control. The apps will be the designed-by-a-committee and written by 'professional' developers kind. Having a networked general purpose computer that people actually _want_ to carry around and use is the biggest thing since sliced bread. But _fuck_ it's a pain to program. And on top of this we get the whole platform security stuff which basically states that the only people worth something work for big companies. It's both really unproductive and insulting. It will kill off the little innovation there is in this space. Sorry to rant, it's been a bad week (with Symbian). Mika