• bearophile (50/51) Jan 19 2009 Fan is a cute language for virtual machines, that can be used like Boo b...

bearophile <bearophileHUGS lycos.com> writes:

Fan is a cute language for virtual machines, that can be used like Boo but has
a Java-like syntax:
http://www.fandev.org/doc/docIntro/StartHere.html

It has both static and dynamic typing, and it's generally designed to be handy,
and not dumb as Java, see for example the list type:
http://www.fandev.org/doc/docCookbook/Lists.html

Its type system is simpler than Scala one. It feels and looks much simpler,
almost like a Java-Python cross with some extra nice things added.

This page shows several interesting features:
http://www.fandev.org/doc/docIntro/Tour.html

---------------

Like Fields:

class Person {
  Str name
  Int age
}

Equivalent to the Java code:

public class Person {
  public String name() { return name; }
  public void name(String x) { name = x; }

  public int age() { return age; }
  public void age(int x) { age = x; }

  private String name;
  private int age;
}

In Fan, fields are always accessed via an auto-generated getter or setter which
you can override:

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

---------------

See also mixins.

Dynamic typing is used with -> instead of .

It has a built-in serialization syntax.

---------------

Nullable Types

Types may be nullable or non-nullable. A non-nullable type is guaranteed to
never store the null value. Nullable types are indicated with a trailing "?".
This means non-nullable is the default unless otherwise specified:

Str   // never stores null
Str?  // might store null

---------------

This other page shows other nice things:
http://www.fandev.org/doc/docIntro/WhyFan.html

Portability:

We built Fan from the ground up to tackle portability between these VMs. Fan's
source language compiles into fcode - a bytecode representation that can be
translated into both Java bytecode and IL easily. This translation is typically
done at runtime, which enables you to deploy Fan modules as a single file and
have them run on either VM.<

---------------

Deployment and pods:

Everything in Fan is designed around modular units called pods. Pods are the
unit of versioning and deployment. They are combined together using clear
dependencies. Like Java they are just ZIP files which can be easily examined.

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.

This whole notion of type namespaces versus deployment namespaces does offer
flexibility, but also seems like unnecessary complexity. Fan takes a simple
approach to managing the namespace using a fixed three level hierarchy
"pod::type.slot". The first level of the namespace is always the pod name which
also happens to be the unit of deployment and versioning. This consistency
becomes important when building large systems through the assembly of pods and
their types. For example, given a serialized type "acme::Foo", it is easy to
figure out what pod you need.

---------------

So Fan avoids lot of the complexity (and power) of Scala, and being mostly
statically typed (integers, bools, etc are value/primitive types for speed) may
have a decent performance. Overall it's not revolutionary, and I don't think it
will become much common, but looks cute.

I think it can show several *simple* to use and understand things that are
possible in a static language too (like handy array/dictionary methods,
nullable types, fields, serialization syntax), and are now almost expected in a
modern handy language.

Bye,
bearophile