View of Scala from Java | Hacker News Reader

View of Scala from Java

thepolygl0t.blogspot.com

27 pointstathagatadg23 comments

From the article:

    val x = new Array[Integer](3)  //type inferred for x
    x(0) = 1
    x(1) = 2
    x(2) = 3
    
    for (y <- x if y > 2)
        println(y)

The idiomatic way to do this is:

    val x = Array(1, 2, 3)

That infers the type and sets values in one shot, with fewer characters. Also, using Integer (that's the java.lang.Integer) has been deprecated since 2.8.1 I believe. `Int` is preferred unless you really mean to use `Integer` (e.g. you're using a native Java library).

By not using the declaration, the type of x is Array[Nothing], and it lacks the `withFilter` attribute.

I'm not so sure about that...

    C:\Users\bert>scala
    Welcome to Scala version 2.9.2 (Java HotSpot(TM) Client VM, Java 1.7.0_06).
    Type in expressions to have them evaluated.
    Type :help for more information.

    scala> val x = Array(1, 2, 3)
    x: Array[Int] = Array(1, 2, 3)

    scala>

You can see that scala infers the type right (Array[Int]).

Even, I find this strange and I may be wrong. With your definition, when I use the for construct, I see this:

    scala> for (y<-x if x > 2)
         | println(y)
    <console>:9: error: value > is not a member of Array[Int]
              for (y<-x if x > 2)
                             ^

As you suggested, there may be a idiomatically better way to get implicit inference and also use the filters. I would be glad if some one corrects me on that.

Edit: Yeah, I see the silly error I made. I'll better get some sleep. I will leave this comment intact, for the responses to make sense.

You are comparing an array of integers with an integer. You would want to do this instead:

    for (y <- x if y > 2) ...

You made a typo, it should be "y > 2" in your filter expression.

Get some sleep, then spend another week playing with Scala and its REPL. It's a terrific tool to learn. If you like Eclipse, install the Scala IDE and the Scala Worksheet. It's rough around the edges, but it's even better than the REPL.

Yes, I have been using the Scala IDE and Scala worksheet for my initial learning. As you said, it is great and more friendly than the REPL itself. It reminds me of Python Notebook in terms of being able to get good feedback and recursively edit.

Most folks find that the IntelliJ Scala plugin is the best tool rather than Eclipse.

Have you tried the Scala Worksheet for Eclipse? Pretty cool.

I see that the recently released IDEA 12 has a similar feature (but so far incomplete and undocumented according to their bug tracker).

There are a number of syntactic errors and typos in the article. For instance `sum` should be:

* def sum(x: Int, y: Int) = x + y

Why `return x * y`? That is not a sum... Also using `return` is not idiomatic scala.

* List(1, 2, 3) ::: List(4, 5, 6)

That is the more typical way to concatenate lists. Using `+` will actually fail to compile.

* list.map(i => i + 1)

to increment the list. forall checks that a predicate is true for all elements.

And so on...

Thanks, fixed the errors.

I still see under the heading 'Choose between explicit type declaration or implicit type inference' the following:

> Sum(x: Integer, u: Integer): Int = return x * y > or > Sum(x: Integer, u: Integer): = return x * y

Clearly, x * y is not the sum. And y isn't in the argument list, u is. And in both cases the return statement is unnecessary and should be omitted.

The article confuses immutability with being 'final' (both in Java and in Scala).

From the article:"In Java you can use the final keyword to differentiate variables that are not mutable. Scala has two keywords val and var to differentiate between mutable and immutable types."

If a variable is 'final' in Java, then the variable cannot be reassigned to another object once initialized. This does not at all prevent it from being used for a mutable object. For example:

  final Map<String, String> stateToCapital = new HashMap<String, String>();
  // since HashMap is a mutable type, I can add a key/value pair:
  stateToCapital.put("Indiana", "Indianapolis");

Similarly in Scala, I could make a 'final' ('val' as opposed to 'var') assignment on a mutable data type:

  val myMutableMap = collection.mutable.Map("Indiana" -> "Indianapolis")

If only the Scala compiler wasnt so slow...

That's what nailgun and zinc are for...

See what the Jetbrains guys are currently using: http://blog.jetbrains.com/scala/2012/12/28/a-new-way-to-comp...

...am I the only one who finds type inference bad, at least when "reading the code as documentation"?

Types for method and constructor parameters are always explicitly specified. Type inference generally used for local variables and method return types. This strikes a good balance between having no type info (e.g. python) and having type info for everything (java). The convention in Scala is to specify the return type of a method if the return type is complex.

In practice the type which is inferred is pretty obvious: val x = 800 vs. val x: Int = 800

It gives the freedom to put the type when it is useful for reading and to remove it when it is annoying for reading.

It is very different from others because this language assumes the developer is smart.

I think a class's public API should always specify its types (including method return types). But for local variables inside a method, the type information is often just noise.

The features described are nice, but are they nice enough to make up for Scala often using more memory than Java and being a bit slower?

One data point: https://docs.google.com/open?id=0ByTAIYFOarh0cm9aSXlzc0NWaXc

It is always about trade-offs, but you had the above with the much smaller functional language talent pool and I don't think I would want to use this are a core/shop language. If I was going to go functional, I think I'd go for Haskell GHC and get the functional lang benefits with better than Java performance.

Scala is definitely a good alt. lang for a Java shop though :)

"It is easy to notice that in Java, one might have implemented infinite number of for loops trying to do such lookups using iterators."

val list3 = list1 ::: list 2 // returns a new list of 6 elements

final list3 = new ArrayList(list1).addAll(list2);

list3.drop(2) //return a new list without first 2 elements

new ArrayList(list3.subList(2));

list3.filter(s => s > 4) //return a list with elements 5 and 6

new ArrayList(list3.subList(4));

Also the Java versions use standard convenience methods which seems preferable to language features since anyone can re-implement them, or add new ones. Plus the copy-on-mutate behaviour is optional.

This article focuses ONLY on minor syntactic differences. These are nice, but the things that will make all the difference are bigger issues, like the ability to easily write functional code (good) or incomprehensible type inference error messages (bad).

Reply on news.ycombinator.com