
Scala: The Android programming language you didn't know you had - bleakgadfly
http://www.computerworld.com/s/article/9219546/Scala_The_Android_programming_language_you_didn_t_know_you_had?source=rss_applications
======
unoti
I do game programming for Android, and use Scala for my server infrastructure.
I'd like to use Scala for the Android device as well, but haven't even tried
because I'm concerned about garbage collection. You see, I can't even use Java
iterators in areas that are called on every frame on the Android device,
because those create little object instances that will trigger garbage
collection. So I have to write for loops. There are all kinds of things I need
to do in an action game in Java on Android to carefully pre-allocate my memory
and not trigger garbage collection.

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.

------
Tichy
Any news on Clojure for Android? Last I checked (~1.5 years ago) it was too
slow because reflection works differently on Dalvik than on a normal JVM, or
something like that.

I would prefer getting into Clojure over Scala.

~~~
hencq
I'm interested in that as well. In addition to the reflection issue, I believe
another issue was that every program brought in the whole core library. So
even a simple Hello World app would get to a few megs. It also made start-up
of the apps relatively slow. This was quite a while ago though and I do seem
to recall that Android support was on the radar, so maybe these issues have
been fixed now?

~~~
rst
Scala also has the library bloat problem. The most common workaround for now
is to run all apps through ProGuard --- not for the obfuscation, but just to
get rid of unreferenced library classes. Which actually works well, but it
does add a tedious minute or two to builds.

~~~
astine
ProGuard doesn't really solve the problem for Clojure though, as most of the
Core library is necessary for core features of the language to function.
Dropping 'eval' support for Android targeting Clojure apps might work, but it
hasn't been done near as I can tell.

------
wccrawford
"To start with, you don't need as many semicolons."

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.

~~~
tomjen3
Scala infers a lot of things including semicolons, when possible (typically
almost always, except when two or more statements are put on the same line).

------
Dn_Ab
I would like to share my experience with Scala and Android. Maybe someone can
tell me what I am doing wrong.

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.

------
vorg
> Statically typed Java language pushed as alternative to JRuby and Groovy for
> building mobile Android apps

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.

------
fosk
Drawback: the environment must load the Scala runtime.

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.

~~~
Dove
Yeah, I'm curious about that. When article said, "He lists benefits of Scala
development for Android as _speed_ , easier programming, . . . ." (emphasis
mine), that turned my head a bit.

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?

~~~
fosk
Found this, but not sure if it can be considered reliable:

[http://scala-programming-
language.1934581.n4.nabble.com/Scal...](http://scala-programming-
language.1934581.n4.nabble.com/Scala-on-Android-Performance-td2004054.html)

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...](https://days2011.scala-
lang.org/sites/days2011/files/ws3-1-Hundt.pdf)

 _"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).

