No Closures in Java 7?

Currently it seems that Java 7 will not get closures. Oh dear.

According to Hamlet D'Arcy's blog Java 7 will not get closure support. That's bad news to me. It should have closures instead of the new style "for" loop added in Java 5. It should have closures in Java 6. Now it seems that it will not get closures in Java 7.

Closures are not that difficult to understand. At least when you compare them to anonymous inner classes in Java. Others disagree. I don't follow the reasoning of the closure opponents when they say that because there are stupid Java programmers out there you should limit the Language trying to prevent them from doing too much harm. That's just impossible. Incompetent programmers will shoot themselves in the foot in any language.

Fortunately there are other languages on the JVM that can use the real strength of Java: libraries, portability, and (to some extent) tooling.

iPhone bei simyo

Mein Lieblings-Mobilfunk-Reseller bietet jetzt das iPhone 3G an. Wenn es denn copy&paste hätte, 64GB Speicher und eine Java VM, dann könnte ich mich schwer zurückhalten. So ist es cool, schick, aber doch noch nicht vollständig.

Was durfte ich heute lesen? Simyo, mein Lieblings-Mobilfunk-Reseller, bietet über seinen Hardware-Partner das iPhone 3G an. Gar nicht mal so teuer (für ein iPhone):

Apple iPhone 3G 16GB Schwarz:     674,90 Euro.

Damit die Musiksammlung und ein paar Bilder und Videos darauf passte, es also als Ersatz für den iPod durchgehen könnte, müsste das iPhone schon 64GB Speicher haben. Und solche neumodischen Dinge wie Copy&Paste will Apple uns in einem Smart-Phone auch (noch) vorenthalten... Siehe zu diesem Thema auch Mikes Bemerkungen auf seinem Blog.

Außerdem bin ich immer noch der Meinung, das ein Telefon (insbesondere ein Smartphone) richtige Tasten haben sollte. Und eine Schnur :-) (nein, das nun wieder nicht: Hänn di koi Schnur?)

Pressemitteilung von simyo

Limited Visibility

When driving my car I do not like foggy weather with limited visibility. In programming languages it is the other way round: Too much detail visibility will hinder evolution of software systems. Unfortunately Java is rather weak in controlling visibility. Scala improves the situation a little bit.

Usually one uses the term "information hiding" to describe the technique of limiting the visibility of implementation details to users of software components / libraries. The Booch book [reference to be added] has nice pictures of a cat from the view of the user (grandma: purr, purr) and the implementor (gears and levers). Information hiding is very important for two reasons. First, it makes it easier to use functionality because the API is more clearly defined. Second, the provider of functionality can change implementation details more easily without fearing to break client code.

Unfortunately Java's visibility model is not that helpful in practice. You can limit visibility to the class itself (private), the same package (not subpackages or sibling packages), to more specific classes in the inheritance hierarchy (protected) or to make the class or its element world visible (public). Interface methods are always public.

It is not practical in larger Java programs to make only a facade of a larger software system or library visible and to define limited visibility between the parts of the software system. A typical scenario is that you have a structure of packages that use helper functions from a utility package. The utility functions are not useful in a context outside this package structure. But Java cannot prevent client software to use the helpers from the utility package. Only convention can try to do this and external tools can emit warnings.

Scala discards the "package friendly" or default visibility of Java and lets the programmer specify to which level of enclosing scope an element is visible, giving more control than possible in Java. Another interesting feature is that you can restrict access to the same object (as opposed to the same class).

package chb13.fooapp

package processing {
  class FooProcessing {
    def foo {
      chb13.fooapp.utils.FooHelper.onlyForFriends
    }
  }
}

package utils {
  private [fooapp] object FooHelper {
    def onlyForFriends {
        System.out.println("psst...")
    }
  }
}

Note the access from FooProcessing.foo to FooHelper.onlyForFriends. A method from chb13.bar.BarProcessing would not have access to FooHelper methods.

Note also that there is another package declaration syntax possible in Scala as used above. You can nest package declarations and define classes and objects in several packages in the same source file. My opinion on this feature is, that it is only useful for presentations and documentation like this. In real software systems where you need packages to group and organize functionality you should not have different packages in the same file. The situation may change when we move to repository based software development environments and give up files to organize source code, but I do not see this coming in the near future.

Less spectacular and known from many languages: You can rename members on import, resolving name conflicts without having to resort to fully qualified class names. It is also possible to place imports more flexibly than in Java. Rewriting part of the previous example, we could give our helper method a shorter name that is also more meaningful in the given context:

package processing {
  class FooProcessing {
    def foo {
      import chb13.fooapp.utils.FooHelper.{onlyForFriends => psst}
      psst
    }
  }
}

Conclusion

When first introduced to Java I always was a little bit put off by the fact that you could access almost every class from everywhere using fully qualified names, even without declaring access in a file preamble.

Scala in principle still has this possibility, but only if you do not use the access qualifiers to limit visibility. The combination of the access qualifiers and the more flexible syntax for imports allows the provider of some functionality to limit access to internals and therefore ensuring better maintainability and at the same time allows for the clients to access the published functionality using names of their choice.

By the way: I didn't forget the other two languages. XSLT is currently on hold until I receive a book on it (ordered, but not delivered, yet). Groovy will get a blog entry real soon now. And Scala deserves at least one negative ^H^H^H less positive entry in the near future, but its weaker points are harder to describe...

To Type Or Not To Type - Functions in Scala and Groovy

Does a static type system help even though the code becomes longer / more ugly?

Continuing my exploration of Groovy and Scala I have finished chapter 8 of "Programming in Scala", which is on functions and closures. Most of the function / closure stuff is not that surprising. Which means that this blog entry will be rather short.

Nested functions

Scala supports nested function declarations, that is named functions declared within a named function. These have access to the names in the enclosing function(s). Nested functions are useful, when you have functions that are only useful in a limited context to improve readability. In this case it is also nice that you do not have to pass parameters explicitly from the outer function to the inner one. Program layout then resembles the call hierarchy.

def testNested() {
    val context=5
    def foo(i: Int) = i + context
    assertEquals(8, foo(3))
  }

In this example (part of a JUnit test case) testNested sets up some execution context for the inner function and then evaluates it. No need to define "context" as a parameter to "foo".

Groovy does not support nested function declarations. I think Pascal had them and I missed them a lot when I started to program C about 1990. But if you really need them, you can emulate nested functions using closures in Groovy, see below.

Closures

Both Scala and Groovy allow for anonymous functions. In both languages these are not only allowed to refer to parameters but also to refer to variables in scope when the function is defined, thus creating closures. In Groovy you can always omit the parameter types. In Scala you often have to define the parameter types.

// Scala
val incr = (i: Int) => i + 1
assertEquals(2, incr(1))

// Groovy
def incr = { x -> x + 1 }
assertEquals(2, incr(1))

Note the syntactical similarity. Scala defines anonymous functions with the double arrow and calls them "function literals", Groovy uses curly braces with single arrow and calls them "closures". Here I find it easier to read the Groovy variant, partially because the type can be left out.

Both languages support shortcuts for anonymous function definitions.

Groovy allows to drop the parameter declaration and arrow when the function takes only a single parameter, which is then called "it" implicitly:

// Groovy
def incr = { it + 1 }
assertEquals(2, incr(1))

Scala allows to drop the parameter list and arrow when the parameters are only used once. Every parameter is then replaced by an underscore. The parameter types are then declared inline.

// Scala
val incr = (_: Int) + 1
val add = (_: Int) + (_: Int)
assertEquals(2, incr(1))
assertEquals(7, add(3, 4))

The Scala code looks a little bit ugly, or at least strange. What do you get for the additional typing? Better content assist in Eclipse for example. Better byte code, because the compiler has more knowledge on which methods are going to be called. Less stupid errors, when applying functions to unsupported actual arguments. On the other hand, duck typing also has its merits.

Fortunately the parameter type declarations can be omitted in Scala, too, provided that the compiler can infer the types automatically from the context.

// Scala
val someNumbers = List(-1, 0, 1, 2)
assertEquals(List(-1), someNumbers.filter(x => x < 0))
// or, because x is used only once in the function literal:
assertEquals(List(-1), someNumbers.filter(_ < 0))

This again looks very similar to equivalent Groovy code:

// Groovy
def someNumbers = [ -1, 0, 1, 2 ]
assertEquals([-1], someNumbers.findAll{it < 0})

One important difference: Scala is type checked. Assume you type + instead of < in the predicate closure above. Scala won't compile: You get "type mismatch, found: Int required: Boolean". In Groovy you get something else...

// Broken Groovy
def someNumbers = [ -1, 0, 1, 2 ]
assertEquals([-1, 1, 2], someNumbers.findAll{it + 0})
//                                           ~~~~~~     means it != 0 

I don't want to stress this to much, because there are enough other possibilities to make errors that pass type checking, but the combination of Groovy Booleans and missing static type system is generating really strange effects, here.

Partial Application of Functions

Both languages support partial application of functions, that is, creating a new function by binding only some of the function parameters, but not all. The result is a new function with the remaining unbound parameters. This sounds strange when you hear this concept for the first time, but has some interesting real-world applications. Missed that feature the day before in Java and had to define some anonymous inner classes with 90% syntax and 10% functionality instead.

The concept is called "currying" or, in German "schönfinkeln", referring to the inventors of the concept. Groovy can only bind the leftmost parameter of a function when currying, Scala supports binding arbitrary parameters.

// Groovy
def add = { a, b -> a + b }
def incr = add.curry(1)

"incr" is a closure with a single parameter that adds 1 (the parameter to "curry") to its parameter when applied. Possibly also interesting: I used the closure syntax to emulate a local function definition (see above) for "add".

// Scala
def add(a: Int, b: Int) = a + b
val incr = add(1, _: Int)// Scala

def sub(a: Int, b: Int) = a - b
val decr = sub(_: Int, 1)
assertEquals(2, decr(3))

The "incr" definition is essentially the same in Scala, slightly better readable because of syntax support for currying (the underscore denotes an unbound parameter, that is the parameter for the resulting function. The value 1 in bound to the first parameter of add, the second parameter stays unbound, resulting in a function with one parameter.

The "decr" definition above is not possible using currying in Groovy, because it binds the second parameter of "sub".

Tail recursion optimization

Scala supports tail recursion optimization, that is the transformation of a recursive function into iterative code, provided that the recursive call is the last statement in the recursive function. You might think of the callee borrowing the stack frame of the caller because the caller does not need it anymore since it is about to return.

In Scala the tail recursion optimization is only done when directly calling the same named function. Indirect recursion or calling throug curried functions will not be optimized, according to the book. This is more than Java does (nothing) but less than other languages. The reason seems to be a restriction of the JVM. I'll have to see which limitation this is in practice.

Conclusion

Just taking the visual appearance of the code, Groovy and Scala both do well for function literals / closures. I prefer the underscore as wildcard character to the magical "it" parameter and the half-hearted currying support of Groovy. On the other hand I somewhat dislike the syntax for supplying the type information for function literals in Scala.

I do not know the additional API calls for either language. The static type system and resulting IDE support makes it easier to find candidate API calls in Scala through code completion. I almost wrote that I assume Scala to be faster than Groovy thanks to the type system, but without any benchmark this is not a valid statement.

No, this was not so short. But fun to write.

Rational Numbers in Scala

I just finished another chapter in the Programming in Scala book: "Functional objects". C++ strikes back: The return of operator overloading...

Todays chapter of Programming in Scala introduced "functional objects", in other words: immutables. The task was to implement rational numbers in Scala. Here are my highlights.

Conciseness: Scala is not Cobol

The language is concise (as advertised). Not like Cobol (shudder) nor like Ada. Static types are only required in a few places, mainly as parameter types. Type inference works well, saves some typing, and (more important) removes clutter from the code. The declaration of method return type is optional, but improves readability. The return keyword is also optional which also improves readability for this class, which has only very short methods.

For example the multiplication method:

// part of class Rational
def multiply(that: Rational) =
  new Rational(this.numer * that.denom, this.denom * that.denom)

You can call that method either Java-like:

val result = new Rational(1,3).multiply(new Rational(3,5))

or with infix notation

val result = new Rational(1,3) multiply new Rational(3,5)

Operator overloading is also possible and useful for this example:

// part of class Rational
def *(that: Rational): Rational = this multiply that

Now multiplication can be written more naturally:

val result = new Rational(1,3) * new Rational(3,5)

Development Enviroment

I use the Eclipse plugin for Scala (version 2.7.2RC5). It is usable but rather limited in functionality compared to the Java development tools. There are lots of bugs: incremental compilation not properly synchronizing with the editors, incorrect diagnostics, and more. Syntax highlighting is OK, completion uses the static type information and is quite useful for novices like me.

Integration with Java

As expected you can call Java code without problems. After defining my Rational class I wondered how this would be usable from Java code. First I used javap to check the signatures of the class. Type definition and constructors look like Java, same for "conventional" methods as the "multiply" method above. The class implements ScalaObject, that means you have to include the scala jars on the classpath. Operator overloading results in methods with dollar signs in their names. Nevertheless they are callable from Java.

Actually it is fun to mix the different JVM languages in the same workspace. I implemented the class in Scala. I wrote the unit test in Scala but using the JUnit framework, because I do not know the testing framework of Scala. I did some additional tests in Groovy. Looking back at the C/C++ world this is really awesome: You can mix and match languages almost seamlessly. No core dumps, yet :-)

Conclusion

Todays lesson was another step up the Scala. No major obstacles encountered. Writing this blog entry took longer than implementing Rational with some JUnit tests. Of course I had the book as cheat sheet.

I can fully recommend "Programming in Scala" (at least from the first six chapters I have read). This book by Martin Odersky, Lex Spoon and Bill Venners is one of the best Programming Language introductions I have read. The examples are well chosen. There are few concepts that are used before described, and always with forward reference to the chapter where they will be introduced in depth. The book is available as e-Book (no DRM, but with watermark). The printed version can be pre-ordered and is due this month.

Checking a String for upper case characters

Trying three programming languages for the Java Platform at the same time shows interesting features of the different languages. Here solutions for checking a String for upper case characters in Java, Groovy, and Scala.

The Task

A simple task, taken from the Programming in Scala book: Check whether a String contains any upper case character.

Solutions

Java

// Java
String aString = "abCde";
boolean upperFound = false;
for (char c : aString.toCharArray()) {
    if (Character.isUpperCase(c)) {
        upperFound = true;
        break;
    }
}

Scala

// Scala
val aString = "abCde"
val upperFound = aString.exists(_.isUpperCase)

Shorter, clearer, no control structures. That's the way -- I like it.

Groovy

So what about Groovy. Should be very similar to the Scala solution, since Groovy has closures, too, shouldn't it?

Let's try the it the Scala way, nearly 1:1:

// Groovy (1)
def aString = "abCde"
def upperFound = aString.any{it.isUpperCase()}
// RUNTIME ERROR!

Why doesn't it work? Groovy treats aString as a sequence of Strings, not Characters, and String has no method "isUpperCase".

OK, make it more explicit:

// Groovy (2)
def aString = "abCde"
def upperFound = aString.any{(it as Character).isUpperCase()}
// RUNTIME ERROR!

This one is scary: Even though there is an explicit conversion to Character, the method isUpperCase on java.lang.Character is not chosen. Groovy complains, that there is a method isUpperCase(char) and a method isUpperCase(int).

Solution: explicitly use the static helper method on Character and convert the iteration value to Character.

// Groovy (3)
def aString = "abCde"
def upperFound = aString.any{Character.isUpperCase(it as Character)}

Conclusion

This is of course a kind of a micro-benchmark for the expressiveness of the languages. Runtime performance has not been evaluated, so no statement on that, here.

The Java solution is clearly the most verbose and least clear solution.

The Scala solution is extremely short and clear. It is also statically type checked, even though there is no explicit type information given. The compiler can infer the types starting from the string literal.

The Groovy solution is reasonable short and readable. But the solution was not straightforward. Why does the iteration on String yield String as element type? Why does the call to isUpperCase fail in Listing "Groovy (2)"?

A New Programming Language Every Year

After some abstinence I have started to learn programming languages again. And it's fun! At least one of the languages is even fun-ctional.

I used to learn a programming language a year, approximately, when I was a student. Programming can be a lot of fun, kind of an intellectual puzzle, and also a bit of an art, to find "aesthetically pleasing" ways of expressing information and algorithms.

Then comes the time when you have to do something to earn a living. Even if you have a job in the software industry that will not mean that you can always choose the prettiest programming language. Sometimes you'll get the chance of learning some new language during business hours when there is an urgent need in some project you are assigned to. But languages that are not mainstream are not in this category.

Well, what about learning in your leasure time? Not so easy when you have little children: They have their demands and after a day in the office and after having spent some time with the children you are often simply too tired to toy around with a programming language. That's why I haven't learned too many languages in the last years.

I am going to compensate this now by learning 2-3 languages in parallel... I can't remember when I did this the last time, but I'll give it a try (and hope that I won't confuse too many APIs...)

Here are the candidates

• XSLT (Does this even count as a "programming" language? At least it is a formal language, that'll do for me.)
• Groovy
  
• Scala

Why are these currently interesting for me?

XSLT just because there are many (too many!) XML documents out there, that have to be mangled in some way. This one is also most probably directly useful for my job. I intend to use it for tree data like I use the Unix stream editor for line oriented files. I do not assume that I become a real friend of XML, though...

Groovy because of the hype around it. I had already started to experiment with it about 2 years ago just before version 1.0 of Groovy. At that time I had the impression that the language is rather fragile, but this might have changed by now.

Last week I read some examples in Scala and I am really impressed by this language. I like the combination of

• integration in the Java Platform
• support for functional programming
• static type system
• concise and regular syntax.
  

I'll document some of my experiences in this blog, stay tuned.

I hate trackback spam!

Checking our web space I had to discover that we went low on space due to such a dull thing as trackback spam. Is there a way to get away without being spammed, or do we have to accept a certain level of spam?

Suddenly - in a phase when I did not publish anything on our pages - disk usage of the site went up to its limits. After logging in it became clear that my four blog entries got thousands of trackbacks.

If anyone needed some biology lessons or medicine or poker experience: The trackbacks could have provided useful information...

Fortunately trackbacks have to be acknowledged on this system and even more fortunately they can be disabled completely. Maybe at some time I will connect to a spam filter for comments / trackbacks, but probably this is not worth the trouble and I just keep them turned off.

Spam is really the plague of the internet. But when you really think about it, it may just be the other side of the coin of the well appreciated freedom and partial anonymity of the internet. How could you stop spam other than by introducing strict control and accountability of every step an individual makes in the internet - big brother would be watching us.

Probably we have to roll out our own web of trust (again) to get the most important information through the net without delay while maintaining free communication with people neither known nor recommended to us, yet, and live with lots of spam in exchange for the freedom of not having to sign every packet of information with a key assigned to us by Mr. Schäuble (our equivalent of a Secretary of Homeland Security).

Software Engineering Radio

Where some software engineering professionals and gurus share their knowledge and opinions.

On http://se-radio.net/ Markus Völter and his friends publish a very interesting audio podcast every 10 days. Very useful to broaden one's view on software engineering and software architecture.

Rechner mit Schokoladenkühlung

Wenn Obst am Arbeitsplatz nicht mehr ausreicht.

Alle, die mich kennen, wissen, dass ich am besten arbeite, wenn ich ausreichend mit Schokolade versorgt bin: Schokolade macht glücklich, anderes Essen nur dick.

Zur Zeit wird bei uns in der Firma ein Obstbüfett angeboten. Eine tolle Sache. Jetzt muss ich nur noch die Schokoladenkühlung für meinen Rechner beantragen, dann habe ich immer leckeres Schokoladenfondue.

Anscheinend hat aber noch niemand probiert, den Rechner mittels Schokolade zu kühlen: Google weiß nichts darüber.

Schokoladenfüllung ist aber auch nicht schlecht...

Martin Fowler installs OpenArchitectureWare

OpenArchitectureWare got kind of an official blessing from one of the software architecture gurus: Martin Fowler. Since he had some trouble installing it, he shares his experience on his blog.

OpenArchitectureWare, a model driven development framework integrated with the Eclipse IDE, is a very interesting software package, which allows for fast creation of specialized formal languages for a narrower range of problems.
Martin Fowler, author of several OO books, including the famous "Refactoring" book, currently follows this track of little languages and obviously has given OpenArchitectureWare a try.

"There are few things more frustrating than spending hours trying to install a piece of software and then having to delete everything and start again. Today at 9.30 I began installing openArchitectureWare, I finally had it installed (I think) at 15.30. So I thought I'd write this to help someone else do it more quickly."

Martin Fowler in InstallingOpenArchitectureWare

Mein erstes Blog, mein erster Eintrag

Irgendwann erwischt es jeden...

Nachdem ich der Blog-Seuche lange widerstanden habe, bin ich nun auch infiziert.

In diesem Blog werde ich meine Gedanken und Eindrücke zu Themen berichten, die mich aktuell bewegen. Viel Spaß beim Lesen.