[codelion]

The list of features were meant to just illustrate that Scala is not some programming fad, it is strictly more expressive than Java and based on solid programming language principles.

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.

[timclark]

What can you express in Scala that you can't express in Java?

[trurl]

You do realize the futility of such questions given Turing completeness, right?

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.

[timclark]

Ok, so can I express that this method returns a collection of a single type and that collection always contains 10 items?

[trurl]

Yes, you can do that by using types indexed by a number.

See https://apocalisp.wordpress.com/2010/06/16/type-level-progra... for one take on this.

[rue]

Scala, with its “type-level programming”, crazy operator overloads and weird DSLs, is at a similar precipice as C++ was back when people started doing insane stuff with template metaprogramming (around the time of Alexandrescu's “Modern C++ Design”, 2001 maybe?).

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.

[trurl]

Yes, I guess I answered the letter of his question... but I personally wouldn't use collection types indexed by a size unless (a) I really really needed to be sure about this particular invariant (b) there was a bit more sugar and automation. In most cases the added verbosity and complexity involved would not generally be a win over just using an assertion. However, it is nice to know you have the option of static enforcement should it be desirable.

[timclark]

Shouldn't that be as simple as

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?

[fhars]

That is not a simple type. And people who still remember the original Pascal will know that you do not want to encourage people to make the size part of the collection type. And it doesn't buy you much if you cannot prove at compile time that the type you use to index into the collecton cannot overflow the collection bounds. Use Ada if you need that.

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

[soc88]

For instance you can implement a library providing Units of Measurements such that you can track the correct type through computations, e.g:

    val time: Time[Int] = 15 s
    val length: Length[Int] = 450 m
    val speed: Speed[Int] = time / length

The type annotations are of course completely optional.

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.