Scala: The Android programming language you didn't know you had
computerworld.com
computerworld.com
When I look at the code that Scala produces, it's spinning off little instances of auto-generated classes all over the place to work the magic that it works. You can't breathe in Scala without it generating a few anonymous classes and instantiating them. All that is fine for an app where the device is idle between UI events (a "normal" app), but how does it fly in a game? I can see and "feel" a noticeable glitch when my machine GC's, and I need to avoid that pretty much at all costs. How in the world do you avoid that with Scala in an action game? So far I've been assuming that you pretty much don't avoid it, so I haven't bothered trying to use Scala for my games on Android.
I would prefer getting into Clojure over Scala.
Is this a cute way of saying you will end up with fewer lines of code to do the same thing, or that you just don't need to use semicolons?
I think if you're trying to convince someone to use a new language, you should be a little more clear.
Speed and start up time does not appear to be a problem, even if you are using a good part of the library. The problem with scala is it takes so darn long to build your simple app. Size of generated output is not a big deal, though it will be larger than Java for simpler stuff. But unless your app is trivial the media elements will make a much larger contribution to your final size than the code. Also the growth is non linear. Here is what I mean.
If you hello world and proguard your app will be the same size as a java app. But once you bring in some scala stuff - collections or language features which need the library it grows by an order of magnitude. So a 20k Java app vs 100k Scala for the same app. After that initial bump the additional baggage is gradual so that eventually the java app of similar complexity will generate similar sized output. Speed is not meaningfully impacted in my experience. If you are making a game it would be worth considering preallocating arrays and doing basic memory management to avoid stalls.
You will have to avoid some idiomatic scala because functional programming is too easy going in terms of allocation. So manually iterating java hashtables and arrays instead folding over maps and lists. I will note that for my simple app I fold over lists with little impact for now. Scala has the basic advantage of being a java with less boilerplate. The little things add up. But if you are not using it as a functional language is it worth it? I think so. Instead of using it as just a functional language you can use it as something else. more? By leveraging caseclasses, Extractors and pattern matching you gain in expressivity while retaining declarative elegance. your mileage may vary.
So the problems are: You can't easily debug. But Mostly, building takes Forever. It takes 4-5 minutes to build the simple hello world activity. I humbly suggest the scala team look at their android support.
Getting F# on WP7 was a piece of cake in comparison. Building is normal, debugging is there and getting it to work was a matter of referencing a targeted dll.
According to the SpringSource P.M. for Groovy: "Groovy is not able to run properly on Google's Android mobile platform. A project started porting Groovy to Android, but performance wasn't there (20 secs to startup a simple Hello World)" (http://docs.codehaus.org/display/GSOC/Groovy+Ideas)
Perhaps Scala is the ONLY alternative to Java.
Sometimes is better to add some semicolons instead of slowing down the whole device.
Scala is great, but in this case the choice must be made carefully.
I would think the best Scala could hope for would be to match Java's performance. I can't imagine how it would be faster.
Are there actual numbers for Android development? What do you lose doing Scala and where?
http://scala-programming-language.1934581.n4.nabble.com/Scal...
The following one instead is an official Google doc with some benchmarks between Java/Scala/C++/Go (not specifically related to Android), where it's stated that actually Java would be more performant than Scala without the GC:
https://days2011.scala-lang.org/sites/days2011/files/ws3-1-H...
"In other words, Scala spends 7699-2416-1 = 5282 clicks on non-GC code. Java spends 14073-10484-110-2 = 3477 clicks on non-GC code. Since GC has other negative performance side-effects, one could estimate that without the GC anomaly, Java would be about roughly 30% faster than Scala."
Very interesting. Also, Scala JARs are 3.6x bigger than the Java equivalent (due to the runtime files, see page 7).