[lukedegruchy]

I disagree. I think Scala suffers from Perlisms like being too succinct and more than one way of doing things (ex omitting dots and parens to invoke a method). There are newer alternative JVM languages that are more consistent and preferable to Java, so I disagree with your argument that those of us that prefer not to use Scala are Luddites.

[eropple]

Meh? B&D languages bother me, for the most part--your criticisms would apply to C++, which I'm also happy to use. I mean, omitting dots and parens is primarily of value in flexible DSLs. Otherwise? Talk like adults and figure out the idioms you wish you adopt. Does one of your developers do something that you don't like. Then y'all talk it out. Not hard.

Consistency is important, but effectiveness is, by my lights, moreso. Java's biggest problem isn't the language, which is sad, but its type system, and I've yet to see a newer alternative JVM language with a type system remotely worth discussing. (Which isn't to say it doesn't exist, but it sure isn't Ceylon or Kotlin.)

[lukedegruchy]

What's wrong with Ceylon's type system? I find it incredibly well designed. For instance, the Ceylon compiler won't allow you to assign null to a non-optional variable. Also, there is a bottom type, which makes controvariance far more manageable. I could go on.

[jbooth]

"Talking it out" isn't an option when you're dealing with code that's older than last week, let alone code written by developers that you've never met - you can't talk it out retroactively. That's a huge part of the 'which effective subset' argument against C++ and Scala. The argument is that, in the long term, 'simplicity and consistency', even if clunky at times, are way more effective than 'expressiveness'.

[lmm]

> "Talking it out" isn't an option when you're dealing with code that's older than last week, let alone code written by developers that you've never met - you can't talk it out retroactively.

Omitting dots and parens is so superficial that you could change the code purely mechanically to your preferred style. Just like running an autoformatter on someone's code before reading it because you don't like their indentation style.

[lmm]

Omitting dots and parens is superficial; it's no more a Perlism than allowing whitespace or extra parens (which almost all languages do).

Could you give an example of what you consider a more consistent JVM language? I find Scala is often more consistent, because it uses a small number of powerful features. E.g. Kotlin doesn't have Scala's implicits - so it instead has a bunch of different special-case features (e.g. extension methods) to replicate their use cases.

[lukedegruchy]

I disagree about the dots and parents. It impacts readability because the person reading the code, which most developers do 90% to 95%. If different developers on the team use different styles, it makes reasoning about the cod that much more difficult.

I can't say I've followed Kotlin all that closely, but it struck me as a less dense language. Ceylon is a language I've followed closely, and I find it very consistent.

[lmm]

Ceylon is very nice, and probably is more consistent; first-class union types are a really good idea. Its Java interop story isn't quite as good as Scala's (without existential types, you can't express many Java generic methods - and try calling a Java generic method with a Ceylon tuple), and I don't think I could live without higher-kinded types and some equivalent to for/yield (do notation). But it does feel pretty elegant so far; we'll see if it can keep it up through years of language evolution.

[lukedegruchy]

Java interop is way better with Ceylon 1.1. For example, use-site variance for generics was introduced and overloading bugs have been resolved. Ceylon 1.2 will have constructors (to support DI frameworks) and I believe Java EE integration. The Ceylon guys have been very careful about adding new features, considering the pros and cons. Strict Java interoperability would have resulted in a much less elegant language (ex public/protected/private instead of shared and allowing an escape hatch for null, as Swift and Kotlin have done).

[eropple]

Yeah, having looked at Ceylon 1.2 I withdraw the "or Ceylon" part of what I'd said above. It's a lot nicer than when I'd looked at it before. I'd still go to Scala first, but that ain't bad.