In my experience, jumping straight to writing code results, if anything, in a huge mess. For anything more complex than proof of concept programs for specific language or library features, this quickly becomes unmanageable.
I have obtained much better results by first developing a nice logical model (not necessarily 100% formal, but at least rigorous enough to be amenable to formalization), and only then picking a programming language into which the model can be translated with a minimum amount of effort. In this regard, a good language is one that allows translating as many logical constraints as possible into statically verifiable constructs (such as types). The nice thing about static verification is that errors in the translation can be detected as soon as you make them. Heck, in some cases, even errors in the original conceptual design can be detected.
Scala is a better language than Java because its type system is so much more powerful. Using Scala as if it were Java nullifies this advantage, and leaves you only with the inconvenience of having to learn a new syntax. So, what is the point?
The new syntax is similar but nicer. If you just use Scala as "java with type inference, no semicolons, and a shorter form of final" it's already an improvement over java.
Scala only has very limited inference. In fact, so limited that, based on this criterion alone, I would take Java's powerful refactoring tools over Scala's inference anytime. (One of my main uses of inference is enabling fearless aggressive refactoring.)
But let's say Scala had a type system amenable to global inference with a nice principal types property. This does not prevent you from having to annotate types when, at a module boundary, you want a term to have a more specialized type than its principal type. (Within module boundaries, it is admittedly no big deal to have terms whose types are more generic than their use would warrant.)
> "no semicolons, and a shorter form of final"
You cannot tell me with a straight face that cosmetic syntactic changes are a particularly compelling reason to switch languages. (Well, you can, but then you cannot convince me you are a pragmatic engineer.)
> "it's already an improvement over java."
Yes, but, without taking advantage of Scala's powerful type system, is the improvement over Java substantial enough to justify the investment in learning a new language?
>Yes, but, without taking advantage of Scala's powerful type system, is the improvement over Java substantial enough to justify the investment in learning a new language?
What investment? You just write the same code that you were writing in Java. You can do that on day 1 (at least, assuming your IDE and build system have scala support already) - on day 1 your productivity is just as high (or slightly higher, because of the cosmetic syntax improvements) as it was in Java. On day 2 your productivity is higher, as you pick up a little bit of scala. So there's no initial cost - just an improvement. I know this is possible because I have done it.
I have obtained much better results by first developing a nice logical model (not necessarily 100% formal, but at least rigorous enough to be amenable to formalization), and only then picking a programming language into which the model can be translated with a minimum amount of effort. In this regard, a good language is one that allows translating as many logical constraints as possible into statically verifiable constructs (such as types). The nice thing about static verification is that errors in the translation can be detected as soon as you make them. Heck, in some cases, even errors in the original conceptual design can be detected.
Scala is a better language than Java because its type system is so much more powerful. Using Scala as if it were Java nullifies this advantage, and leaves you only with the inconvenience of having to learn a new syntax. So, what is the point?