> "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
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
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
- 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
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