On Wed, May 11, 2011 at 09:18:57AM +0200, Michael Schnell wrote: > > And if you want to capitalize on it, you need to be ready now, not only > > start. > > > > Lazarus is not suitable for trying to follow fast moving trends. Iphone > > was just yesterday, and even that is not really ready. > > > Yep. > > OTOH, I feel that Android is the more promising concept.
Maybe, but only if some dominant vendor emerges that standarizes a certain set of features across its line. This is now chaos. > In fact I don't like it's strong Java binding. I don't like that either, but usually such things will eventually be watered down by reality. (and I don't think it will be any different for the javascript bit) (CIL vs JVM) We have gone over the CIL rants before, so I'll not repeat it, except that I think it is a very coloured view, and I do not agree. > But other than then the iPhone OS+GUI, that seems quite different to the > PC Mac OS+GUI, Android to me seems to be about to win at multiple targets: > - mobile (smart Phone and "Pad": anyway) > - Laptop > - Desktop (via the Laptop path) > - embedded (I already found the first embedded PCBs that come with > Android <enhanced by API extensions for embedded hardware interfaces) > - Servers (it's not harm if the usual Linux server gets a - seldom > used - Android GUI just for compatibility) This demonstrates the problem what is "win". Widest range of devices? Most devices sold? Biggest turnover in the software market? I think for the average developer it is the latter, and then corrected by subtracting turnover of the very large companies. (e.g. we won't compete with mp3 sales, and other very popular apps, we won't ever get that business, so it is no sense). Note that is turnover for the devices I can reach in practice. Not the devices that run some form of android, but android in the right version on the right architecture with a device that has the required aux. hardware on board (think GPS,Tilt sensor etc), and sold separately or by a carrier that allows app install. And of course the cost of development. How many versions of the app for different devices/archs/versions must I make? How many different periphal hardware will I have to support (different GPSes etc). How much does it cost to get them in the marketplace and promote them etc etc. That is all more important than cil vs jvm, or even bytecode vs native. But my personal opinion is that neither cil NOR jvm is a valid target for Lazarus/FPC (regardless of the fact if you think bytecode is the way to go or not). I slightly turned last summer after some discussions on IRC and the lazarus day in the sense that if a JVM backend wouldn't complicate the compiler too much. (the JVM is standalone, and the rest of the compiler remains native), and has its own separate libraries, that would be a possibility. But still I think it would be better served with an independant project long term. -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
