Hacker News Reader

Comment by PaulHoule | Hacker News Reader

The damning point against Scala there is that the Scala program is only about 30% the length of Java.

That's not enough savings to make up for the complexity of a language that seems like an unholy union of Perl, C++ and F#.

For me the breakthrough in Scala was understanding enough about how it works that I could interface with Scala code easily in Java. At that point I could copy any of those patterns in Java. They were a little more verbose than Scala, but more reliable because I wasn't worrying that some piece of magic was going to cause something extraordinary to happen.

View on HN

The Author states that the program was so long because he was new to the language when he wrote it. Scala can be very very terse if you know what you are doing with it. I have had projects that went from 1K+ lines of c++ to 300 lines of Scala to 10 lines of Scala. The language didn't change to give me that decrease in LOC, I did. The more I moved from the translation of C++ to a functional design in the program the better i was able to express the code.

As someone who's done a lot of functional and OO programing over the years, I find it very hard to believe that you have multiple projects that went from 1K+ lines of C++ to 10 lines of Scala.

Claims like this are the sort of thing that make make it hard to convince people to try functional programming, because they think that FP evangelists are full of shit.

In C++ I implemented a lot of functionality by hand using mostly glibc and stl. In scala there are library's to help with threading and network I/O in my case it was A combination of threading (Akka), Network I/O (again Akka) and HTTPS communication (dispatch-http). So yes this was a combination of a better programing style and better support for libraries (SBT)

A little more verbose? Lets see, Scala vs Java in a promise-based async server:

Java (real code - this is a mild example, imagine this 8 indents deep):

  return users.verifyAccess(userId, oldPassword).flatMap(
    new Callable1<Promise<DataObject>, UserProfile>() {
      @Override
      public Promise<DataObject> call(UserProfile profile) {
        return replyProfile(profile.setPassword(newPassword));
     }
  });

Scala (translated):

  for {
    profile <- users.verifyAccess(userId, oldPassword)
  } replyProfile(profile.setPassword(newPassword))

(observe how you can actually read the code)

Oh man, I wish we started with Scala (or wrote everything sync)... My conclusion from all of this was that Java makes certain abstractions impractical from a readability standpoint.

From my - some years, but rather limited - experience with Scala (compared to a decade of Java), the largest point for Scala is how it works with monads e.g. Option, eliminating a lot of "if" statements and making APIs much clearer. And I did not expect this to be the main difference to Java when I've started working with Scala some years ago, I thought it would be closures (which are a nice thing, I especially like the _ syntax).

Don't you have to have closures to make monads work in practice? (I only really have experience with monads in Haskell, and something like (a >>= \x -> b >>= \y -> g x y) is a very basic thing to do with monads, there.)

"Only about 30% the length of Java" seems like a huge savings. What would you prefer?

Reply on news.ycombinator.com