9 ms·

Google, it's time – We want Scala for Android

90 points by phatak-dev 12y ago

pinkyand 12y ago
I agree that Google should add more languages to android. And while Scala is a great language, it's very complex - so it won't benefit many of the less skilled users. A better language would be something with the simplicity and power of python, but with good performance.Groovy could be one such language.
- blablabla123 12y ago
  It would be a mass experiment on Functional Programming acceptance ;)
  - MichaelGG 12y ago
    Considering that Visual Basic has monads, and lots of C# developers are regularly using closures, I think the response to "is FP accepted" is a resounding yes. Although .NET had to sort of smuggle those features in, under cover.
- phatak-dev 12y ago
  Scala is not complex in terms of the language design. Most of features [or complexity] come from the libraries.
  - taeric 12y ago
    That doesn't do much to make it a great choice, though. In particular, Scala can be a fair bit trickier in terms of knowing your memory profile. Though, I doubt it is much worse than Java these days.
  - nvarsj 12y ago
    Implicits? Compared to Java, Scala is not a simple language. I'd say Scala's complexity is on the order of Haskell + Java syntax with additional glue on top of that. Not to say this is bad, it just means you need greater discipline when writing software in Scala. A bit like C++ (yes, I went there! :-)).
    - zak_mc_kracken 12y ago
      I'd say this makes Scala slightly more complex than C++ and Ada. Java and Haskell are not in the same league when it comes to complexity (Java because it's simple, Haskell, because it's wickedly well designed so its complexity is completely tractable).
    - frowaway001 12y ago
      The great thing is that as soon as people mention C++, it's immediately clear that this person has not a single clue what he/she is talking about.
  - zak_mc_kracken 12y ago
    Not true, the mix of functional and OO features make the language complex even without the libraries. Throw in implicits, higher kinds, pattern matching, a fairly good generic type system, support for all kinds of polymorphisms (subtyping, ad hoc, duck typing), etc... and you can see complexity emerge pretty quickly.
- broodbucket 12y ago
  Just because Scala has features that are tricky to get your head around if you're not familiar with functional programming, it doesn't mean it's complex to write software in. You can write Scala that's basically Java with less syntax if you want. I think that's what's so great about Scala, Python and other languages that mix OO and functional elements; you don't have to throw away Java and pick up Haskell, you can start experimenting with other styles as you go.
  - TeeWEE 12y ago
    It still doesnt change the fact that Scala, as a programming language, tries to incorporate too many concepts while still trying to be typesafe. This makes the language complex, and not an ideal candidate.
    - benburton 12y ago
      There's no substantiative argument in this comment. > Scala, as a programming language, tries to incorporate too many concepts Too many concepts? Says who? How many concepts is too many? You don't have to use them all, and you can pick them up fairly easily as you go along; that's exactly how I learned the language. > while still trying to be typesafe. Not sure why that's contentious. > This makes the language complex, and not an ideal candidate. Says who? Why? Should all complex things be abandoned? I find the Android framework itself complex, personally, so should we throw that out? This is the same Scala FUD that's always prevalent on Hacker News. "The language does too much." So what? You don't need to know all the concepts to be proficient. The language's beauty is that you can write simple code and pick up the concepts as you go along. Library modularity generally means that you don't need to get into the deep end of the language unless you want to. Scala is an expressive language. That's an intentional design decision that makes it flexible. It is not a drawback. It does not make it overcomplicated for a beginner.
      - apendleton 12y ago
        > Says who? Says at least me and the OP, and probably others... I haven't put a ton of time into learning Scala and only occasionally interact with it, but in that capacity I'd definitely say I find it a bit intimidating and someone hard to read. Certainly there are many ways to write Scala, and a Java-like style is doable, but idiomatic Scala, as far as I've seen, encourages terseness and the use of opaque punctuation-laden operators that aren't immediately interpretable by people not familiar with the language. Whether legibility from non-experts is important is absolutely a matter of opinion and personal taste (it's a clear source of disagreement between the Python and Ruby communities as well), but if you're someone who thinks it's an important property for languages that get widespread adoption to have (and I am), looking at Scala code as it seems to typically be written would give you (or at least gives me) pause. I can look at Swift without having ever written any and know roughly what it's doing. I can't with Scala. I don't think they fill the same niche, as the poster seems to be advocating that they could.
- lmm 12y ago
  Groovy's founder has said that he wouldn't have bothered creating it if he'd known about Scala at the time. In Scala you can write almost the same code as Groovy, word for word - but you don't have to give up compile-time type safety for it. (Of course you can do more complex things in Scala, taking advantage of the powerful type system. But you don't have to if you don't want to)
  - divideby0 12y ago
    Groovy has supported compile-time safety since version 2.0 with the optional @CompileStatic annotation. It's one of the few languages where you can mix static and dynamic typing, even within the same class. With this annotation enabled, you get pretty close to pure Java performance but with 1/5 the lines of code in some case. For something like Android, running Groovy with CompileStatic enabled by default would make a lot of sense.
    - vorg 12y ago
      > It's one of the few languages where you can mix static and dynamic typing In theory, but in practise virtually everyone uses the dynamic typing only. Groovy's really only used with Grails and for testing Java classes. > Android, running Groovy with CompileStatic enabled by default would make a lot of sense Unlike other statically-typed languages, Groovy's CompileStatic code was written by only one person and having it be the default would expose all the bugs.
      - pinkyand 12y ago
        > but in practise virtually everyone uses the dynamic typing only. Why ? is it a social thing? or a technical thing?
        tormeh 12y ago
        Any optional and inconvenient feature in a programming language will never be used. It's why static typechecking in Python and Pypy and whatever will never take off.
- vorg 12y ago
  > Groovy could be one such language Android needs a statically typed language, but Groovy's dynamically typed, and the statically typed portions available via annotations since version 2.0 isn't really used much. Groovy's still usable for its original use case of manipulating and testing Java objects, and with Grails, but the more recently promoted stuff isn't being used in favor of other options, and even Gradle seems to have been totally rewritten in Java for Gradle 2.0. I suspect Gradle will soon open its configuration as an API so any language can be used with it.
  - thawkins 12y ago
    Go would make a good candidate, given that it is also a google project.
justplay 12y ago
My bet is for golang.
- izacus 12y ago
  Current design of Android makes any non-JVM language a rather illogical and problematic choice. Writing JNI bridges for everything and reboxing costs would be prohibitive.
  - noss 12y ago
    Android's target machine is google's dalvik vm, and not the jvm.
  - higherpurpose 12y ago
    So what? I think with the arrival of ART, it's also not an impossible task anymore, in terms of compatibility. They just need a separate team to rewrite all the existing API's in Go (and also catch-up with the new ones by the time they finish this project). How much would that take for a team of 20 developers? I imagine not that long. In theory, they could make ART allow for both the Java code and the Go code to work on Android, no? So we could have Google push new app development to Go, while they deprecate Java over the next 5 years (after Go support is out). But to get developers to write Go, they also need a significant market share of Android L/ART-enabled devices, like over 50 percent, which will take 2-3 years to arrive there anyway. They can use this time gap to port Android APIs to Go, and when ART is on 50-70 percent of the devices, announce that developers can now write Android apps in Go, too (for Android L+ only). They could announce it at the release of Android N (the one after M). By then Go 2.0 will probably be out, too, so they can support 2.0 on Android from the beginning, especially if they plan Go 2.0 to have some pretty major incompatibilities with 1.x. In the meantime, the Go team could also work on some "made for Android" features for Go 2.0, to make Go more optimized for Android. By then, they'd probably only have to support ARMv8, too (preferable, I think). So they can target only 64-bit ARMv8 hardware with Go (from what I hear Go works better with 64-bit hardware anyway). I think Google can do this. They just need to plan it out. Three years is probably a reasonable time period for this.
- 12y ago
howdoipython 12y ago
I think there are better selections than groovy to be the next language supported on Android.
otikik 12y ago
Make golang for Android and I'm yours.
- zura 12y ago
  Swift would be better.
  - eigenrick 12y ago
    Rust would be better.
    - BinaryHole 12y ago
      No~Go is the best~ Too simple, and too powerful~
jug6ernaut 12y ago
I would be happy with Java 7/8.
- andwaal 12y ago
  +1
- bni 12y ago
  I bet if Google asked Oracle nicely, it could happen :-)
TeMPOraL 12y ago
Can we have a good Lisp for Android already?
- emidln 12y ago
  Clojure sorta runs on it. It has various issues, but is usable. It's nice having a repl into your phone.
  - mjn 12y ago
    There's also a commercial ($200) Common Lisp implementation that targets Android (and iOS): https://wukix.com/mocl https://wukix.com/mocl Somewhat different setup though. Instead of a Java-replacement language on top of a JVM, I believe it's compiling to native code. The intention seems to be to target "logic-heavy" apps where a smaller portion of the code is UI. You still write the UI in each platform's "normal" way (Java on Android, Obj-C on iOS), but call out to Lisp for the real work. I'm not 100% sure on this part, but I believe that's done on Android via the NDK route, not Dalvik/ART. No idea what happens on iOS.
- deleted 12y ago
  [deleted]
- bachmeier 12y ago
  I've never used it, but this has been around for a while: https://wukix.com/mocl https://wukix.com/mocl
serge2k 12y ago
according to apple, swift uses ARC, not GC. https://developer.apple.com/library/prerelease/mac/documentation/Swift/Conceptual/Swift_Programming_Language/AutomaticReferenceCounting.html https://developer.apple.com/library/prerelease/mac/documenta... How does Scala solve any of the problems with Java?
- lmm 12y ago
  It unifies the type system, which gets one of the big headaches of Java out of the way. It has a generics system that makes a lot more sense (allowing covariant/contravariant types, rather than forcing use-site variance everywhere). Case classes are wonderful for making simple data classes easy to read (and write). Honestly Scala is all about solving the pain points with Java, so just look at anything that's been written about it. http://www.scala-lang.org/ http://www.scala-lang.org/
  - serge2k 12y ago
    right, all nice to have things. Does it actually solve any real problems? Does it fix GC performance? Does it fix API issues? Does it remove the need for JNI bindings to native code? No?
    - lmm 12y ago
      Repetitive code is a real problem. Or do you think performance is the only thing that can ever qualify as a "real problem"? Implicits make it much easier to deal with API issues.
    - tormeh 12y ago
      1) GC: VM issue. Has nothing to do with language. 2) API: Google's responsible for the Android API's but Scala's standard library is definitely better than Java's. 3) JNI performance is a VM issue, again, and JNI interface is Google's problem. These problems are not solvable by any language.
apetrovic 12y ago
Knowing that Google and JetBrains have a good cooperation (Android Studio will replace Eclipse plugin as a preferred way to develop apps for Android), I kinda-sorta expected Kotlin to be backed from Google as an official Android language on the latest I/O.
TeeWEE 12y ago
Please not scala! I prefer to have clojure for android. Scala is too complex, to ugly, and tries todo too much. Its also to heavy for android (it needs tons of libs to run).
- Cyph0n 12y ago
  Clojure would be too large a leap syntax-wise I think. Scala at the very least gives you both FP and OOP in the same language.
  - adambard 12y ago
    Perhaps, but some people have built pretty amazing abstractions in Clojure. I just found this tutorial, and was quite impressed: https://github.com/krisc/events/blob/master/tutorial.md https://github.com/krisc/events/blob/master/tutorial.md
    - phatak-dev 12y ago
      Similar abstractions implemented in Scala http://macroid.github.io/tutorial/BuildingLayouts.html http://macroid.github.io/tutorial/BuildingLayouts.html
- benburton 12y ago
  It seems to be that what's really needed is better JVM language interoperability in Android, then you can choose your poison. * As an aside, for beginner programmers I think that asking them to use a Lisp is far more conceptually challenging than using the basic syntax of Scala (could be wrong though... I don't know Clojure, but I found Common Lisp fairly easy to understand yet know that many beginners do not).
colig 12y ago
Um, people have already been able to use Scala to make Android applications. Just about anything that doesn't require dynamically generated JVM bytecode can manage, difficult and error-prone as it is. If we're talking about official support, then I'd rather Java 8 instead. And beefing up ART even more.
- pjmlp 12y ago
  On the same session, I linked here https://news.ycombinator.com/item?id=8192611 https://news.ycombinator.com/item?id=8192611 The answer to Java 8+ support was "No comment".
- mncolinlee 12y ago
  Technically speaking, Android doesn't fully support Java 6. It's only a partial implementation of Java, since Java is overweight. The Android team has been adding requested features to the SDK in piecemeal form. With that said, you can already get Java 8 lambdas in Android using the retrolambda project. http://zserge.com/blog/android-lambda.html http://zserge.com/blog/android-lambda.html
  - jug6ernaut 12y ago
    How does this work with a jar which contains classes using java8 features? Will it work in this situation or is it only for classes to be compiled? Can retrolambda be applied in other situations to keep the java version at 6 but use java 8 features?
- edgyswingset 12y ago
  To me, Scala just feels like a mess. Java 8 isn't as modern as I'd like, but just having lambda expressions and declarative syntax would boost the quality of life so much.
fritz_vd 12y ago
Um... why .. on .. earth.. scala. Make it stop.
pjmlp 12y ago
It is not going to happen. Google IO 2014, Android development fireside: https://www.google.com/events/io/schedule/session/85311b0e-70ca-e311-b297-00155d5066d7 https://www.google.com/events/io/schedule/session/85311b0e-7... The answer to this request is "Java is the official Android development language".
- phatak-dev 12y ago
  Direct link to the question https://www.youtube.com/watch?v=K3meJyiYWFw#t=1566 https://www.youtube.com/watch?v=K3meJyiYWFw#t=1566
  - smrtinsert 12y ago
    That wasn't linked correctly.
- wes-exp 12y ago
  If I asked a restaurant if they would serve something besides bowls of gruel I would at least expect some sympathy like "we wish we could, but..." Instead they were actually mocking the idea and seem to have no clue how bad Java is.
- on_and_off 12y ago
  In all fairness they also explained that they don't communicate about what they will or might do. Although some core members of the Android team are indeed very outspoken on their opinion that a switch to another language would have a way too big cost/benefits ratio, it does not mean that it cannot happen at some point in the future. In the meantime, the android tools team is hard at work improving the usage of Java on Android. Some examples that should be coming soon : -the end of the 65k limit. -enums with int performances/costs, at least for basic cases. -code hot-swaping (for 2015).
deleted 12y ago
[deleted]
remon 12y ago
Who's "we"? How about we ask Google to focus on things the vast majority of Android developers actually want? Java 7/8 comes to mind. Even if we're looking for just an alternative Android dev language Scala probably wouldn't even be in the top 10.
- eklavya 12y ago
  What matrix are you using where Scala wouldn't make it in top 10? I would bet it would be one of the top choices.
  - remon 12y ago
    Well I'll immediately admit my top 10 comment wasn't exactly based on comprehensive research and polling on the subject. That said I doubt that if such a poll would happen the results would place Scala anywhere near the top. There are just very few upsides for Google to do so. Their main reason for adding language support would be to broaden the developer base that is able to create Android applications and how many Scala developers do you know that aren't fluent in Java?
  - 27182818284 12y ago
    As a new Android developer Scala wouldn't remotely have come to my mind as a feature I wanted anytime soon. The Android Studio is still in beta, the ability to test different platforms with the simulator is less than great (poor) experience still on a MacBook Pro, and the vast majority of developers come out with iOS versions of their products before Android. Those three alone need massive attention before I would even remotely want Google to focus resources on Scala development.
    - ibebrett 12y ago
      Scala is an immensely popular jvm language (as far as jvm langaugesg go). That's why it would be a good candidate.
      - zak_mc_kracken 12y ago
mncolinlee 12y ago
Why not Kotlin? It's more like a modernized Java. It's closer to what Android developers are used to and it already supports Android. It interoperates well with existing Java code in your Android app. Also, it has excellent IDE support, since JetBrains is behind it. http://kotlinlang.org/ http://kotlinlang.org/
- lmm 12y ago
  It's less mature than Scala; it has a smaller developer base or library ecosystem, and it is missing many Scala features (higher-kinded types, implicits). Most of Kotlin's features are already present in Java 8; if you're going to go to the trouble of supporting two languages, it seems perverse to pick Java and Kotlin when they're so similar.
  - curtis17 12y ago
    If Google can't resolve their differences with Oracle Kotlin could be a way forward. Especially given the Android Studio connection.
ryanthejuggler 12y ago
You can use Scala for Android right now, as people are pointing out. However, it feels like a "second-class citizen" because the Android JVM has been optimized for enterprisey, Java-style coding with fewer, longer-lived objects than functional programming usually demands. At a guess, I'd say that with Java 8+ they'd have to fix that. Probably why they said "no comment" as pjmlp pointed out (https://news.ycombinator.com/item?id=8192614 https://news.ycombinator.com/item?id=8192614).
trendnet 12y ago
Why do people think that Swift has a managed runtime with garbage collection? It has reference counting, it's compiled into native code. It has a small runtime lib. linked into the executable (but hey, even C executables have it).
- pjmlp 12y ago
  The younger generations grew with VM based implementations, never learned the memory safe system programming languages that lost the market to C and C++ and lack compiler design understanding. As such, any language they see announced as safer than C and C++ must be VM based.
seivan 12y ago
Swift doesn't have a GC from what I know it has automatic reference counting. It's not really the same thing. It's on compile time and not at run time. It injects release/retain calls between acquiring ownership and relinquishing ownership. I could be wrong but I don't think they added GC to Swift, as Objective-C (at least not on Mac OS) doesn't have it. EDIT: They got rid of the GC on Mac OS as well. They use ARC there as well just like iOS.
- monkey_slap 12y ago
  Correct, Swift uses reference counting in just the same way Objective-C did.
- mikeash 12y ago
  He also says that Swift is bringing lambdas to iOS, when Objective-C has had lambdas for years and years now.
gizmodo59 12y ago
"As phones are getting faster memory is not an issue anymore." No, its not true. Memory is an issue. Android does not only run on premium devices but also economical devices.
Afal 12y ago
No
knodi 12y ago
No. Google its time, we want Go for Android.
- reustle 12y ago
  It's being talked about https://docs.google.com/document/d/1N3XyVkAP8nmWjASz8L_OjjnjVKxgeVBjIsTr5qIUcA4/mobilebasic?pli=1 https://docs.google.com/document/d/1N3XyVkAP8nmWjASz8L_Ojjnj...
  - merlinsbrain 12y ago
    Yes, however there is a major caveat: "Providing a Go equivalent to the Android platform is intractable." What is actually happening: "There is however, a subset of Android apps written against a much smaller C-based API surface provided in the Android NDK: Games. It is feasible to build Go support for Android providing the equivalent features found in the NDK." Source: parent link (https://docs.google.com/document/d/1N3XyVkAP8nmWjASz8L_OjjnjVKxgeVBjIsTr5qIUcA4/mobilebasic?pli=1 https://docs.google.com/document/d/1N3XyVkAP8nmWjASz8L_Ojjnj...)
WoodenChair 12y ago
If they're not even giving us Dart or Go for Android (their own languages), what is the probability they will give us official support for Scala? Yes, Scala runs on the JVM, and the former two don't. And yes, Go is not really designed as an end-user GUI application building language. But Dart has a nice VM of its own and is designed for client-side apps. I would like to see Dart on Android and the original author is definitely confused when he calls Dart and Go "niche" languages (as a way of dismissing them) and somehow doesn't feel the same way about Scala. Scala might be marginally more popular than Go/Dart but it's not an order of magnitude. In fact, according to the latest Tiobe index (a terrible metric in my opinion, but one indicator) Go is more popular than Scala by one place.
- phatak-dev 12y ago
  Original author here I don't mean disrespect when I say niche. I just mean in terms of community, Scala seems to more diversified as it gets used in variety of fields compared to Dart and Go. This is just view of mine.
donniezazen 12y ago
1. Most of the threads like this are going to turn into I like this language so let's rewrite Android in that. 2. Even if Google changes the primary development languages of Android where do you go to ask developers to port their Java libraries, technical bloggers to update their blogs with Scala code or change thousands of questions on SO. Documentation/Q&A created around Java/Android is equally important.
general_failure 12y ago
The article reeks of ignorance. Swift doesn't really have GC (but ARC) - https://www.google.com/webhp?sourceid=chrome-instant&rlz=1C5CHFA_enUS504US504&ion=1&espv=2&ie=UTF-8#q=apple%20swift%20uses%20arc https://www.google.com/webhp?sourceid=chrome-instant&rlz=1C5.... It also takes an unnecessary dig at nodejs. Has the author ever written node.js production code? What bugs has the author found and filed? I am sure most android devs rather have a major ramp up of the Android APIs rather than switching the programming language. The real problem with Android is the ungainly APIs and how very cumbersome it is to develop anything reasonable.
- th3iedkid 12y ago
  Adding more complexity to scala is its dependency on ASM for class file creation [1] and more refined performance options like tail-recursion [2] are implemented in a contrived fashion to make scala actually port to a non-standard JVM like dalvik .However if things were to change from ground-up like ARM actually made easy for functional programming. These facts actually can make porting a performance application to scala quite a job! [1]: http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/2012Q2/GenASM.pdf http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded... [2]: http://blog.richdougherty.com/2009/04/tail-calls-tailrec-and-trampolines.html http://blog.richdougherty.com/2009/04/tail-calls-tailrec-and...
captainmuon 12y ago
I want Python for Android. Ideally, it would compile to Dalvik/ART or ARM. It would use something like PySonar to infer types or use annotations to be able to use native types when possible (for speed & correctness). When the type isn't given or can't be deduced, it would fallback to boxed objects (like Nuitka does, in the way the offically C-Python keeps its objects in memory). But that is not neccessary, all that is needed is a decent wrapper to the Android API for Python, and some packaging support. It is now already possible to compile Python for Android to include it in your app. What I'd like to be able to do is to write the whole thing in Python (+ a GUI design tool maybe). I already see some people saying, that's not possible, because an interpreted language uses too much resources (CPU, memory, esp. battery) for mobile. Well, 90% of the apps I use are not computationally expensive. The consume battery mainly via network access, and via the screen, both of which is independent of the language or runtime used. And when they are doing something computationally intensive, it is usually the layout and drawing of the GUI - most of which is done by the native framework anyway. Most apps are literally just fancy listboxes and details pages, with a database and a web backend. (The great exception are games, of course.) For these apps, a rapid development language like Python (or Javascript, or heck, a new VB) would be great, ideally augmented by good tooling. And if you have something CPU intensive (map routing, image processing, complex translation etc.), you'll just write it in a C library anyway.
- waps 12y ago
  http://kivy.org/ http://kivy.org/ Best you'll get, and quite good.
krschultz 12y ago
This has a lot more to do with refactoring the build system than anything else. The more the build system adheres to the Java Gradle plugin, the easier it is to use Scala or other JVM compatible languages. There is an open ticket for it, and supposedly Gradle 2.0 will make this possible. https://code.google.com/p/android/issues/detail?id=56232 https://code.google.com/p/android/issues/detail?id=56232
jcc333 12y ago
Scala doesn't have very good type inference, dude...
krschultz 12y ago
Theres a different between "supports writing your own code in that language" and "the platform APIs are in a language". In theory, it should be possible to write code on the Android platform using any JVM language. Groovy, Scala, Clojure, Kotlin, etc. There are hiccups to that right now but you can hack your way to it generally. But Android's APIs are going to stay in Java. That is a lot different than Apple's move to Swift, where the platform itself is moving to the new language.
programminggeek 12y ago
I'm not sure the author understands why Java is the language in the first place - there is an army of developers who knows how to use Java. Yeah, it might not be the best language ever, but neither is C++ and neither is Scala. For what Google is doing their choices were basically C++ or Java, there is no other embedded, performant option that hits mass quantities of developers worldwide. Every other language is either too niche, or not performant enough, or doesn't have the features you would want. Sure, I guess they could have done C#, but I'm pretty sure Google hates Microsoft, so that's not going to happen. iOS only has Objective-C because of NextStep and OS X. Otherwise, it could very easily have had C++ or Java. Blackberry ended up with C++ for their native toolkit. Has there been a significant mobile platform that wasn't C++ or Java that doesn't have some historical reason like Obj-C has behind it?
- wes-exp 12y ago
  I think WebOS was going to use JavaScript. The thing about Java and C++ is that they themselves are around for historical reasons. Far better languages have already been proven out. But, it will take a major industry player to move the masses forward on this. Apple's Swift effort gives hope on this.
  - humanrebar 12y ago
    > Far better languages have already been proven out For what they do, C and C++ don't really have serious challengers yet, not that there aren't some promising contenders.
    - wes-exp 12y ago
      When I say proven out, I don't mean in the sense of being widely used; I mean academically. In other words, I am trying to say that it's not a research problem, it's a problem of, say, engineering and marketing to bring it to reality. Cool language features are well established in academia (but tend not to go anywhere due to entrenchment and industry complacency – in that sense I would agree that they aren't 'proven').
zak_mc_kracken 12y ago
The problem is that Scala generates very big jar files, which is why the only couple of Scala Android applications I've ever seen are toy apps. There is no doubt that any more sizeable project will blow up Dalvik's various restrictions like is already happening with Scala apps without ProGuard. There's also the fact that Typesafe doesn't care about Android so even if your current app works on Android, a future version of the compiler might make it blow up on the phone after you recompile it. Unfortunately, the Ceylon team doesn't seem to be interested in supporting Android either. Which leaves Kotlin, as a reasonable option for non-Java development on Android. At any rate, don't expect any help from Google about Scala, they're not even supporting their own non-Java languages there (Go, Dart).
- frowaway001 12y ago
  > The problem is that Scala generates very big jar files, which is why the only couple of Scala Android applications I've ever seen are toy apps. Yes, it's the same problem why compiling Scala to JavaScript is impossible ... oh wait! In both cases the standard library overhead is a few dozens of kB! The horror! That's why nobody is using Scala.js or Scala-on-Android for anything serious ... oh wait! That's already happening.
  - zak_mc_kracken 12y ago
    That's three strawmen in a row, none of them coming remotely close to addressing the point I made above. The web (scala-internals, scala-users, stackoverflow) is filled with threads of people trying to run their Scala code on Android and being mystified by fatal errors from Dalvik or DEX generation simply dying on them.
    - ebruchez 12y ago
      Maybe this could change if Google helped, don't you think?
      - zak_mc_kracken 12y ago
DCKing 12y ago
Over the last few months I've been writing Scala full time, and have even written some (demo grade) Android apps in it. My opinion is: Android should not adopt Scala as one of its primary languages. I think a platform's primary language should be accessible. It is an unfortunate fact that the stuff that most people only know about programming using some object oriented imperative language. People find it harder to hobby with unfamiliar styles, and it is hard to find leverage within your organization to go into unknown territory. If it isn't a popular widely known language (Java) it should at least resemble popular widely known languages (Swift). Give people a piece of Java or Swift code, and they can read it. Give people a piece of Scala code, and they usually cannot. Scala can be an accessible language; its imperative syntax is really nice. But Scala is not an accessible language in that idiomatic real-world Scala and most of its libraries are written in a wholly unfamiliar style. Powerful, yes. People should learn it, yes. But if Scala comes to Android it will only serve to make the platform seem less accessible. And that's a much bigger downside than whatever expressivity Android Java currently lacks. Scala can't even properly be a primary language in parallel to Java at the moment. Swift is just a better syntax for expressing idiomatic Objective C programs. Good Swift programs should look mostly like good Objective C programs with a different syntax - Swift has been made for this purpose [1]. Scala is not a better syntax for expressing idiomatic Java programs. Despite backwards compatibility, good Scala programs look very different to good Java programs. This means that Google cannot present them as equivalents. The Android platform APIs heavily promotes mutability which makes writing idiomatic Scala code for Android a pain in the ass. Should Google ask people to write non-idiomatic code for their new primary language, or should Google provide new APIs for their new primary language? I dislike Java very much. But I think it's a great language for Android, because everyone can do it and that makes the platform accessible. There's only one other language I can even remotely imagine in its place, and that's Dart. And that's not happening either. In the meantime, making Scala run on Android is perfectly doable. That is good enough for me. [1]: I'm aware that this comparison doesn't do Swift as much justice as it should.
- frowaway001 12y ago
  > If it isn't a popular widely known language (Java) it should at least resemble popular widely known languages (Swift). Give people a piece of Java or Swift code, and they can read it. Give people a piece of Scala code, and they usually cannot. You realize that Swift not only resembles Scala syntax closely, but also adopts many of the same concepts? Oh, right. Just the usual Scala bashing ... I think you have forgotten to mention C++.

90 points by phatak-dev 12y ago

I agree that Google should add more languages to android. And while Scala is a great language, it's very complex - so it won't benefit many of the less skilled users. A better language would be something with the simplicity and power of python, but with good performance.Groovy could be one such language.

blablabla123 12y ago
It would be a mass experiment on Functional Programming acceptance ;)
- MichaelGG 12y ago
  Considering that Visual Basic has monads, and lots of C# developers are regularly using closures, I think the response to "is FP accepted" is a resounding yes. Although .NET had to sort of smuggle those features in, under cover.
phatak-dev 12y ago
Scala is not complex in terms of the language design. Most of features [or complexity] come from the libraries.
- taeric 12y ago
  That doesn't do much to make it a great choice, though. In particular, Scala can be a fair bit trickier in terms of knowing your memory profile. Though, I doubt it is much worse than Java these days.
- nvarsj 12y ago
  Implicits? Compared to Java, Scala is not a simple language. I'd say Scala's complexity is on the order of Haskell + Java syntax with additional glue on top of that. Not to say this is bad, it just means you need greater discipline when writing software in Scala. A bit like C++ (yes, I went there! :-)).
  - zak_mc_kracken 12y ago
    I'd say this makes Scala slightly more complex than C++ and Ada. Java and Haskell are not in the same league when it comes to complexity (Java because it's simple, Haskell, because it's wickedly well designed so its complexity is completely tractable).
  - frowaway001 12y ago
    The great thing is that as soon as people mention C++, it's immediately clear that this person has not a single clue what he/she is talking about.
- zak_mc_kracken 12y ago
  Not true, the mix of functional and OO features make the language complex even without the libraries. Throw in implicits, higher kinds, pattern matching, a fairly good generic type system, support for all kinds of polymorphisms (subtyping, ad hoc, duck typing), etc... and you can see complexity emerge pretty quickly.
broodbucket 12y ago
Just because Scala has features that are tricky to get your head around if you're not familiar with functional programming, it doesn't mean it's complex to write software in. You can write Scala that's basically Java with less syntax if you want. I think that's what's so great about Scala, Python and other languages that mix OO and functional elements; you don't have to throw away Java and pick up Haskell, you can start experimenting with other styles as you go.
- TeeWEE 12y ago
  It still doesnt change the fact that Scala, as a programming language, tries to incorporate too many concepts while still trying to be typesafe. This makes the language complex, and not an ideal candidate.
  - benburton 12y ago
    There's no substantiative argument in this comment. > Scala, as a programming language, tries to incorporate too many concepts Too many concepts? Says who? How many concepts is too many? You don't have to use them all, and you can pick them up fairly easily as you go along; that's exactly how I learned the language. > while still trying to be typesafe. Not sure why that's contentious. > This makes the language complex, and not an ideal candidate. Says who? Why? Should all complex things be abandoned? I find the Android framework itself complex, personally, so should we throw that out? This is the same Scala FUD that's always prevalent on Hacker News. "The language does too much." So what? You don't need to know all the concepts to be proficient. The language's beauty is that you can write simple code and pick up the concepts as you go along. Library modularity generally means that you don't need to get into the deep end of the language unless you want to. Scala is an expressive language. That's an intentional design decision that makes it flexible. It is not a drawback. It does not make it overcomplicated for a beginner.
    - apendleton 12y ago
      > Says who? Says at least me and the OP, and probably others... I haven't put a ton of time into learning Scala and only occasionally interact with it, but in that capacity I'd definitely say I find it a bit intimidating and someone hard to read. Certainly there are many ways to write Scala, and a Java-like style is doable, but idiomatic Scala, as far as I've seen, encourages terseness and the use of opaque punctuation-laden operators that aren't immediately interpretable by people not familiar with the language. Whether legibility from non-experts is important is absolutely a matter of opinion and personal taste (it's a clear source of disagreement between the Python and Ruby communities as well), but if you're someone who thinks it's an important property for languages that get widespread adoption to have (and I am), looking at Scala code as it seems to typically be written would give you (or at least gives me) pause. I can look at Swift without having ever written any and know roughly what it's doing. I can't with Scala. I don't think they fill the same niche, as the poster seems to be advocating that they could.
lmm 12y ago
Groovy's founder has said that he wouldn't have bothered creating it if he'd known about Scala at the time. In Scala you can write almost the same code as Groovy, word for word - but you don't have to give up compile-time type safety for it. (Of course you can do more complex things in Scala, taking advantage of the powerful type system. But you don't have to if you don't want to)
- divideby0 12y ago
  Groovy has supported compile-time safety since version 2.0 with the optional @CompileStatic annotation. It's one of the few languages where you can mix static and dynamic typing, even within the same class. With this annotation enabled, you get pretty close to pure Java performance but with 1/5 the lines of code in some case. For something like Android, running Groovy with CompileStatic enabled by default would make a lot of sense.
  - vorg 12y ago
    > It's one of the few languages where you can mix static and dynamic typing In theory, but in practise virtually everyone uses the dynamic typing only. Groovy's really only used with Grails and for testing Java classes. > Android, running Groovy with CompileStatic enabled by default would make a lot of sense Unlike other statically-typed languages, Groovy's CompileStatic code was written by only one person and having it be the default would expose all the bugs.
    - pinkyand 12y ago
      > but in practise virtually everyone uses the dynamic typing only. Why ? is it a social thing? or a technical thing?
      - tormeh 12y ago
        Any optional and inconvenient feature in a programming language will never be used. It's why static typechecking in Python and Pypy and whatever will never take off.
vorg 12y ago
> Groovy could be one such language Android needs a statically typed language, but Groovy's dynamically typed, and the statically typed portions available via annotations since version 2.0 isn't really used much. Groovy's still usable for its original use case of manipulating and testing Java objects, and with Grails, but the more recently promoted stuff isn't being used in favor of other options, and even Gradle seems to have been totally rewritten in Java for Gradle 2.0. I suspect Gradle will soon open its configuration as an API so any language can be used with it.
- thawkins 12y ago
  Go would make a good candidate, given that it is also a google project.

justplay 12y ago

My bet is for golang.

izacus 12y ago
Current design of Android makes any non-JVM language a rather illogical and problematic choice. Writing JNI bridges for everything and reboxing costs would be prohibitive.
- noss 12y ago
  Android's target machine is google's dalvik vm, and not the jvm.
- higherpurpose 12y ago
  So what? I think with the arrival of ART, it's also not an impossible task anymore, in terms of compatibility. They just need a separate team to rewrite all the existing API's in Go (and also catch-up with the new ones by the time they finish this project). How much would that take for a team of 20 developers? I imagine not that long. In theory, they could make ART allow for both the Java code and the Go code to work on Android, no? So we could have Google push new app development to Go, while they deprecate Java over the next 5 years (after Go support is out). But to get developers to write Go, they also need a significant market share of Android L/ART-enabled devices, like over 50 percent, which will take 2-3 years to arrive there anyway. They can use this time gap to port Android APIs to Go, and when ART is on 50-70 percent of the devices, announce that developers can now write Android apps in Go, too (for Android L+ only). They could announce it at the release of Android N (the one after M). By then Go 2.0 will probably be out, too, so they can support 2.0 on Android from the beginning, especially if they plan Go 2.0 to have some pretty major incompatibilities with 1.x. In the meantime, the Go team could also work on some "made for Android" features for Go 2.0, to make Go more optimized for Android. By then, they'd probably only have to support ARMv8, too (preferable, I think). So they can target only 64-bit ARMv8 hardware with Go (from what I hear Go works better with 64-bit hardware anyway). I think Google can do this. They just need to plan it out. Three years is probably a reasonable time period for this.
12y ago

howdoipython 12y ago

I think there are better selections than groovy to be the next language supported on Android.

otikik 12y ago

Make golang for Android and I'm yours.

zura 12y ago
Swift would be better.
- eigenrick 12y ago
  Rust would be better.
  - BinaryHole 12y ago
    No~Go is the best~ Too simple, and too powerful~

jug6ernaut 12y ago

I would be happy with Java 7/8.

andwaal 12y ago
+1
bni 12y ago
I bet if Google asked Oracle nicely, it could happen :-)

TeMPOraL 12y ago

Can we have a good Lisp for Android already?

emidln 12y ago
Clojure sorta runs on it. It has various issues, but is usable. It's nice having a repl into your phone.
- mjn 12y ago
  There's also a commercial ($200) Common Lisp implementation that targets Android (and iOS): https://wukix.com/mocl https://wukix.com/mocl Somewhat different setup though. Instead of a Java-replacement language on top of a JVM, I believe it's compiling to native code. The intention seems to be to target "logic-heavy" apps where a smaller portion of the code is UI. You still write the UI in each platform's "normal" way (Java on Android, Obj-C on iOS), but call out to Lisp for the real work. I'm not 100% sure on this part, but I believe that's done on Android via the NDK route, not Dalvik/ART. No idea what happens on iOS.
deleted 12y ago
[deleted]
bachmeier 12y ago
I've never used it, but this has been around for a while: https://wukix.com/mocl https://wukix.com/mocl

serge2k 12y ago

according to apple, swift uses ARC, not GC. https://developer.apple.com/library/prerelease/mac/documentation/Swift/Conceptual/Swift_Programming_Language/AutomaticReferenceCounting.html https://developer.apple.com/library/prerelease/mac/documenta... How does Scala solve any of the problems with Java?

lmm 12y ago
It unifies the type system, which gets one of the big headaches of Java out of the way. It has a generics system that makes a lot more sense (allowing covariant/contravariant types, rather than forcing use-site variance everywhere). Case classes are wonderful for making simple data classes easy to read (and write). Honestly Scala is all about solving the pain points with Java, so just look at anything that's been written about it. http://www.scala-lang.org/ http://www.scala-lang.org/
- serge2k 12y ago
  right, all nice to have things. Does it actually solve any real problems? Does it fix GC performance? Does it fix API issues? Does it remove the need for JNI bindings to native code? No?
  - lmm 12y ago
    Repetitive code is a real problem. Or do you think performance is the only thing that can ever qualify as a "real problem"? Implicits make it much easier to deal with API issues.
  - tormeh 12y ago
    1) GC: VM issue. Has nothing to do with language. 2) API: Google's responsible for the Android API's but Scala's standard library is definitely better than Java's. 3) JNI performance is a VM issue, again, and JNI interface is Google's problem. These problems are not solvable by any language.

apetrovic 12y ago

Knowing that Google and JetBrains have a good cooperation (Android Studio will replace Eclipse plugin as a preferred way to develop apps for Android), I kinda-sorta expected Kotlin to be backed from Google as an official Android language on the latest I/O.

TeeWEE 12y ago

Please not scala! I prefer to have clojure for android. Scala is too complex, to ugly, and tries todo too much. Its also to heavy for android (it needs tons of libs to run).

Cyph0n 12y ago
Clojure would be too large a leap syntax-wise I think. Scala at the very least gives you both FP and OOP in the same language.
- adambard 12y ago
  Perhaps, but some people have built pretty amazing abstractions in Clojure. I just found this tutorial, and was quite impressed: https://github.com/krisc/events/blob/master/tutorial.md https://github.com/krisc/events/blob/master/tutorial.md
  - phatak-dev 12y ago
    Similar abstractions implemented in Scala http://macroid.github.io/tutorial/BuildingLayouts.html http://macroid.github.io/tutorial/BuildingLayouts.html
benburton 12y ago
It seems to be that what's really needed is better JVM language interoperability in Android, then you can choose your poison. * As an aside, for beginner programmers I think that asking them to use a Lisp is far more conceptually challenging than using the basic syntax of Scala (could be wrong though... I don't know Clojure, but I found Common Lisp fairly easy to understand yet know that many beginners do not).

colig 12y ago

Um, people have already been able to use Scala to make Android applications. Just about anything that doesn't require dynamically generated JVM bytecode can manage, difficult and error-prone as it is. If we're talking about official support, then I'd rather Java 8 instead. And beefing up ART even more.

pjmlp 12y ago
On the same session, I linked here https://news.ycombinator.com/item?id=8192611 https://news.ycombinator.com/item?id=8192611 The answer to Java 8+ support was "No comment".
mncolinlee 12y ago
Technically speaking, Android doesn't fully support Java 6. It's only a partial implementation of Java, since Java is overweight. The Android team has been adding requested features to the SDK in piecemeal form. With that said, you can already get Java 8 lambdas in Android using the retrolambda project. http://zserge.com/blog/android-lambda.html http://zserge.com/blog/android-lambda.html
- jug6ernaut 12y ago
  How does this work with a jar which contains classes using java8 features? Will it work in this situation or is it only for classes to be compiled? Can retrolambda be applied in other situations to keep the java version at 6 but use java 8 features?
edgyswingset 12y ago
To me, Scala just feels like a mess. Java 8 isn't as modern as I'd like, but just having lambda expressions and declarative syntax would boost the quality of life so much.

fritz_vd 12y ago

Um... why .. on .. earth.. scala. Make it stop.

pjmlp 12y ago

It is not going to happen. Google IO 2014, Android development fireside: https://www.google.com/events/io/schedule/session/85311b0e-70ca-e311-b297-00155d5066d7 https://www.google.com/events/io/schedule/session/85311b0e-7... The answer to this request is "Java is the official Android development language".

phatak-dev 12y ago
Direct link to the question https://www.youtube.com/watch?v=K3meJyiYWFw#t=1566 https://www.youtube.com/watch?v=K3meJyiYWFw#t=1566
- smrtinsert 12y ago
  That wasn't linked correctly.
wes-exp 12y ago
If I asked a restaurant if they would serve something besides bowls of gruel I would at least expect some sympathy like "we wish we could, but..." Instead they were actually mocking the idea and seem to have no clue how bad Java is.
on_and_off 12y ago
In all fairness they also explained that they don't communicate about what they will or might do. Although some core members of the Android team are indeed very outspoken on their opinion that a switch to another language would have a way too big cost/benefits ratio, it does not mean that it cannot happen at some point in the future. In the meantime, the android tools team is hard at work improving the usage of Java on Android. Some examples that should be coming soon : -the end of the 65k limit. -enums with int performances/costs, at least for basic cases. -code hot-swaping (for 2015).

deleted 12y ago

[deleted]

remon 12y ago

Who's "we"? How about we ask Google to focus on things the vast majority of Android developers actually want? Java 7/8 comes to mind. Even if we're looking for just an alternative Android dev language Scala probably wouldn't even be in the top 10.

eklavya 12y ago
What matrix are you using where Scala wouldn't make it in top 10? I would bet it would be one of the top choices.
- remon 12y ago
  Well I'll immediately admit my top 10 comment wasn't exactly based on comprehensive research and polling on the subject. That said I doubt that if such a poll would happen the results would place Scala anywhere near the top. There are just very few upsides for Google to do so. Their main reason for adding language support would be to broaden the developer base that is able to create Android applications and how many Scala developers do you know that aren't fluent in Java?
- 27182818284 12y ago
  As a new Android developer Scala wouldn't remotely have come to my mind as a feature I wanted anytime soon. The Android Studio is still in beta, the ability to test different platforms with the simulator is less than great (poor) experience still on a MacBook Pro, and the vast majority of developers come out with iOS versions of their products before Android. Those three alone need massive attention before I would even remotely want Google to focus resources on Scala development.
  - ibebrett 12y ago
    Scala is an immensely popular jvm language (as far as jvm langaugesg go). That's why it would be a good candidate.
    - zak_mc_kracken 12y ago

mncolinlee 12y ago

Why not Kotlin? It's more like a modernized Java. It's closer to what Android developers are used to and it already supports Android. It interoperates well with existing Java code in your Android app. Also, it has excellent IDE support, since JetBrains is behind it. http://kotlinlang.org/ http://kotlinlang.org/

lmm 12y ago
It's less mature than Scala; it has a smaller developer base or library ecosystem, and it is missing many Scala features (higher-kinded types, implicits). Most of Kotlin's features are already present in Java 8; if you're going to go to the trouble of supporting two languages, it seems perverse to pick Java and Kotlin when they're so similar.
- curtis17 12y ago
  If Google can't resolve their differences with Oracle Kotlin could be a way forward. Especially given the Android Studio connection.

ryanthejuggler 12y ago

You can use Scala for Android right now, as people are pointing out. However, it feels like a "second-class citizen" because the Android JVM has been optimized for enterprisey, Java-style coding with fewer, longer-lived objects than functional programming usually demands. At a guess, I'd say that with Java 8+ they'd have to fix that. Probably why they said "no comment" as pjmlp pointed out (https://news.ycombinator.com/item?id=8192614 https://news.ycombinator.com/item?id=8192614).

trendnet 12y ago

Why do people think that Swift has a managed runtime with garbage collection? It has reference counting, it's compiled into native code. It has a small runtime lib. linked into the executable (but hey, even C executables have it).

pjmlp 12y ago
The younger generations grew with VM based implementations, never learned the memory safe system programming languages that lost the market to C and C++ and lack compiler design understanding. As such, any language they see announced as safer than C and C++ must be VM based.

seivan 12y ago

Swift doesn't have a GC from what I know it has automatic reference counting. It's not really the same thing. It's on compile time and not at run time. It injects release/retain calls between acquiring ownership and relinquishing ownership. I could be wrong but I don't think they added GC to Swift, as Objective-C (at least not on Mac OS) doesn't have it. EDIT: They got rid of the GC on Mac OS as well. They use ARC there as well just like iOS.

monkey_slap 12y ago
Correct, Swift uses reference counting in just the same way Objective-C did.
mikeash 12y ago
He also says that Swift is bringing lambdas to iOS, when Objective-C has had lambdas for years and years now.

gizmodo59 12y ago

"As phones are getting faster memory is not an issue anymore." No, its not true. Memory is an issue. Android does not only run on premium devices but also economical devices.

Afal 12y ago

knodi 12y ago

No. Google its time, we want Go for Android.

reustle 12y ago
It's being talked about https://docs.google.com/document/d/1N3XyVkAP8nmWjASz8L_OjjnjVKxgeVBjIsTr5qIUcA4/mobilebasic?pli=1 https://docs.google.com/document/d/1N3XyVkAP8nmWjASz8L_Ojjnj...
- merlinsbrain 12y ago
  Yes, however there is a major caveat: "Providing a Go equivalent to the Android platform is intractable." What is actually happening: "There is however, a subset of Android apps written against a much smaller C-based API surface provided in the Android NDK: Games. It is feasible to build Go support for Android providing the equivalent features found in the NDK." Source: parent link (https://docs.google.com/document/d/1N3XyVkAP8nmWjASz8L_OjjnjVKxgeVBjIsTr5qIUcA4/mobilebasic?pli=1 https://docs.google.com/document/d/1N3XyVkAP8nmWjASz8L_Ojjnj...)

WoodenChair 12y ago

If they're not even giving us Dart or Go for Android (their own languages), what is the probability they will give us official support for Scala? Yes, Scala runs on the JVM, and the former two don't. And yes, Go is not really designed as an end-user GUI application building language. But Dart has a nice VM of its own and is designed for client-side apps. I would like to see Dart on Android and the original author is definitely confused when he calls Dart and Go "niche" languages (as a way of dismissing them) and somehow doesn't feel the same way about Scala. Scala might be marginally more popular than Go/Dart but it's not an order of magnitude. In fact, according to the latest Tiobe index (a terrible metric in my opinion, but one indicator) Go is more popular than Scala by one place.

phatak-dev 12y ago
Original author here I don't mean disrespect when I say niche. I just mean in terms of community, Scala seems to more diversified as it gets used in variety of fields compared to Dart and Go. This is just view of mine.

donniezazen 12y ago

1. Most of the threads like this are going to turn into I like this language so let's rewrite Android in that. 2. Even if Google changes the primary development languages of Android where do you go to ask developers to port their Java libraries, technical bloggers to update their blogs with Scala code or change thousands of questions on SO. Documentation/Q&A created around Java/Android is equally important.

general_failure 12y ago

The article reeks of ignorance. Swift doesn't really have GC (but ARC) - https://www.google.com/webhp?sourceid=chrome-instant&rlz=1C5CHFA_enUS504US504&ion=1&espv=2&ie=UTF-8#q=apple%20swift%20uses%20arc https://www.google.com/webhp?sourceid=chrome-instant&rlz=1C5.... It also takes an unnecessary dig at nodejs. Has the author ever written node.js production code? What bugs has the author found and filed? I am sure most android devs rather have a major ramp up of the Android APIs rather than switching the programming language. The real problem with Android is the ungainly APIs and how very cumbersome it is to develop anything reasonable.

th3iedkid 12y ago
Adding more complexity to scala is its dependency on ASM for class file creation [1] and more refined performance options like tail-recursion [2] are implemented in a contrived fashion to make scala actually port to a non-standard JVM like dalvik .However if things were to change from ground-up like ARM actually made easy for functional programming. These facts actually can make porting a performance application to scala quite a job! [1]: http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/2012Q2/GenASM.pdf http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded... [2]: http://blog.richdougherty.com/2009/04/tail-calls-tailrec-and-trampolines.html http://blog.richdougherty.com/2009/04/tail-calls-tailrec-and...

captainmuon 12y ago

I want Python for Android. Ideally, it would compile to Dalvik/ART or ARM. It would use something like PySonar to infer types or use annotations to be able to use native types when possible (for speed & correctness). When the type isn't given or can't be deduced, it would fallback to boxed objects (like Nuitka does, in the way the offically C-Python keeps its objects in memory). But that is not neccessary, all that is needed is a decent wrapper to the Android API for Python, and some packaging support. It is now already possible to compile Python for Android to include it in your app. What I'd like to be able to do is to write the whole thing in Python (+ a GUI design tool maybe). I already see some people saying, that's not possible, because an interpreted language uses too much resources (CPU, memory, esp. battery) for mobile. Well, 90% of the apps I use are not computationally expensive. The consume battery mainly via network access, and via the screen, both of which is independent of the language or runtime used. And when they are doing something computationally intensive, it is usually the layout and drawing of the GUI - most of which is done by the native framework anyway. Most apps are literally just fancy listboxes and details pages, with a database and a web backend. (The great exception are games, of course.) For these apps, a rapid development language like Python (or Javascript, or heck, a new VB) would be great, ideally augmented by good tooling. And if you have something CPU intensive (map routing, image processing, complex translation etc.), you'll just write it in a C library anyway.

waps 12y ago
http://kivy.org/ http://kivy.org/ Best you'll get, and quite good.

krschultz 12y ago

This has a lot more to do with refactoring the build system than anything else. The more the build system adheres to the Java Gradle plugin, the easier it is to use Scala or other JVM compatible languages. There is an open ticket for it, and supposedly Gradle 2.0 will make this possible. https://code.google.com/p/android/issues/detail?id=56232 https://code.google.com/p/android/issues/detail?id=56232

jcc333 12y ago

Scala doesn't have very good type inference, dude...

krschultz 12y ago

Theres a different between "supports writing your own code in that language" and "the platform APIs are in a language". In theory, it should be possible to write code on the Android platform using any JVM language. Groovy, Scala, Clojure, Kotlin, etc. There are hiccups to that right now but you can hack your way to it generally. But Android's APIs are going to stay in Java. That is a lot different than Apple's move to Swift, where the platform itself is moving to the new language.

programminggeek 12y ago

I'm not sure the author understands why Java is the language in the first place - there is an army of developers who knows how to use Java. Yeah, it might not be the best language ever, but neither is C++ and neither is Scala. For what Google is doing their choices were basically C++ or Java, there is no other embedded, performant option that hits mass quantities of developers worldwide. Every other language is either too niche, or not performant enough, or doesn't have the features you would want. Sure, I guess they could have done C#, but I'm pretty sure Google hates Microsoft, so that's not going to happen. iOS only has Objective-C because of NextStep and OS X. Otherwise, it could very easily have had C++ or Java. Blackberry ended up with C++ for their native toolkit. Has there been a significant mobile platform that wasn't C++ or Java that doesn't have some historical reason like Obj-C has behind it?

wes-exp 12y ago
I think WebOS was going to use JavaScript. The thing about Java and C++ is that they themselves are around for historical reasons. Far better languages have already been proven out. But, it will take a major industry player to move the masses forward on this. Apple's Swift effort gives hope on this.
- humanrebar 12y ago
  > Far better languages have already been proven out For what they do, C and C++ don't really have serious challengers yet, not that there aren't some promising contenders.
  - wes-exp 12y ago
    When I say proven out, I don't mean in the sense of being widely used; I mean academically. In other words, I am trying to say that it's not a research problem, it's a problem of, say, engineering and marketing to bring it to reality. Cool language features are well established in academia (but tend not to go anywhere due to entrenchment and industry complacency – in that sense I would agree that they aren't 'proven').

zak_mc_kracken 12y ago

The problem is that Scala generates very big jar files, which is why the only couple of Scala Android applications I've ever seen are toy apps. There is no doubt that any more sizeable project will blow up Dalvik's various restrictions like is already happening with Scala apps without ProGuard. There's also the fact that Typesafe doesn't care about Android so even if your current app works on Android, a future version of the compiler might make it blow up on the phone after you recompile it. Unfortunately, the Ceylon team doesn't seem to be interested in supporting Android either. Which leaves Kotlin, as a reasonable option for non-Java development on Android. At any rate, don't expect any help from Google about Scala, they're not even supporting their own non-Java languages there (Go, Dart).

frowaway001 12y ago
> The problem is that Scala generates very big jar files, which is why the only couple of Scala Android applications I've ever seen are toy apps. Yes, it's the same problem why compiling Scala to JavaScript is impossible ... oh wait! In both cases the standard library overhead is a few dozens of kB! The horror! That's why nobody is using Scala.js or Scala-on-Android for anything serious ... oh wait! That's already happening.
- zak_mc_kracken 12y ago
  That's three strawmen in a row, none of them coming remotely close to addressing the point I made above. The web (scala-internals, scala-users, stackoverflow) is filled with threads of people trying to run their Scala code on Android and being mystified by fatal errors from Dalvik or DEX generation simply dying on them.
  - ebruchez 12y ago
    Maybe this could change if Google helped, don't you think?
    - zak_mc_kracken 12y ago

DCKing 12y ago

Over the last few months I've been writing Scala full time, and have even written some (demo grade) Android apps in it. My opinion is: Android should not adopt Scala as one of its primary languages. I think a platform's primary language should be accessible. It is an unfortunate fact that the stuff that most people only know about programming using some object oriented imperative language. People find it harder to hobby with unfamiliar styles, and it is hard to find leverage within your organization to go into unknown territory. If it isn't a popular widely known language (Java) it should at least resemble popular widely known languages (Swift). Give people a piece of Java or Swift code, and they can read it. Give people a piece of Scala code, and they usually cannot. Scala can be an accessible language; its imperative syntax is really nice. But Scala is not an accessible language in that idiomatic real-world Scala and most of its libraries are written in a wholly unfamiliar style. Powerful, yes. People should learn it, yes. But if Scala comes to Android it will only serve to make the platform seem less accessible. And that's a much bigger downside than whatever expressivity Android Java currently lacks. Scala can't even properly be a primary language in parallel to Java at the moment. Swift is just a better syntax for expressing idiomatic Objective C programs. Good Swift programs should look mostly like good Objective C programs with a different syntax - Swift has been made for this purpose [1]. Scala is not a better syntax for expressing idiomatic Java programs. Despite backwards compatibility, good Scala programs look very different to good Java programs. This means that Google cannot present them as equivalents. The Android platform APIs heavily promotes mutability which makes writing idiomatic Scala code for Android a pain in the ass. Should Google ask people to write non-idiomatic code for their new primary language, or should Google provide new APIs for their new primary language? I dislike Java very much. But I think it's a great language for Android, because everyone can do it and that makes the platform accessible. There's only one other language I can even remotely imagine in its place, and that's Dart. And that's not happening either. In the meantime, making Scala run on Android is perfectly doable. That is good enough for me. [1]: I'm aware that this comparison doesn't do Swift as much justice as it should.

frowaway001 12y ago
> If it isn't a popular widely known language (Java) it should at least resemble popular widely known languages (Swift). Give people a piece of Java or Swift code, and they can read it. Give people a piece of Scala code, and they usually cannot. You realize that Swift not only resembles Scala syntax closely, but also adopts many of the same concepts? Oh, right. Just the usual Scala bashing ... I think you have forgotten to mention C++.