That way you can delude yourself into thinking you are productive, because you are writing code immediately. However, productivity is not to be measured by the number of lines of code; rather, by 1. the amount of actual functionality implemented, 2. the elegance of the design (which saves time refactoring later on).
It's easy to forget the value of delivering functionality immediately. It's all too easy to spend a long time on an elegant design that doesn't actually serve business needs. I like to follow an agile approach where if something can't deliver value in 2 weeks then it's not worth doing (or, more likely, needs to be split into smaller pieces). That's plenty of time to learn enough Scala to be more productive than you were in Java, even though it will take months or years to learn the full language.
Learning a new programming language is an intellectual, exploratory endeavor, even if it might result in adopting that language for future programming projects. Writing software professionally is a pragmatic engineering job constrained by non-intellectual considerations such as customer expectations (and lack of knowledge thereof) and limited availability of resources (time, money, skills, etc.). Suggesting that both activities should be approached the same way is a huge mistake.
I learnt scala very effectively simply by delivering a program in it at my day job. I'm not sure about "should", but in my personal experience I've found that the best way to learn.
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.
