I just came across a language that I never heard of before: Fan.

Here is a quick snippet:

// find files less than one day old
files := dir.list.findAll |File f->Bool|
{
return DateTime.now - f.modified < 1day
}
// print the filenames to stdout
files.each |File f|
{
echo("$f.modified.toLocale:  $f.name")
}

After a few hours surveying the language, I have to say that Fan seems to get a lot of things right. Here is a short list of its features:

• Reuses the C# syntax for properties.
• Optional static typing and type inference. Use "." to enable static typing, "->" for dynamic typing. Non-existent methods are sent to a catch-all "trap" method, which is the equivalent of Ruby's method_missing. It is also possible to create types at runtime, which Fan calls -- a bit confusingly albeit accurately -- "dynamic types".
• Currying with the & operator.
• Closures. I also like the fact that closures and Fun functions can be transparently converted to methods (think "delegates") via currying. See below for an example.
• override and virtual keywords (as opposed to Java, Fan methods are not virtual by default).
• Untyped annotations (called Facets). Facets are pairs of (key, value) and they can be introspected at run time. The system reserves a few facet names for itself, such as @transient or @serializable.
• Immutability (classes can be created const and objects can be made immutable).
• Mix-ins (represented by interfaces that can have implementation). Fan mix-ins can have properties, although these need to be abstract (an approach that I find less restrictive than Scala's).
• Runs on both the JVM and .Net (wow!).
• Uses := for assignment. I remember liking this symbol a lot when I was programming in Pascal and Modula 2, but I haven't used it in about twenty years, so it might be a bit disconcerting at first.
• Interesting approach to modularity leveraging REST URI's to denote namespaces. This area is still in development, but here is a quote that summarizes Fan's approach:
  

  Java and .NET to a lesser degree separate the concepts of namespace and deployment. For example in Java packages are used to organize code into a namespace, but JAR files are used to organize code for deployment. The problem is there isn't any correspondence between these concepts. This only exacerbates classpath hell - you have a missing class, but the class name doesn't give you a clue as to what JAR file the class might live in.

• "once" methods (a feature I can only remember ever seeing in Eiffel).
• Constructor declarations need to be prefixed with the keyword "new" but can take any arbitrary name, although the prefix "make" is commonly used. Constructing an object is done by invoking that constructor as a static method on the type (like Ruby), which I find intuitive.
• Good-looking web site with extended documentation.

Here are a few code samples illustrating the main feature of Fan.

Constructor

class Point
{
new make(Int x, Int y) { this.x = x; this.y = y; }
Int x
Int y
}
// make a point
pt := Point.make(30, 40)

Properties

class Person
{
Str name
Int age { set { checkAge(val); @age = val } }
}

In the code above, @age is used to refer to the actual field and not the property.

Facet

@version=Version("1.2")
@todo=["fix it", "really fix it"]
class Account
{
}

You can pass methods when closures are expected. For example, Thread.make expects a closure that takes a Thread in parameters and returns an Obj:

new make(Str name := null, |Thread -> Obj| run := null)

You don't need to create an object to invoke that method:

static Void readerRun(Thread t) {
// ...
}
reader := Thread.make("reader", &readerRun).start

Here are some of my pet peeves about Fan:

• The typing syntax. I would have preferred "f: File->Bool" instead of "File f->Bool" so that formal parameters and the type of the closure can be more easily told apart.

• No generics. All successful languages eventually get there, so I hope Fan will as well, but the creators seem to be hostile to the idea:

  Our philosophy is that generics are a pretty complicated solution to a fairly insignificant problem.

  I'm sure they will change their mind in due time, and in the meantime, List, Map and Func offer a limited type of genericity.

• There doesn't seem to be any IDE support. I'm not sure how old Fan is, but the documentation states that it is approaching v1.0, so I'm hoping that the Fan developers will learn from Groovy's mistakes and focus their attention on IDE support as soon as possible.

• I prefer for constructors to have a fixed name instead of one arbitrarily chosen by the developer. While class declarations make it easy to pinpoint which methods are constructors (just look for "new"), it's not as easy to tell when you are on the call site, since a constructor invocation cannot be differentiated from a static call. From that respect, I still find that Ruby's approach (Person.new) represents the best of both worlds, although I think it could be perfected even further by eliminating the duality "new"/"init" completely.
  For example, instead of:

  // Valid Fan
  class Point {
  new make(Int x, Int y) { this.x = x; this.y = y; }
  Int x
  Int y
  }
  p = Point.make(2, 3)
  

  Why not:

  // Invalid Fan
  class Point {
  new(Int x, Int y) { this.x = x; this.y = y; }
  Int x
  Int y
  }
  p = Point.new(2, 3)
  

  ? (the same remark can be made about Ruby)

Except for partial generics, Fan doesn't seem to add as many innovations as its predecessors did, which is not necessarily a bad thing. It's pretty clear that the Fan authors have a solid knowledge of multiple languages and they ported these concepts, sometimes hardly modified, into Fan. And speaking of porting, I am thoroughly impressed by the fact that Fan works on both the JVM and .Net.

Overall, it looks like Fan is being driven by motivations that are very similar to what started Groovy: pick the best features of the current popular languages and try to blend them into a coherent set. I find myself particularly fond of Fan because I happen to agree with a lot of the choices that the designers made, which is exactly how I felt about Groovy in the beginning. Of course, Fan has the advantage of hindsight and it borrows from a few additional languages than Groovy did (namely, C#, Scala and a bit of Erlang), so I find the result quite promising.

Here is a very interesting demo of the new HTC Diamond phone’s sensors. In this game, called Teeter, you move a marble by tilting the phone and you need to avoid the holes along the way.

It’s a very impressive demo, but as opposed to the author of the article, I really don’t think that much more can be done with this kind of technology. People are quick to point out that we could write fantastic games or develop great applications with this technology, but the fact that you need to keep the screen visible (and at a reasonable angle) as you tilt the phone severely limits the range of what you can actually do.

Recently, I have also started encountering limitations in what you can do with touches on a phone screen. Touch interaction allows for great-looking devices that are not encumbered by ugly-looking keyboards, but it also takes a toll on user interaction in two ways:

• The widgets need to be much bigger so that fingers can accurately tap them, thereby limiting the amount of information that can be shown on the screen.

• When you tap on a widget, your entire finger will mask a significant portion of the screen, including the very widget you are tapping on.

This last point is particularly interesting because it impacts user interfaces in a lot of subtle ways and it actually makes touch inadequate for a large number of games, for which not seeing the entirety of the screen is simply not an option.

There is no doubt that touch and accelerometers are here to stay, but in my opinion, the most revolutionary applications that we are likely to see in phones in these coming years will come from features that don’t require any user interaction, such as camera, compass and GPS.