C'mon, stop writing Java for Android(robots.thoughtbot.com)
robots.thoughtbot.com
C'mon, stop writing Java for Android
http://robots.thoughtbot.com/post/5836463058/scala-a-better-java-for-android
16 comments
>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.
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.
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.
Thanks; it's very helpful to see some hard numbers. That's quite good--I expected it to be much higher. I don't suppose it introduces any noticeable startup delay, does it?
No. Although Scala does introduce many more temporary objects so you might want to be careful with allocations and the types e.g. undiscriminated use of tuples. This may not be an issue depending on your performance needs.
Thanks; it's very helpful to see some hard numbers.
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.
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.
I don't understand all of the Scala hate on Hacker news. First of all, the ONLY language I am aware of that provides guarantees on immutability is Haskell, as it is the only language I am know of that has any kind of serious effects system. I'm sure there are others (Clean might be one of them), but they certainly aren't in common use. That means that you must also not like Scheme/Racket, Clojure, CL, or the ML's, and you must not consider them to have killer FP value either.
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.
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.
That means that you must also not like Scheme/Racket, Clojure, CL, or the ML's, ...
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.
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 think you're nit-picking at my choice of words a little too much rather than the points I was trying to make. For instance, when I said Scala was not worthy of your criticisms, I meant in effect, your comments aren't accurate! :-)
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 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.
> 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. ;)
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.
It seems you don't like Scala, but I don't think your complaints accurately represent the language.
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.
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
> 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.
Isn't this ... Scala?
Sure, it has a lot more too, but there's zero obligation to use every single feature.
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:
Compare this to the Python version:
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!"
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 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.
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 the only thing your hello world example proves is that hello world examples don't really demonstrate the overall complexity of programming languages very well, especially when you try to use it to say Haskell is easier to explain. Sure the Haskell version of Hello World looks simple but, once you get even a little beyond that example you start having to explain MUCH more complicated subjects such as currying, monads, functors, typeclasses, etc. Don't get me wrong I love Haskell but it certainly isn't easier to learn then Scala even if the syntax is less verbose. I don't really get your argument that Scala code does not scale to solve complex problems; I would actually argue that Scala does that very well. Now I will agree that some aspect of Scala syntax are ugly but overall it seems to do an okay job unifying object oriented and functional programming while remaining accesible.
That's a very contrived example which certainly falls apart in Haskell as soon as you do anything relatively complex (Python I would agree is a perfect language for learning to program).
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.
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.
Scala's support for implicit parameters lets you do most everything you can with type classes. Plus, implicits have scope in Scala, so can choose which you wish to apply in a given context. With type classes the scope is global, so you're stuck with one implementation per type per project.
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.
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.
Perhaps http://ropas.snu.ac.kr/~bruno/papers/TypeClasses.pdf is the paper that you're looking for?
Yes, that's it. Thanks.
> The entire Haskell standard library could be rewritten, more or less, in Scala. How is that "kinda" functional?
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.
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.
Mirah is what finally got me started with Android development. Coming from a Ruby background there's practically zero learning curve, plus you can install it from RubyGems (which when using RVM makes it dead-simple).
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.
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.
"you still have to include the Scala base libraries with every app. Proguard may help, but it seems wasteful."
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.
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.
>> But the functional part gives no guarantees of referential transparency or immutable state, so the killer value of FP is lost.
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.
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.
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.
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.
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.
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.
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).
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).
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".
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...
(at the end during Q&A)
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)
I think everybody should just call it "golang"
It helps to include the words "lang" or "language" in the search. Kinda frustrating.
There is a "Custom Search Engine" for Go: http://go-lang.cat-v.org/go-search
Interesting. Possibly to skirt the Oracle/Java mess? If so, I think it's a great idea. iOS/Obj-C has shown that devs will use a new (to them) language if need be.
With Golang on AppEngine, I can see a momentum within Google pushing for Golang for Android. Rob's comment sounds very positive. I'm guessing we will see something at Google IO next year.
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.
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.
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).
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.
You absolutely need proguard since the Scala library is several megs in size, and will likely grow bigger when specialization goes everywhere.
See answer posted elsewhere in the thread: http://news.ycombinator.com/item?id=2585541
I haven't tried myself, but I have used GNU Kawa to great success, and your right, Proguard does strip most of it out.
I tried both Mirah and Scala and I'm sticking with Java for the IDE integration.
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.
If it wasn't for that, we'd leap at the opportunity to use Scala.
I also would love to hear from someone who has put effort into and succeeded, or failed, at selling their enterprise clients on Scala.
Has anyone written any Clojure for Android so far as anyone knows?
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.
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.
> 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.
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.
i love to use scala on android. has anyone developed any 'real' app with scala on android?
There's also the issue of all the ephemeral garbage Clojure tends to create and gets disposed. Not sure if 1.3 generates less but oh a phone that stuff adds up.
I thought there were some GC optimizations needed to make it work efficiently on android. I was under the impression it worked ok for Android 1.2 phones and up.
> I was under the impression it worked ok for Android 1.2 phones and up.
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."
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."
Have a look at those slides and blog entries:
http://www.deepbluelambda.org/programming/clojure/
http://www.deepbluelambda.org/programming/clojure/
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
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
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.
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.
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.
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.
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.
I'll switch to scala or any other language if it will abstract away SQL cursors with minimal overhead.
> 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.
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.
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.
> 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.
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.
Don't take my System.out's away from me wierdo.
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.