Share

From this page you can share Not a Fan of Scala? An Evolutionary Approach to a social bookmarking site or email a link to the page.
Social WebE-mail
Enter multiple addresses on separate lines or separate them with commas.
Not a Fan of Scala? An Evolutionary Approach
(Your Name) has forwarded a page to you from Ajaxonomy
(Your Name) thought you would like to see this page from the Ajaxonomy web site.

Not a Fan of Scala? An Evolutionary Approach

Tagged:  

The Scala programming language, heralded by many of the Java cognoscenti as the language to replace Java, has garnered well-deserved praise as a sophisticated and capable language. But to many who have grown up in the tradition of C-C++-Java, Scala's hybrid imperative-functional design may be just too alien to their sensibilities. Given the history of popular programming languages, this is not a surprise. It was, after all, not Smalltalk but C++ that introduced OOP to the masses; and Java in no small way gained popularity by fixing many of the pains involved with programming in C++ while still retaining the same general style of syntax.

Now along comes a language called Fan, which takes a more evolutionary (as opposed to revolutionary) approach to language design, incorporating concepts from Java, C#, Ruby, and other languages (e.g. Erlang) into a fluid style that would be very comfortable for a programmer well-versed in any of these languages.

Here is a short list of interesting features in the Fan language:

  • Compiles to either JVM or .NET bytecode.
  • A Ruby-like syntax for using closures (with the method signature expression enclosed between two "|"). Like C#, functions are first-class citizens in Fan (represented by the Func class).
  • Fan has no concept of interface classes, but rather uses mixins for multiple inheritance. Mixins are like abstract classes in Java (i.e., they can declare concrete method implementations), but can contain no state (i.e., fields). This addresses one of the weaknesses of interfaces in Java (and C#), namely that it is very difficult to introduce new methods into the interface without breaking all of the existing implementations of this interface; this is a problem in widely-used public-facing APIs such as the Collections API in Java.
  • All threads in Fan have the ability to pass messages to other threads, i.e they use the Actor model for concurrency popularized by Erlang.
  • Fan is, generally speaking, a strongly and statically typed language. But Fan supports a special syntax for using dynamic typing with a "dynamic call operator", the "->". This operator allows you to call a method on a class without the compiler enforcing type checking. In other words, you don't have to cast a type just to call a method.
  • A unified namespace and deployment structure. The deployment unit in Fan is called the "pod". The first part of a namespace is always the deployment unit (pod), so identifying a missing class becomes much easier than the "jar hell" of Java (though arguably Maven makes this much easier).
  • Fan supports a "literal syntax" for programming with lists, maps, etc. that makes working with these common elements much easier.

More thorough documentation on the language is available here. In general, Fan does not introduce any world shaking concepts--certainly all of its elements are present in some form or another in other programming languages--but is distinguished by the fact that it makes very smart decisions about which features to use, combining them in a style that is both fluid and familiar to the average programmer.