My first JavaFX script

I just wrote my first JavaFX script. This script is actually a little benchmark I run when first looking at a new language. Is it rigorous and scientific ? Not at all. It is a very modest benchmark that gives me a feel for the language speed. It includes a bunch of operations typical of the kind of code that I write (string manipulations, collection manipulations, etc...). The code is not optimized to any degree and might actually run faster (or slower) if I was to use more idiomatic style. I also use a number of Java class. I think this is needed because this is also representative of what actual code will look like.
So what is the result ? Turns out that in this benchmark JavaFX is only 2 times slower than Java (511 milliseconds in one tests compared to 272 using Java). If you compare that to other JVM languages that is actually quite good. Groovy for example runs this particular benchmark in about 2600 millis (about 5 times slower than JavaFX). Of course JavaFX is a statically typed language so I was hoping I would get that kind of performance. I suspect that this will improve with subsequent versions. Scala for example runs the benchmark in about the same time as Java.
Of course speed is not the only criteria for language selection. Groovy for example being a dynamic language has a lot of characteristics that make it really appealing. However, in my case for the kind of applications I work on I cannot run 10 times slower than Java. If I can write only a small portion of an application using a language then this language becomes much less interesting. With the kind of speed that JavaFX is giving me I know I can write most of my code using it. That makes it really appealing. Now if JavaFX graphic rendering can get fast enough and with its already compeling UI capability it becomes a clear winner in my book.

FInally a decent Groovy and Scala IDE

Yesterday I installed InterlliJ Community edition on my Linux system at home. I have not completed my evaluation but I must say that what I have seen so far looks good.
Groovy support is available "out of the box" while Scala support can be added by downloading a plug-in. I have been reading about both languages and I even started writing little scripts at work in Groovy (utilities to extract data from text files and such). However I must say that the lack of a good IDE was quite a hindrance. As a Java programmer I expect a lot from my IDE being used to programs like Eclipse and Netbeans. Some of the productivity gains from those new languages are not so impressive when one is used to working with a good IDE. Take for example the Groovy (or Scala) "def" keyword. This is often presented as one of the advantages of Groovy over Java. You can replace:

  StringBuilder myString =  new StringBuilder();

with:

  def myString =  new StringBuilder()

The problem is that in Eclipse for example when I enter the first expression I type the following:

  myString =  new StringBuilder();

Then I just press +F1 and select "Create local variable" and the IDE adds the missing type at the beginning of the line.
Another example is the Groovy @Delegate annotation that generates delegate methods for a given member. Again in Eclipse I just right click the member and select "Generate delegate methods" from the Source menu.
Of course, in this category both Groovy and Scala offer much more gains then what an IDE like Eclipse can offer. However, those gains have to be weighted against the loss of other IDE functionality. As a Java programmer and Eclipse user I expect a good browser for my language. A browser is an essential part of a good OOP environment. This is so true that Smalltalk development kits have always included a browser. It is somewhat painful to apply good OOP principles if you don't have a browser (good OO programming tends to result in more numerous small classes).
The other must of course is code completion. The large number of core classes and API makes this absolutely essential.
I think a good open source environment like IntelliJ will contribute to the adoption of both Groovy and Scala.

Avoid having your Scala code turning into APL

With the rise of languages that support operator overloading like Ruby, Groovy, Scala and C# one is justified to wonder if libraries will become loaded with unreadable APL like code.
I have already seen signs of the potential chaos that could come from the abuse of operator overloading. In the Scala actor library tutorial for example I have seen the following:

producer ! Next

I was initially unable to guess the meaning of this.

The following example is from a Ruby library:

(aobject / 'a string')

In this case because I watched the full presentation I know that the slash is actually an alias for a search method.
The speaker in the presentation was calling this cool. I call it stupid. It is the archetypal example of a bad use of operator overloading. The presenter himself said he was puzzled and could not understand what the code was doing at first. Definitely not cool.
Since I'm looking at switching to Scala as a main language I thought I needed to think about what kind of rule I would put into our code convention document under the section
Operator Overloading. I thought I would share this with others to get inputs and hopefully constructive comments.

For me, the best applications of operator overloading makes the code easier to understand.
Here are some example of this:

Mathematical operations (+, -, *, /)

This is the best application for operator overloading and as long as you don't
start doing stupid things like using operators in a way that conflicts with established
conventions you should be OK.

Logical operations (&. |, ||, ..)

This should be used on boolean values. One acceptable extension of this is to
use them in cases where we have implicit conversion to boolean. They don't really look like their textbook equivalent but they have been in use long enough in enough languages to be used safely.

Comparisons (>, <, ..)

Use those on any set of ordered elements. The meaning should be obvious. For example:

myWeight > aWeight

Beware of things like:

myDog > otherDog

where we don't exactly know how things are being compared.

Operations that are metaphorically related to a mathematical or logical equivalent

Using the + when you want to add a string to another for example.

Operators used as part of method names

Of course this is not operator overloading but since it is another use of operators that can lead to abuse and unreadable code I include it here. In those language that allow this, using ? as a suffix for queries for example is OK. The meaning is clear and makes the query stand out. In this category I think that % and $ could be used if allowed by the language. The only other case that I can think of is the exclamation point as a warning that a method call might have side effects. This last one is not as obvious and is at the limit of what is acceptable for me.

Operators that are already used in the core libraries of a language

If those operators have been around long enough and it is too late to remove them from the standard library then we have no choice but to use them.

All other uses of operator overloading is suspicious. The worst offenders of course are operators used as meaningless abbreviations for method names.

In some cases you will have to watch for compiler quirks and language peculiarities. WIth C# for example when you define the ++ operator on a class it has the same semantic when used as a prefix (pre increment) or
suffix (post increment). In both cases this works like a pre increment operation. This is a bug factory.
In this case I think the compiler should give an error when ++ is used as a post increment operation because it will not have the expected result. You get the same thing with the -- operator.