Poll: A year from now, which language will you be writing mobile apps in?
I'm writing an article on mobile web development and testing trends, and I'm interested to know.
17 comments
Python on Android would be my preferred option. But I've yet to look at Scala and Ruby, so if they become available on Android, I'd definitely try that. I have 3 android devices, but haven't gotten around to programming them because I hate Java.
ASE(http://google-opensource.blogspot.com/2009/06/introducing-an...) Lets Ruby and Python run among others. It may not be ideal for distribution to end-users yet, but it seems pretty good.
You can use Scala with a moderate amount of hassle today: http://www.assembla.com/wiki/show/scala-ide/Developing_for_A....
What about C# or F# for Windows Phone apps? I'd either use one of those (I do most of my development on .NET these days) or an HTML5/JavaScript site.
While native applications wont go away any time soon, I fully believe that we will see the exact same position as we do currently do with flash vs the web.
People will use native apps particularly when web apps just cant provide the functionality needed, but web apps will grow into the large majority, slowly improving and eating out the market from the bottom.
its taken the web a very long time to take out flash's market share so it could take a very long time on mobile as well, however the web is progressing rapidly these days so it may not be the long drawn out process we have seen with flash.
People will use native apps particularly when web apps just cant provide the functionality needed, but web apps will grow into the large majority, slowly improving and eating out the market from the bottom.
its taken the web a very long time to take out flash's market share so it could take a very long time on mobile as well, however the web is progressing rapidly these days so it may not be the long drawn out process we have seen with flash.
I disagree. Native apps will not have to, unless they specifically introduce it, the overheads of a browser rendering engine and all that entails. Even after you make the rendering engine as efficient as possible both in software and in hardware engineering, the overheads will always be there no matter how good you get things. You really can only do so much on 3.7v.
Personally, I'm looking into doing Qt development next year.
Personally, I'm looking into doing Qt development next year.
At the risk of making this a "me too" comment, I want to expand on iloveponies answer.
Mobile is special, in that the answer to the question of "would less processor/memory/storage overhead be better?" is probably going to be "yes" for the foreseeable future. It certainly will for the next year.
This gives you a very different tradeoff between developer productivity and code efficiency than you would have on a desktop machine, much less in a server farm.
At some point batteries will be so good, and processors so efficient, and memory so cheap that the overhead of not running natively will go from "it doesn't matter except for some games and stuff" to "it doesn't matter". And compilers and development environments will be able to amp up developer productivity without sacrificing power efficiency. So daleharvey might get the last laugh. Just not next year.
Mobile is special, in that the answer to the question of "would less processor/memory/storage overhead be better?" is probably going to be "yes" for the foreseeable future. It certainly will for the next year.
This gives you a very different tradeoff between developer productivity and code efficiency than you would have on a desktop machine, much less in a server farm.
At some point batteries will be so good, and processors so efficient, and memory so cheap that the overhead of not running natively will go from "it doesn't matter except for some games and stuff" to "it doesn't matter". And compilers and development environments will be able to amp up developer productivity without sacrificing power efficiency. So daleharvey might get the last laugh. Just not next year.
I think any time you are saying X maybe ore convenient but it wont be as computationally efficient it becomes a matter of "when" not a matter of "if"
That being said I already spend the majority of my time using mobile optimised web sites / web apps and they havent had a noticeable effect on my battery vs native apps, so while I am making it a "prediction", its really already happened, I just think the trend will continue.
That being said I already spend the majority of my time using mobile optimised web sites / web apps and they havent had a noticeable effect on my battery vs native apps, so while I am making it a "prediction", its really already happened, I just think the trend will continue.
It's tough to say one exactly, so I went for Javascript native and mobile, as well as other.
I only target iOS as mobile devices, so my focus maybe be slightly different from others (android is catching on a lot around here with my friends, and nobody is picking up blackberry).
For graphical big projects, I tend to write in Scheme and compile down to iphone. It's nice to have the flexibility and comfortable toolset.
I do a lot of small quick-and-dirty projects as mobile javascript apps, and they tend to grow over time, but never too big... until recently, I've been thinking about wrapping these in some sort of native-layer so that I can possibly distribute them via the app-store (honestly, most of the native stuff I used to slug through objective-c to get is available with the new iOS Safari stuff).
I only target iOS as mobile devices, so my focus maybe be slightly different from others (android is catching on a lot around here with my friends, and nobody is picking up blackberry).
For graphical big projects, I tend to write in Scheme and compile down to iphone. It's nice to have the flexibility and comfortable toolset.
I do a lot of small quick-and-dirty projects as mobile javascript apps, and they tend to grow over time, but never too big... until recently, I've been thinking about wrapping these in some sort of native-layer so that I can possibly distribute them via the app-store (honestly, most of the native stuff I used to slug through objective-c to get is available with the new iOS Safari stuff).
I wouldn't be surprised if windows 7 phone apps were a big part of the eco system in a year, so I guess C# will be common for app development.
By and large, I'll need to make existing web apps mobile friendly (ie., easy to use on a small mobile browser), rather than write apps for a particular mobile device per se. So core programming languages will probably still be Java and Ruby. I expect that HTML5, CSS, Javascript, other UI type languages will factor in as well.
Ideally, Scala or Python targeting Android. Probably some JavaScript in one or both categories as well.
I wish it was mobile optimized web site but all the good stuff, camera control, address book, motion sensors etc. is not exposed to web apps and won't be any time soon. You will be writing an objective-c app for iphone, and java apps for android and bb.
I'd love to give Silverlight a try. I've got a Silverlight web mapping app that handles 20x the complexity that I've ever seen with AJAX or Flash and I think I could get it up to 100x.
I'm going to use sproutcore
Python for Android and Ruby for iOS are pretty realistic options.
Hopefully Clojure, which I suppose is another way of saying Java.
HMTL5
Thanks. I updated one of the JS entries to: "JavaScript (HTML5/Mobile-optimized web-site)". Do you think "HTML5" should be a completely separate option?
Likely Objective-C. Small chance that it might be MacRuby.
[deleted]
Gee, we've only been writing C# mobile apps for five years. Except now I can write iOS and Android apps in it too.