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.

As someone who is using scala for 2 android apps one small and another smaller, Proguard does more than maybe help, it shrinks it to a small size. From the Scala for Android page:

AndroidForScala includes a treeshaker (proguard) that removes all the parts of the android-scala library that you don't use. For a simple "hello world" the scala library takes up about 10kb, and for a larger real world app (500kb), the library takes up more like 25kb.

Indeed. This is nowhere as bad as I had expected. Still don't like the language, but good to see that the "needs a carry-on bag to travel" argument is a non-issue.

Second of all, Scala isn't kinda OO kinda-sorta functional. Scala is actually more OO than Java, C#, C++, and any other statically typed language that I can think of off the top of my head. At the same time, Scala integrates functional concepts and techniques like higher order functions, immutability, and pattern matching into this object system in a very clean and effective way. In short, Scala has accomplished the most beautiful fusion of OO and functional that I have ever seen.

As someone who has used several functional and OO languages, I can witness that Scala is doing something very special and is not worthy of the criticisms you give it, whether or not you like Mirah more, and I am certainly a fan of Charles Nutter's work.

No, it doesn't. Please don't assume what I might think about something.

... and you must not consider them to have killer FP value either.

That part is true, to the extent that they are not ensuring referential transparency. Mind you "What makes an FP language?" is a great flame-war topic, but for me it has to be more than "Has first-order functions" or "Has pattern matching." I can get that in Ruby if I want but that doesn't make Ruby a functional programming language. It's functiony at best.

Also, pointing out features one does not like in a language is hardly hating on it, and I see far more Scala cheering than dissing on HN. I wish Scala users well. It's just not for me.

As someone who has used several functional and OO languages, I can witness that Scala is doing something very special and is not worthy of the criticisms you give it, whether or not you like Mirah more, and I am certainly a fan of Charles Nutter's work.

It's not a question of worthy or not. It's a matter of whether my comments accurate or not. If I'm wrong, I'm wrong (such as with my initial concerns over the size of the required bundling of runtime libs). But if I'm right then, well, people have to decide if it matters or not.

A few years ago I saw Bill Venners give a talk on Scala and while I appreciated that functiony features were finding their way into Java land the option to have code that was a OO here, FP there, really put me off. It seemed the language did not strongly encourage (or, better yet, out-right enforce) a set of conceptually simple, well-defined ground rules. That is, one would have to keep track of various coding options that were at odds with each other (OO being about carrying around and managing state, FP being close to the opposite).

If Scala and it's combination of features works for you, great. But that doesn't mean it doesn't legitimately fall short for others.

I can understand your criticism of well-defined ground rules. In Scala, it always feels like there are multiple good ways to accomplish a task. But I don't think that is necessarily a terrible thing.

Also, I disagree with your comment on OO and FP being at odds with each other. OO is at its hard encapsulated message passing. One of the things you can do with that is manage state, but that is NOT what OO is about. OO and FP can actually go very well together.

A great example of this is the Scala collections library. The OO features of Scala have allowed the language designers to create some powerful abstractions on functional data structures that makes the them a real pleasure to use. I haven't seen a collections library I like better than the one found in Scala.

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. ;)

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

     in statically typed functional languages, 
     type inference

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

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.

Scala doesn't have H-M type inference because H-M can't handle subtyping. You don't miss it, though. Declaring functions and generic types is hardly arduous, and indeed necessary to resolve that very same ambiguity that stops H-M working. In Haskell it is common practice to declare types for functions and other top-level definitions. Scala imposes about the same burden.

  Dealing with first-class functions in Scala is awkward 
  (getting and returning functions requires juggling with  
  generics, currying is half-baked)

  Haskell relies a lot on type-classes for its polymorphism,
  which aren't really possible in Scala

Unfortunately, I couldn't find a specific paper on this, but I've seen a talk by Bruno Oliveira on the relationship between implicits and type classes.

Isn't this ... Scala?

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

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!")
     }
   }

Compare this to the Python version:

    print "Hello world"

    main = putStrLn "Hello, World!"

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 uncompromising: 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.

I think it's also safe to assume that one of Scala's design goals was to make it accessible to Java developers, not beginning programmers.

Surely all that means is that Scala is Turing Complete, not that it is purely functional.

Also, you use the "more-or-less" qualifier whilst disagreeing with the "kinda" qualifier, even though they are "pretty much" synonymous.

That being said, for my first application I decided to do it in plain old Java - since I had never worked with Java, I imagined that a rudimentary understanding of its workings would help me down the road in debugging issues that might arise when working with Mirah (somewhat like knowing JavaScript before working with CoffeeScript).

There's even a tool for writing Mirah for Android called Pindah https://github.com/mirah/pindah/ .

All in all, it's quite a nice package.

I have started to see Scala coming into Android market apps, and haven't felt they were worse for resource utilization. Bump is the most widely deployed example that comes to mind.

Well, forcing objects to immutable on Dalvik VM will be a performance crime. Scala has no practical sense on Android since Dalvik is not made for it.

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.

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.

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

They must be good at SEO.

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

(at the end during Q&A)

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.

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

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.

It works OK in the "You can run a repl on your phone if you don't mind waiting a few seconds" sense. That's a far cry from "You can build a usable application with it."

http://www.deepbluelambda.org/programming/clojure/

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

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.

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.

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.

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.