Although,I agree the code may not be easy to understand for everyone in the beginning but with effort and training I believe every programmer can learn enough of it to be more productive.
It is not about what can be expressed, but about how you express things. You do not need function literals in Scala, but it is sure is more concise and cleaner than anonymous classes in Java. You do not need traits in Scala, but it avoids code duplication or the overhead of wrapper classes or proxies in Java. You do not need case classes and algebraic pattern matching in Scala, but it is far more concise and less error prone than having to write the obscene amounts of boilerplate you would write in Java.
And so on.
See https://apocalisp.wordpress.com/2010/06/16/type-level-progra... for one take on this.
Unfortunately, I don't think many Scala users were around at that time or in that community, so lessons of the past might be learned the hard way again.
There are many encouraging signs too, though, toward better and simpler practices. We'll see which way things go.
func bar() [10]foo
with
var a [8]foo = bar
giving an error like
cannot use bar() (type [10]foo) as type [8]foo in assignment
Is it necessary to use Peano arithmetic to specify a simple type in a general purpose programming language?
But if you want you can also encode the sizes in binary or decimal numbers: http://apocalisp.wordpress.com/2010/06/24/type-level-program... http://www.ict.kth.se/forsyde/files/tutorial/apas03.html
val time: Time[Int] = 15 s
val length: Length[Int] = 450 m
val speed: Speed[Int] = time / length
The interesting thing is that while the implementation is quite complex, the actual user has a very simple interface to develop against.
So while you can write complex code in Scala, Scala allows you to keep the complexity in the library-side, while it would bleed into the use-site in Java (use-site generics, anyone?).
Java can't do that. In fact, they already failed twice with it.