Hacker News Reader

Comment by jamesbritt | Hacker News Reader

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

Mirah.

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

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

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

View on HN

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

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.

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.

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.

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.

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

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

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

     in statically typed functional languages, 
     type inference

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

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

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

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

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

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.

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

Currying is not idiomatic in Scala. But other than that -- what? This makes no sense to me, as someone who write Scala most days of the week.

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

Read "Type Classes as Objects and Implicits" (e.g. http://lambda-the-ultimate.org/node/4039) for how type classes are 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.

No.

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

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

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

Here, I'll get you started:

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

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

Compare this to the Python version:

    print "Hello world"

Or the Haskell version:

    main = putStrLn "Hello, World!"

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

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.

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.

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.

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.

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.

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

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

Reply on news.ycombinator.com