Symbian rant no 4

zg wrote:

> "Vesa Suontama" wrote:
>
>> For a cross platform developer, the mobile world just does not seem so 
>> happy for the Symbian camp. The rest of the world is trying to make 
>> coding more easy and fun, while the Symbian camp is making life harder
>>  for developers.
>
> did you study physics in school? did you hear about "conservation of 
> energy"? "easy and fun" must be payed. the rest of the world pay for it 
> by productivity. this is not a big problem when you can use 3GHz cpu
> when real requirement is 100 MHz. but mobile phones now has some 
> limitations, so resources - restricted. and you have to ways:
> 1. high perfomance and accurate programming.
> 2. low perfomance and easy and fun programming.
> i choose 1st way.

That's the most crucial error here. It _is_ possible to make programming
both efficient and fun. _Easy_ is a bit different: programs are
complicated things and you have to have some understanding of both
the problem and implementation domains. But efficiency is important,
and achievable. Go read a bit of Paul Graham, or the new Beyond Java
book.

And we are kidding ourselves if we think that these phones are too
under-powered to run modern programming languages and libraries.
They have the power of mid-90's PCs, or late 80's workstations.
Lisp and ML were developed in late-70's - early 80's. COM was
created for machines with les resources, same with Corba (well,
with Corba, it didn't actually run).

I'm not saying the answer is Lisp (or even Ruby), I'm just pointing
out that major efficiency advantages can be gained by raising the
level of abstraction, and focusing on the actual problem instead
of housekeeping.

One of the things in which C++ really loses against Java is the
extra effort needed to create physically re-usable components,
and Symbian is not making it easier. In Java, to use a class, it's
enough to have it in your classpath, whether in a .jar or as a .class.
With C++ and Symbian, you have to possibly create a new DLL to put it
in, change the MMP (including adding LIBs it needss)
add the IMPORT_C/EXPORT_C, recreate the .DEF files, re-build and
recreate your IDE project file. And to have separate compilation
you need to write all your declarations twice: once in the header
and once in the body of your class. All this really adds up in
the daily development -> which means that if you are in a hurry,
or impatient, or lazy you won't do it -> less reuse, more code
to maintain, more coupling.

There are certain aspects of development that have a large impact
on the quality of the end-result: testing, decoupling, performance
measurements, ability to change run-time architecture without
changing (a lot of) the code, re-factoring, physical re-use. If
these are hard, they will be done badly, and the result will be
bad. If these are effortless, the resulting quality is much higher,
and you will have much more fun developing it as the main part
of your effort will go to actually creating things instead of
house-keeping. These are the things a _platform_ should make easy.

Look at lifting out a class from a DLL and making it a server
on Symbian (which is the only way to change the run-time structure).
You need to:
    - create two new projects, with all of the things above
    - write boilerplate startup, shutdown and session management
    code
    - write your own serialization, proxy and stub code
    - change your client code from direct-flow function
    call style to an asynhronous state machine (including
    the same for all the clients of _that_ client code)
When (at least in some cases) there are no _conceptual_ changes
that really are needed. Compare this to, say COM(+), where you
just say whether your component runs in- or out-of-process.

Especially if these things use some shared, persistent data, since
the devices don't ship with the client-server version of the
database, which means everybody gets to write their own instead
(Including the device manufacturers. Log engine, Comms database,
contact database etc. are all just thin wrappers over the database
API.)

Do you still hand-code your client-server things at Symbian? Or
do you have some proxy/stub generators you are just not sharing
with the rest of us?
>
>
>> .bat -based compilation environment is one glaring example: restricting, 
>> inefficient, kludgy, invented here (at symbian camp) and not so portable.
>
> if you cant' effective use some tool this not mean that tool is bad.

Actually, that's exactly what it means.

You could also say that I should write my own tools. But that's stupid:
if the platform provider writes the tools, everybody benefits, and the
cost can be amortized over a much larger population.

And it's not like things work out just fine at Nokia either. From what
I've heard each new device is a deathmarch, and the resulting quality
is crap.

    Mika
This entry was posted in Symbian. Bookmark the permalink.

4 Responses to Symbian rant no 4

  1. Alessandro Furlanetto says:

    Grat… I think you’re right. I think that one of the most interesting things in a new device (for a programmer point of view), is the time elapsde between the purchase (for example 3 weeks ago for my N80) and the built of the first “program” for it. For me the test is the classical “Hello World” program. If this fail… there is something bad with this device.
    I’ve downloaded all the nokia software, a lot of SDK (and the one for my device) but… no luck understanding this f…ing phone!!!
    I’m not worried about C++ but it’s not so easy to run/maintain like an p-code dialect. But all those macro constructors?!?!?
    Really, if symbian want to get up with programs on their os… they should give people something else… more “easy” to learn… so one can start enjoing that system… and start learning how to use it deeper…
    C/C++ it’s the BAD way to start something for fun. It requires skill and knowledge.
    Great, now I’ve to learn how to write programs for ANOTHER OS :(

  2. Mikko says:

    >> if you cant’ effective use some tool this not mean that tool is bad.

    > Actually, that’s exactly what it means.

    Not necessarily.

    All tools strive to accomplish a set of tasks. If the set of tasks is large and complicated, then the tool will require lots of parameters and has a steep learning curve; but on the other hand, a simpler tool with less parameters and switches can only accomplish that much.

    Yes, it’s true that alternative development platforms, such as MIDP, are much easier to use than Symbian. There are two catches: first is the efficiency issue (which you addressed above), and the other one is the “expressiveness” issue (which you didn’t address above). Symbian just can accomplish a hell lot of more than MIDP, and the API will thus be necessarily more complicated.

    One workaround on the steep learning curve is to build some simple mid-level APIs such as SendAs, which allow doing simple, common things (required by 99% of developers) more easily than in the general case (required by 1% of developers).

    Of course, none of this forgives the general bugginess of Symbian. Just wanted to point out that ease of use correlates with lack of expressive power.

  3. Mika says:

    Sorry, but I think you slightly sidestepped my point. My major claim was that the non-standard-library-supporting, export-specifiation-requiring, manual-proxy-and-stub-writing C++ development environment with very low-level supporting classes makes it hard to build your own abstractions, which would then make development more efficient. I allude above to the large amount house-keeping work required when making new components.

    I’m not quite sure what it is that makes C++ so ill-suited for reusable components, by I think that the past 20 years of experience show that it _is_. See also my post on the reusability of Perl. One of the few successfull libraries is Boost, which uses the kind of template-techniques that take a long time to master (and Boost isn’t supported on Symbian).

  4. Vesa Suontama says:

    I agree that C++ for is not suited for reusable components, especially given the restrictions with Symbian. The API’s on Symbian are so different from other operating systems, that your cross platform code will look terrible. Symbian C++ uses Action/Listener style, Windows mobile blocking calls and encourages the use of threads and Unix async IO with sockets.

    Combine that with non standard data types (TDesc, _LIT, wtf?), and non standard exception mechanism bad documentation and the very non standard build system.

    Nobody can say that the environment supports code refactoring, which leads (as you correctly tell above) to bad code over time.

    What I think makes things worse with Symbian is the ActiveScheduler, and recursive event loops, and concurrency control mode (which is not documented anywhere AFAIK) which makes your single threaded code to be actually re-entrant:

    // assume single threaded code


    // state of the MyActionListener
    int a;
    int b;

    void MyActionListener::WhateverSymbianCallback(TPtrC *foo)
    {

    int c;
    // this is the only place a is ever changed.
    a++;
    c = a;

    // some code that runs ActiveShceduler, now a dialog
    CAknQueryDialog* dlg;
    dlg = CAknQueryDialog::NewL(CAknQueryDialog::ENoTone);
    dlg->ExecuteLD( R_QUERY_YES_NO, message.desc() ) != 0;

    // you CAN NOT assume c == a, because your code is re-entrant
    }

    I propose that we prepend letter A to the methods, which may run ActiveScheduler, so that this re-entrancy can be seen: AMethodLC :)

    To make this post more constructive, I propose the following changes to Symbian SDKs. (Nokia is trying to ask this kind of feedback through its surveys, but the surveys are being sent to seasoned Symbian dev-houses, and it is their advantage, that these changes are not made, so that they stay ahead competition)

    – Throw away MMPs. Use make (which you use internally anyway)
    – Provide easy synchronous convenience API’s written in C
    – Reduce the amount of boilerplate code, e.g. why compulsory MVC?
    – Open the same API’s to Java that are open on Symbian and loose the restrictions there, e.g. why no MMC access? Add signing requirement for midp, if that is restricting you from doing it so now.
    – Enable open source, by not requiring signing, if the device owner says so, e.g. by giving up the capability model only when certain user specified applications are running. I would like to use putty on my E90.
    – Add real support for Symbian
    – Document, document, document the APIs, and the hard issues, like return values, Object deletion, concurrency model, calling conventions, “special cases” like incoming calls, memory shortage situations, etc.