View of Scala from Java

http://thepolygl0t.blogspot.com/2013/01/a-view-of-scala-from-java.html

by tathagatadg • 14 years ago

27 23 14 years ago

thepolygl0t.blogspot.com

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

grdvnl4• 14 years ago

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

bertzzie• 14 years ago

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

BonoboBoner• 14 years ago

If only the Scala compiler wasnt so slow...

thebluesky3• 14 years ago

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

jlh2762• 14 years ago

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

grdvnl4• 14 years ago

Thanks, fixed the errors.

polymatter• 14 years ago

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.

nnq• 14 years ago

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

thebluesky3• 14 years ago

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

webreac• 14 years ago

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.

lmm• 14 years ago

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.

mcherm• 14 years ago

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

ceedubs• 14 years ago

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

voidlogic• 14 years ago

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 :)

renwick• 14 years ago

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

View of Scala from Java

Related Stories