What Rails did for Ruby had been at least started by the Lift Web Framework for Scala! It is Version 0.1.0 but it looks promising. Their website runs on liftweb, too - in fact they are running the example you can download and deploy on your Appserver. Behind liftweb are David Pollak and (among others) Burak Emir how contributed the XML-handling to Scala.

I had a brief look at the code; liftweb is based on Scala-Actors (the Scala implementation of the famous programming model made widely known by Erlang) which promises that it will be quite scalable.

This gave my Scala engagement another boost. And a setback. I installed the latest plugin for Eclipse (it is and had been always quite shaky) - good news: It comes with the compiler/runtime, bad news: It is the 2.3.4 version (current version is 2.4.0) and the preferences page has a bug that prevents you to set the path of your Scala installation.

Scala is for me quite interesting as it also allows to compile to .NET IL-code. This gives Scala a quite unique position as a language that allows you to write code for the two platforms once and run it on both of them.

Another feature that is nice is actually the only pain-point I have yet identified: Scala requires only Java 1.4 - good for people which are still stuck with that version, but bad for the rest of us:

Using implicit functions you can write

val list:List[Any] = MyJavaClass.getCollectionOfString()

But even if getCollectionOfString returns Collection it is impossible to write a conversion that allows to give list the type List[String]. Reason is that the implicit functions for the conversion would need a type parameter and Scala rejects a declaration

implicit def JavaCollection2List[T](coll : java.util.Collection[T]) : List[T] ={…

because “java.util.Collection does not take type parameters”.

If you think this is not an issue: Try dealing with a Map,List>… all this casting gets pretty ugly as casts are rare in proper Scala code, consequentely you get punished for doing it anyway by nice syntax obj.asInstanceOf[String]…

There is many said about generics how bad and complex they are. The existence of the brillant Generics FAQ is used against generics. The point many people miss: Generics are always complicated and there will be always corner cases. Java Generics have at least the thing for it that it is possible to descibe this in a way non CS-PhDs can understand it. If some say they can’t, perhaps they are in the wrong business or belong to these people that stop reading after the third line if the text doesn’t say what they are already convinced of.

Someting really incovenient is the type erasure. In short type erasure prevents you from writing

T copy(T t) { return new T(t)}; // T is not known at runtime, so its ctor is neither

This is not the only example where it gets into your, but the one that I found the most interesting eventually.

For Java 7 lots of things get proposed, and reifiable generics are getting also on the list, some even propose annotations to add this. I had been bitten by type erasure more than once and despite of that I prefer to keep it like it is.

Point is that non-type erasure is not so simple as it seems, for example when passing an heteorogeneous array as vargrs things get messy as the type is not a class anymore but a composition of interfaces. Although I think that we are missing interface composition, passing such structures around at runtime won’t be funny or free.

And perhaps also useless.

What I think we would see is scary introspection code on the type, because this will be possible and simpler in most of the cases (alternative will be creation of a new generic type). The only point valid is the new T. This is something you cannot imitate without reified type. So the question of type erasure is not the point, the point is how to do virtual ctors.

Something missing from generics that is rarely mentioned is the lack of support for native types. Although I see them as the deadly sin of the Java programming language there are there and there are indeed the reason why we deal so much with array (which causes the problem above). As they are there support for them would cut some corners; implementing it is by far trivial thanks to the second C-heritage type coercion amoung the numeric types.

Bob Lee made the remark that the use of array in varargs would be better replaced by List. Nice try - but as List is not part of the language not really an option. Or List becomes part of the language … hello Lisp