What you've described is what Scala programmers want Scala to be, or what they use; not what it really is. It seems to me that you've actually described Kotlin.

BTW, I agree that the JVM is a tremendous asset. I develop for the JVM every day and I love it.

The reality is that Kotlin ships a milestone about every 4 months; they're still on 0.6 and the 1.0 release will be a beta release, so we can expect to see Kotlin stable in what, maybe 18 months? That's a long way away when you consider that...

Java8 (arguably the bigger threat to Kotlin than Scala is) will already have launched (looks like Q2 2014 last I checked) and grabbed frustrated Java teams everywhere.

So, Scala trimming down and Java fattening up. Kotlin? A bit late to the party. Java8 will keep existing Java shops intact, and Scala already having made significant inroads into the enterprise, will continue to thrive as _the_ statically typed Java alternative.

My take at any rate, will be fun to find out how it all shakes out in the coming years.

Because then the computer knows what I'm doing, and not just me. Whenever I write a cast, I am assuming I'm smarter than my computer--so smart I never, ever need the computer to check it. This is pretty stupid, because I'm not that smart. (Neither are you.)

> What you've described is what Scala programmers want Scala to be, or what they use

This is a pretty silly line of demarcation. Scala is what people use. So is JavaScript. There's no prescriptive use case for it.

I'd like to like Kotlin, but it wasn't done enough soon enough and I now know Scala intuitively enough that there's no real reason for me to use it. It's just-different-enough from Scala to throw me, while being a step back down the continuum of expressivity. If Kotlin had come out three years ago, it might have grabbed me, but at this point it holds no value to me.

I've always wondered about this argument. Haven't modern Java IDEs more or less automated away the boilerplate?

Using a tool like IntelliJ IDEA or even Eclipse for that matter, I'm really hard pressed to find something that could be autocompleted or generated that hasn't been. They even have views that collapse or otherwise hide away unnecessary verbosity.

Sure, you have a little more code to look at. But frankly, sometimes this can improve readability vis-a-vis excessively concise and overloaded syntax. It can make it easier to grok someone else's code.

I'm not saying there's no difference, just that it's a little odd that this is the NUMBER ONE advantage always cited for Scala vs. Java. Am I crazy?

They may automate some of the typing of boilerplate, but that just means the language you are entering isn't the same language you are reading, which is another problem.

The boilerplate is still there, and its still in the way.

> Sure, you have a little more code to look at. But frankly, sometimes this can improve readability vis-a-vis excessively concise and overloaded syntax.

IME, its more often the case that the boilerplate that Java requires makes code hard to read than that the conciseness that Scala permits (but generally does not require) makes it hard to read. And, since the concise options in Scala are generally options, a programmer who is aware of a case where being maximally concise impedes clarity can opt for a more explicit expression, whereas the Java-required boilerplate isn't optional, so even if the programmer is aware of it getting in the way of readability, they can't eliminate it.

I don't think that's true. Your phone has an autocomplete function for text input. You're still typing and reading the same language.

> a programmer who is aware of a case where being maximally concise impedes clarity can opt for a more explicit expression

By the same token, readers are held hostage by the poor decisions of overly concise Scala programmers. This is not theory, it really happens a nontrivial amount of time. You can blame the programmer if you want, but it's a point for Java readability.

Now you're simply overstating the case. Why?

This is a perfect example of my claim. There is this emotional component to the "Java boilerplate" argument that belies rationality. There is some other unstated reason advocates want Scala and are fitting the argument to that conclusion. Because it's cool? Big fish small pond syndrome?

  List<String> list = getListofStrings();
  List<String> capitalized = new ArrayList<String>();
  for(String st : list)
    if(Character.isUpperCase(st.charAt(0)))
      capitalized.add(st);

  val list = getListOfStrings
  val capitalized = list.filter(_.head.isUpper)

Second, a lot of the concision comes from omitting type declarations. I will argue this decreases the readability of the Scala example.

What kind of data structure does getListOfStrings return? With Java you know with complete certainty that it returns a List of String (and only String). With Scala you have to infer it from the method name and hope it's honest. Likewise with the filter function. Whatever your opinion is of explicit type declarations, they are not mere "boilerplate".

There are certainly other savings in your Scala example apart from types, like the filter lambda function. I'm just a bit incredulous that Scala advocates genuinely think this saves them large quantities of time over the course of a project vs. an IDE-assisted Java version. I mean, how much longer would it take you to write or grok that Java for loop? Seconds? How much longer to do it 100X in a project? Minutes?

There has got to be a deeper underlying emotional reason why people advocate Scala -- which is not to invalidate that reason at all. It's important to feel love for your tools. But be honest about it. It's not about saving hundreds of hours of time writing boilerplate.

when your mental/visual pattern machinery have been trained for 15+ years on the latter case? :)

It can transform for loops into linq statements (and vice versa) quite easily

And even the best IDEs can't help with much of what I've seen in large Java apps.

What is the proposed change, exactly? Do you have more information?

and the Twitter thread is here: https://twitter.com/odersky/status/382833314286956544

As someone who switched from scala to haskell, I find your mis-characterization rather amusing. The haskell ecosystem is far better than the scala ecosystem. The ecosystem is more than just libraries, and using java libraries in scala is giving up much of the benefits of scala. And scala interoperability has been one of the biggest things everyone complained about, probably not a good choice to criticize other languages for.

>Following that, perhaps for 2.12, Odersky recently proposed on Twitter a revision of the type system that had FP devotees up in arms since the proposed change removes some of the complexity that makes libraries like Scalaz possible.

"Don't worry, they are going to make it 1% simpler by giving up 25% of its expressiveness!" is a pretty terrible sales pitch.

What does that even mean? There's full Java interop, so I just add a dependency on JodaTime and voila, a kick ass library at my finger tips. That is by and large the ecosystem, a massive wealth of functionality, followed by community and tooling (which in Scala is admittedly a weak point).

With Haskell you have Haskell's ecosystem, nothing less, nothing more. So if a Haskeller hasn't developed, for example, a PDF generator to produce client invoices, you're SOL short of writing it yourself.

Scala has a strong, somewhat modernish type system. That protects against many bugs. Java does not. Java libraries can contain code that breaks assertions the scala language makes.

>With Haskell you have Haskell's ecosystem, nothing less, nothing more

Sure. But haskell's ecosystem is miles ahead of scala's. So it is less common to need to resort to using a C lib than it is to have to resort to using a java lib from scala. Yes, tooling and documentation are a huge part of the ecosystem, and scala is pretty awful in that regard.