[joeburke]

1) There is a literal syntax for Java:

entries = new ArrayList<Integer>() {{ add(3); add(4); }}

But yes, certainly not as elegant as Scala. Having said that, you don't encounter literal collections very often (except maybe in tests).

6) Named parameters are pretty easy to emulate:

new Window().width(100).height(50)

although the builder pattern is safer:

Window w = new Window.Builder().width(100).height(50).build();

7) No more checked exceptions: celebrating this is like saying that your code is shorter because you no longer bother checking for errors.

8) You can only omit parenthese in Scala when there is exactly one parameter:

x.foo a <-- legal

x.foo a b <-- illegal

x.foo(a, b) <-- legal

One of the many syntactic quirks that Scala suffers from

9) Comprehensions are neat but they suffer from a crippled performance limitation that forces you to revert to imperative loops, even in optimized mode. This technical problem is serious and there is no solution in sight at the moment.

There are genuine reasons to be excited about Scala but this article makes me think that the author just discovered Scala and they haven't really dug very deep yet. When you do, you start realizing that Scala's nice features are offset by quite a few annoying limitations that will probably doom this language to a niche.

[vicaya]

> entries = new ArrayList<Integer>() {{ add(3); add(4); }}

Nah, entries = Arrays.asList(3, 4);

Scala is pretty sweet with a lot of syntactic sugars, but it still it doesn't fundamentally make writing correct code any faster, especially for Java developers who are competent with their IDEs. Until Scala's compile time and IDE support improves 10x, I see no point of using Scala for production code.

Slightly more verbose Java syntax is more than made up by the instant/incremental compilation/autocompletion/refactor that works. Even as a Java noob (I'm more experienced in C++), I can bang out correct code the first time without going through any edit/compile cycles, most of the time. IDE is the new REPL and language snobs always forget that.

[wnight]

I feel that the boilerplate code IDEs spit out on demand is far more of a liability than not. Once it's created it's your responsibility to maintain.

By focusing on the creation of the simplistic code we ignore the burden of maintaining ten lines of critical fluff for every intentional line of code.

[oconnor0]

    1) There is a literal syntax for Java:
    
    entries = new ArrayList<Integer>() {{ add(3); add(4); }}

Unfortunately if you have warnings turned on in your IDE, it will complain about the lack of a serialVersionUID on your new class. This can be worked around via the `@SupressWarnings("serial")` annotation, but that hurts overall readability & code line count. That makes this technique less of a win than it would seem.

[eweise]

1) That is probably quite slow since you're creating a new class not just a new object.

6) Sure, now let's see all the boilerplate builder code you need to need to make that work.

7) Of course you can check for exceptions, you just don't need to add a bunch of throws clauses all over your code base to get the error bubbling up to the place where you want to handle it.

8) Doesn't look like a quirk to me. Looks pretty straightforward.

[billmcneale]

> 7) Of course you can check for exceptions, you just don't need to add a bunch of throws clauses all over your code base to get the error bubbling up to the place where you want to handle it.

These clauses allow static verification. In other words, the compiler will remind you to handle the error cases.

If you fail to do this and the compiler doesn't nag you, you can bet that most developers will never bother doing it.

[viraptor]

re 1. "create a new anonymous class with one instance and run this when initialising and by the way it's all in one line" is hardly "literal syntax".

re 7. They're ok as long as they're helpful, but at the same time they prevent writing something like useful `map()`, unless it throws everything. How many times do you need to catch something and handle, even though the situation can never happen? (as in - code doesn't throw the exception, but interface says otherwise) How many broken functions, like throwing `sleep()` are there? How many times do you have to write catch / finally / catch / finally / ... when closing more than one resource reliably? And it still doesn't protect you from silly null mistakes. I believe that properly using Option and matching will prevent more errors than checked exceptions ever did... (I may be wrong of course)