
C'mon, stop writing Java for Android - ubuwaits
http://robots.thoughtbot.com/post/5836463058/scala-a-better-java-for-android
======
jamesbritt
_So what’s stopping you from using Scala for your Android app?_

Mirah.

While Mirah is still beta-ish I prefer it to Scala. Maybe it's because I'm
already familiar with Ruby, but the "multi paradigm" (i.e. no paradigm) nature
of Scala leaves me cold. It's kinda-sorta OO, kinda-sorta functional. But the
functional part gives no guarantees of referential transparency or immutable
state, so the killer value of FP is lost.

But, language rant aside, even if Scala were the cat's meow, you still have to
include the Scala base libraries with every app. Proguard may help, but it
seems wasteful.

Mirah, OTOH, compiles down to straight-up JVM byte code. No supporting runtime
libs are needed. Very slick.

~~~
crux_
> But the functional part gives no guarantees of referential transparency or
> immutable state, so the killer value of FP is lost.

I don't think I agree here. First, the language's type system can give you
those guarantees where you need them. (Even Haskell has unsafePerformIO...)

Second, a lot of the "killer value" comes from first-class functions (and in
statically typed functional languages, type inference). Coming from Ruby you
may not see the huge benefits these would give over Java... ;)

Finally I disagree with the "kinda-sorta" label: The entire Haskell standard
library could be rewritten, more or less, in Scala. How is that "kinda"
functional? Likewise, obviously any Java code has a direct scala analogue...
and with the Dynamic trait, you may even be able to write direct translations
of ruby/smalltalk/python-style code too, after a bit of plumbing.

Most (any?) "kinda-sorta" lies with the programmer, not Scala. ;)

~~~
bad_user

         a lot of the "killer value" comes 
         from first-class functions
    

Dealing with first-class functions in Scala is awkward (getting and returning
functions requires juggling with generics, currying is half-baked), and if you
are ready to make that compromise it can be argued that Java doesn't need
first-class functions as long as it has anonymous inner classes.

    
    
         in statically typed functional languages, 
         type inference
    

Scala doesn't have the Hindley-Milner type inference that ML/Haskell have. It
only does local type-inference, saving you from some boilerplate, but other
than that it doesn't and cannot have type-inference where it is truly needed -
in the declaration of functions / generic types.

    
    
        The entire Haskell standard library could be 
        rewritten, more or less, in Scala
    

Haskell relies a lot on type-classes for its polymorphism, which aren't really
possible in Scala, and if you are going to work around that, well, the entire
Haskell library could be rewritten in Java too with those workarounds, only
with more boiler-plate.

The question is, does Scala provide enough value to bother with its
deficiencies (the type system is more complex and awkward, the generated code
more inefficient especially for Android, which doesn't have the luxury of the
Java SE GC).

Well, it does, but for Android at least, a version of Java that had local type
inference and a lighter syntax for instantiating anonymous classes -- would
have been so much better. And personally I'm not ready to commit to C++
version 2.

~~~
crux_
> a version of Java that had local type inference and a lighter syntax for
> instantiating anonymous classes

Isn't this ... Scala?

Sure, it has a lot more too, but there's zero obligation to use every single
feature.

~~~
bad_user
No.

That was my tongue-in-cheek remark about C++. Using a subset of C++ is exactly
the same argument people have been making for years. The problem with that
line of thought is that you're never working only with your own code (that,
and the fact that Scala is not optimized for your subset).

That's the bad thing with a language born out of lots of compromises -- while
initially a pragmatic choice, if it's popular it only grows uglier and uglier
until it becomes the bottleneck of the industry.

If you don't believe me that Scala is ugly, try explaining a "Hello World" to
a beginner that was never exposed to programming, taking the sample out of the
official documentation, preferably without resorting to a cargo-cult style
explanation of "just do this".

Here, I'll get you started:

    
    
       object HelloWorld {
         def main(args: Array[String]) {
           println("Hello, world!")
         }
       }
    

You have to explain -- (1) what are functions + (2) what are those singleton
objects, with OOP sprinkled in between + (3) why functions have to be declared
inside classes or singleton objects + (4) what are generic types + (5) the
"main" entry point.

Compare this to the Python version:

    
    
        print "Hello world"
    

Or the Haskell version:

    
    
        main = putStrLn "Hello, World!"
    

Both of which only require an explanation of functions + the main entry point
in the Haskell case. Yeah, the Scala version does more - that's the problem
with ugly, it cannot scale from simple to complex easily.

~~~
crux_
I think we're talking past each other. First, I'm talking about capabilities,
not aesthetics. Also not on the list of things I'm discussing: teach-ability.

Second, you asked for Java+1 ... then you post a code snippet that's pretty
much exactly that, and tear it to ribbons. Let's be consistent.

On scaling from simple to complex:

There's a wide variety of techniques used to create abstractions, which
(speaking generally) is how to tackle complexity. (Modules, OO, message
passing, functional abstractions...)

On this front, Scala is remarkably __un __compromising: The language designers
have chosen to provide as many of those techniques as possible (and even add a
new one or two of their own along the way).

Maybe that's overkill for scaling from simple to complex -- but I can tell you
it's incredible for scaling from complex to really complex.

------
wccrawford
I'm underwhelmed. At that level, I find the Java version more readable. (I
know, I know, the horror.)

But to answer the question posed: Community. I started messing with Mirah, but
there's just not much community yet. Any questions you have is a new one. And
nobody knows the answer yet. That's fine if you like figuring things out and
have time... But drop either of those and it's just a headache.

~~~
jamesbritt
_I started messing with Mirah, but there's just not much community yet._

True, but as that community includes Charlie Nutter it has a serious leg up.
:)

Still, I expect things to move fairly quickly, so the number first-time-asked
questions will diminish and getting solid work done will increase.

------
codesink
I think google is working to move Android to Go as soon as possible; Rob Pike
replied to a related question with "I cannot talk about it" and that sounds
like a good clue :)

Go binaries already run on Android/ARM, the higher level code is the one
that's missing.

That would bring great boost in performance (compilers are available for both
x86 and ARM) without adding any complexity on the language side (Go is a cool
language).

~~~
jraines
Just went to Google to see if I could find anything relating to this
possibility, and was immediately reminded how annoying it is, with respect to
search, that they named the language "Go".

~~~
codesink
They managed to optimize their golang.org homepage to get the position #5 on
the word "go".

They must be good at SEO.

BTW the video I mentioned is at
[http://www.youtube.com/watch?v=-i0hat7pdpk&feature=playe...](http://www.youtube.com/watch?v=-i0hat7pdpk&feature=player_embedded)

(at the end during Q&A)

~~~
fs111
Well, they own the crawler and the index, they will know, what to do...

~~~
reinhardt
It's not that funny any more if you have to explain it ;)

------
ggeorgovassilis
So what’s stopping you from using Scala for your Android app?

The same that is stopping me from using it for J2EE production code: the
insufficient IDE integration. It's quite ok for unit tests though.

------
mikemaccana
Re: mentioning Python via the ASE in the intro, it's a non-starter: the ASE
can't make GUI or OpenGL apps . Other than that: yes, Scala is awesome (asides
from all those curly brackets).

------
muyyatin
Is there a noticeable size increase from including parts of the Scala library?
I know Proguard will probably strip out a lot of unused classes.

~~~
joshhart
You absolutely need proguard since the Scala library is several megs in size,
and will likely grow bigger when specialization goes everywhere.

------
mickeyben
I tried both Mirah and Scala and I'm sticking with Java for the IDE
integration.

~~~
squidsoup
The IDEA Scala plugin is pretty solid now; worth revisiting if you haven't
tried it in a while.

~~~
joshhart
It's worth noting that www.typesafe.com is now supporting the Eclipse plugin
commercially as well. Both the IntelliJ and Eclipse plugins have made huge
advances in the last year.

------
nupark2
We use Java because we don't want to foist a 'weird' language on our clients.

If it wasn't for that, we'd leap at the opportunity to use Scala.

~~~
dustingetz
I also would love to hear from someone who has put effort into and succeeded,
or failed, at selling their enterprise clients on Scala.

------
andrewvc
Has anyone written any Clojure for Android so far as anyone knows?

~~~
GeorgeTirebiter
I've heard that folks have done it (more than a year ago) but, apparently, the
runtime takes a while to load and that makes the app practically unusable.

~~~
vmind
I think the issue with Clojure is that it does runtime bytecode rewriting for
macros, so to get the whole language working on android they had to bundle the
dalvik translator as well.

~~~
technomancy
> I think the issue with Clojure is that it does runtime bytecode rewriting
> for macros

This is actually very rare; nearly all bytecode generation in Clojure apps can
happen ahead-of-time. But Clojure relies heavily on Hotspot's world-class JIT
(the bytecode Clojure's compiler outputs is only optimized in so far as making
it easy for Hotspot to optimize it.)

In addition, use of persistent data structures puts more strain on the GC;
another place where Hotspot is leaps and bounds ahead of Dalvik. You can
bypass this by using Java arrays directly, but it's very awkward and un-
idiomatic.

~~~
ygooshed
i love to use scala on android. has anyone developed any 'real' app with scala
on android?

------
thepumpkin1979
It's true that you can use the NDK to write "Parts" of the app but, don't get
me wrong, I don't think it's intended as a replacement for Java or the Java
libraries (unless you are writing a game that requires high performance
requirements).

I think Java is a decent programming language and Android comes with tools
nicely integrated in Eclipse IDE.

I quote: "The Android NDK is a toolset that lets you embed components that
make use of native code in your Android applications.

Android applications run in the Dalvik virtual machine. The NDK allows you to
implement parts of your applications using native-code languages such as C and
C++. This can provide benefits to certain classes of applications, in the form
of reuse of existing code and in some cases increased speed."

See <http://developer.android.com/sdk/ndk/overview.html>

------
ikhare
At Bump we use Scala for our the service layer of the application that manages
connectivity to our servers and deals with our "business logic". It's a great
language when you are within it's rules, and a great way to do succinct state
management.

But writing Scala in Android is chock full of gotchas as well. Just today I
was dealing with the scala compiler not finding a public inner class in the
Android framework, forcing me to rewrite that class in Java. I am fairly new
to Scala myself but stuff like this does come up, and can eat up more time
than expected.

We've promised a blog post with more details on the pains and triumphs of
using Scala in Android. Also if you're going to be at the Scala Days
conference next week at Stanford, we're going to be giving a talk about this
subject.

------
sehugg
If Scala can give me a way to abstract all the wacky Activity/Intent/Service
stuff, get around incompatibilities between Android 1.5/1.6/2.1/2.2/2.3/3.0,
work around bugs in various hardware platforms, provide me a _usable_ GUI
layout tool, and maybe even make my simulator start a wee bit faster .. I'm
yours pal. Otherwise I'll be sad because I'll just be _pretending_ that I'm
programming in the future.

------
markokocic
This comes too late. Mirah already took the torch for javaless android
development.

It's much simpler language then Scala, and compile directly to bytecode
without requiring any runtime.

The only thing where Scala is better (for Android development) is better
tooling, but I hope that will be fixed soon.

------
cmars
I'll switch to scala or any other language if it will abstract away SQL
cursors with minimal overhead.

------
leon_
> you don’t need as many semicolons

What is up with the hate on semicolons?

Luckily I know scala but if I didn't and someone would try to sell it starting
with that argument I'd get very suspicious.

~~~
bonzoesc
They're more typing than no-semicolons and all you stand to gain is code
that's harder to read for a majority of programmers. It's really as close as
you get to an objectively-bad thing in a programming language.

~~~
leon_
> objectively-bad

I guess you're confusing objective and subjective here. I think semicolons are
nice - they make reading code easier. And the "extra" typing isn't really that
much work.

But that's my opinion and so it's subjective. I don't claim to be it the
ultimate truth, like you do.

------
hunterp
Don't take my System.out's away from me wierdo.

