The Google AppEngine opens up for Java. Python is a great language, but still a nice-language (compared to Java). A light-weight alternative to host Jav-applications in the cloud.

What some might have guessed is now official?: Twitter is doing its heavy lifting with Scala We don’t have to feel bad anymore to do write statically typed code:-)

Josh Bloch’s talk at Javapolis caused quite a stir in the blogosphere, why is best summed up in a blogpost and its comments: Is Java a simple, less skill demanding language or is it - better can it be - also a home for programming geeks.There are two sides and a point can be made for both of them. As java had been need it was a geeky language - admittedly fueled by the internet hype - which attracted brillant minds. Thanks to these forerunners Java is now one of the top choices for mainstream programming. The ones of these who still stick around in the Java world now look with envy on Ruby, Scala and sometimes back on Smalltalk and want to use the ideas and techniques prevalent there in Java as well. But in practice - unless you happen to work at Google - most java programmers are not of this class. Big application written in Java are written and maintained by ordinary developers, not übergeeks that think in monads.The typical Java programmer in a large enterprise is more of the type of the VB programmer, perhaps he did some C or COBOL before. These people and their thinking about programming is deeply rooted in imperative style.A point could - and personally I think it should - be made if projects really require such large staff and if it weren’t better to use more advanced stuff to build it with fewer, but appropriately skilled developers (this is the Ruby claim), but face it, the enterprise world changes too slowly to accomondate for that.More than 10 years ago we evaluated some new development environments as a replacement for Oracle Forms 3. The most interesting candidates had been Forms 4.5 (obviously), Smalltalk (I don’t remember the vendor) and Franz Allegro CLOS (Ok, this had been the one I fancied). Java had been 1.1 or so in these days and the first looks at it were disappointing, C++ had been already in use, but there had been so many problems with it that it wasn’t ever really a consideration. Eventually we went for Forms because it would give our staff the easiest transistion. The main problem with Smalltalk and CLOS had been the paradigm shift. Neither the pure OO of Smalltalk nor the functional programming in Lisp were accessible to them.I think that the same could happen to Java if all the fancy functional programming (I love it!) would get into it. There are three problems

• FP is not compatible with the mindset of the majority of enterprise programmers. Also FP programs are harder to debug - this is a problem for the prevalent trail-and-error programmer (aka debugging into existence)
• Java is not Scala, one problem of BGGA is the non-local return. This isn’t an issue in true FP languages which are expression oriented, the statement oriented Java makes it awkward to deal with it
• DSLs are in fashion and a powerful concept for layering a complex application, but they create as well new languages: You can’t hire a Lisp or C++ programmer and expect him to be immediately productive as they have to learn the DSLs of your projects first

I initially found CICE (which Bloch promotes) to come a bit short, but now I am convinced that this is the right way to change Java as it keeps the characteristics of the language and can easily integrate into larger teams in any organization.This is the curse of being a mainstream language, you most not let out you users in the cold.For the other classes of problems languages like Scala that run on the JVM could be chosen. There some research has to be done by the system architect(s) how such code can integrate with Java code and how maintenance can be organized. This isn’t a trivial problem as not everything from another JVM language integrates seemlessly with Java code (i.e. you use this code as if it was written in Java), as well the question has to be answered (in each indiviual organization) if there is enough stability in the project to support an other language throughout the life-cycle - imagine a freelancer writing some core code in a language only known by him.

After playing with implicit anon function I came up with the following useful extension to Tuple, here the new method for Tuple2 :

def apply[R] (fn : Function2[T1,T2,R]) = fn(_1,_2);

This allows the following to write very easily:

def add(a: Int, b:Int) = a+b;

val a = 1::2::3::Nil
// calling binary functions with implicit parameter of Tuple is not possible
val li246 = (a zip a){_(add)}
//nested implicit parameter - acts like an explode on Tuple
val liSquared = (a zip a){_{_*_} }

Perhaps this is best implemented on the Product traits.

What bothers me a bit is that there are now two equivalent ways of adding

(2,2)(add) and add(2,2)

Anyway, I think having a tuple and calling a function with this as parameter list is quite a common idiom. Really nice if this would also work for currying, have to check this

Why not adding this to Function2? I thought about (and tried it) and then decided otherwise:

1. It would weaken the typing, afterward it would be impossible for the compiler to tell if I was calling a Function1[Tuple2,R] or the Function2[T1,T2,R]
2. It gets very confusing for the parser, especially with the new uses of ‘_’ for impartial function evals and implicit args

Something I overlooked in the tool-docs and complained about:

–Xgenerics
Use generic Java types.

This makes the following possible:

implicit def JavaCollectionToList[T>:Null<:Object] (coll: java.util.Collection[T]) : List[T] = {

coll.iterator();

}

implicit def JavaIteratorToScalaList[T>:Null<:Object](it: java.util.Iterator[T]):List[T]={

it.hasNext match{

case true=> val head = it.next(); head :: JavaIteratorToScalaList(it);
case false=> Nil;

}

}

With these coercions a List[String] can be assigned from a java.util.Collection<String>

Open question: How will this work with .NET generics (not an issue for me at the moment and the IL-code generation seems to have a problem)

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]…

I have to say that I find the enhanced for loop useful as a chocolate teapot. I cannot count how often I refactored an iteration into a for just to redo it afterwards. Some times you want to delete via calling remove on the Iterator, sometimes you need an index, well it quickly gets ugly.

Triggered by http://kawagner.blogspot.com/2006/08/java-enhancements-i-would-like-to-see.html and learning C# I started playing with the idea to wrap Iterable to provide access to an index, remove and filtering (plus paired iteration). Well it became ugly. Java and the generics are bitchy sometimes, have a look at it, maybe you find it useful (I find it insane:-)
enumerator.zip

I don’t think it is finished and I don’t think that I will finish it ever. The reason why I put this is out was just a side-kick in Javaposse #94 where the index issue was raised with the remark that someone might implement it someday - well I already did.

The point why I stopped working on it and I really developped an aversion against this code (now you have to have a look at it) was that I started with Scala; a really nice language that has enough FP to write expressive code, enough OO to fit into today’s development mainstream and integrates into .NET and Java so that existing code can be leveraged. It is statically typed (I had too much hassle with JavaScript that I could ever consider dynamically typed code in larger scale development) that makes it strict enough to have powerful type inference. Of course it has it rough edges and limitations, but it addresses the problems I find hard to tackle with Java reasonably well - there are problems that can be solved more elegantly with Ruby, but I think I still need some more practice with Scala before I give up on them.
PS: I think the index in a loop is not needed in a pure OO-design, but where do you ever find a pure OO design