If you try to line up parameters, for example, a different tab size will screw up the formatting. By using TABs you force everyone to have the same tab size unless you never, never try to do any fancy formatting

See this example:

void funct(T1 par1,
TAB TAB T2 par2,
TAB TAB T3 par3) {
TAB body; TAB TAB TAB // coment
}

The code above will look fine in any editor if indented with spaces. If you indent it with tabs, you will have to use TABs with size 4 to make T1 and T2 line up (and if the function name changes, you will have to mix tabs and spaces). Same thing with the inline “//coment”, if you want to line it up with other comments, tabs won’t do.

Yes, I’m somewhat upset… and this is kind of ranting, but really… please… for the love of everything sane and beautiful, just use tabs.

Consider this code

args.foreach { arg =>
greeting += (arg + ” “)
}

instead of

foreach (String arg : args) {
greeting += arg + ” “;
}

isn’t the structure of the code more difficult to recognize when the foreach is not at the beginning of the line? The 2-space indentation also adds to this feeling. The structure can’t be seen so quickly. And it gets even worse with the single-instruction closure:

args.foreach(arg => greeting += (arg + ” “))

It’s much more difficult to see the loop in a function containing this line. But I think that’s very important since the number of (possibly nested) for loops reflects more or less directly the runtime performance of your code.

Also I’m struggling with the fact, that things can be done in so much different ways. For example, you say one can still use the semicolons. Then everybody can do what he wants in this regard. I think it’s highly desirable to have a language where things can only be done in one way because that forces everyone to do it exactly the same way. This reduces the sum of different syntax tricks I have to master in order to understand the language. It’s also better if in a project team the source code always looks exactly the same way regardless of who has written it.

So, while I think there are really refreshing concepts here, I wouldn’t be so sure if I would want to change to Scala only because it’s supposed to be a “better” Java. There are also some studies that show, that programmers spent the fewest time with typing in code. So you can’t really save so much time with fewer syntax. But you will loose a lot of time if the syntax is harder to understand …

Until the tools are there, Scala will have a tough time kicking Java out if the #1 spot for most deployed language in the world. I’d expect that unless Scala is acquired by SpringSource, its probably going to end up like Ruby. A quick climax and then a fast fall.

How clever is this? From a concise language I would expect a minimal reduction to avoid comments about so many confusing syntax alternatives found here.

val argsString = args.map(s => “‘” + s + “‘”).mkString(“, “)
println(“Arguments: ” + argsString)

It might be cryptic on first glance, to someone unfamiliar with Scala, but I think it’s really worth it to understand how to do it this way, and why it’s better in general.

Cheers!

> I prefer the term “closure”

Closures are not the same as anonymous functions (lambdas). I agree it’s a nicer term, and I prefer to use it too, because it sounds more erudite, but I think it’s important to pick words according to what they actually mean, rather than what we’d like them to mean.

Also, “antecede” is not an antonym of “precede”, it’s a synonym.

Played with Groovy a bit, but this seems to be the future. My initial problem with Scala was the Eclipse Plug in, but that has now been sorted.

Cheers for sharing

The plugin is here:

http://www.jetbrains.net/confluence/display/SCA/Scala+Plugin+for+IntelliJ+IDEA

List of features:

http://www.jetbrains.net/confluence/display/SCA/Scala+Plugin+0.2+features