While most alternative languages on the JVM sport dynamic type systems, Fan and Scala both provide static typing. The two languages share other similarities, too, although their design centers are quite far apart, writes Fan language creator Brian Frank in Fan vs Scala: Different Trade-offs:
I think Scala is a really great language and I'm always on the lookout of good stuff to steal from it. But I do believe there are some key philosophical differences which I haven't really seen talked about...
A lot of it boils down to Scala's focus on its static type system versus Fan's focus on modularity and meta-programming. There is no right or wrong, just different trade-offs that will suit different tastes. There is also definitely an element of cathedral versus bazaar - Fan is trying to bake more into a unified whole (which is something I can understand might not appeal to those who favor the bazaar model of gluing lots of pieces together)...
Both Fan and Scala are trying to take software scalability to the next level, but I think we are taking different paths to get there. Scala's focus is clearly on a sophisticated type system which can catch as many errors as possible at compile time. It is also focused on mixing functional style with OO style (more so than Fan which only uses functional programming primarily as an enabler of better APIs).
Frank notes that the two languages differ in how they approach "scalable" software:
If I were to pick the absolute most important feature required for scalable software, I personally would pick a first class module system. I think this is a key difference between Fan and Scala. Scala follows more of the Java model of packages, with an unspecified module system. From what I can tell, OSGi seems to be the preferred Scala solution for modularity, but it isn't integrated tightly into the language like Fan...
Fan has a built-in module system called "pods" that is seriously baked into the core... Pods are intertwined into Fan's reflection APIs to enable all sorts of things that are impossible to do in Java (and I assume Scala) such iterate all the installed types...
Because Fan knows about all the installed modules and each module's types, we can index the installed types to provide a unified solution for reflecting things like plugins...
Fan's strong focus on metaprogramming is also a difference from Scala, according to Frank:
Fan's type system makes a trade-off towards a weaker static type system, but easier for meta-programming and reflection... This sort of meta-programming style does not lend itself to static type checking. This is why Fan will let you use Obj as a wildcard whenever a more explicit type is expected. Note the wildcard feature does not really weaken the static type system much, because it typically only kicks in with reflection APIs (which would have have required an explicit cast anyways)...
Fan uses a static type system also - but as just one tool in the toolbox. Rather much of Fan's effort has been focused on overall architecture - more of a "cathedral" approach to providing a unified solution for all the different pieces required to build, test, and deploy software (yes I know IDE solutions are lacking, but I think this will take care of itself with time). This philosophy on the entire platform and the end-to-end programming experience versus just the language is reflected in Fan's features and even this site itself...
Fan's type system is by no means as flexible as Scala's. But I do think the notion of immutability is more hardwired into Fan via the notion of const types and const fields. The notion of immutability is also baked into all the reflection and concurrency code. This makes it almost impossible to share mutable state between actors (threads). The only way to share mutable state is via the Unsafe class which exists only as an escape hatch.
Other points of comparison included in the article are serialization, Fan's built-in build engine, as well as differences in how the two languages interoperate with existing Java and .NET libraries.
What do you think of Frank's comparison of Fan and Scala?
What Im so sure is also that Fan is an easy language to learn compared to the complexity of Scala.
There is a lot of talking about the interoperability between Scala and Java or Fan and Java and Scala wins in that case but Fan Java FFI is not so bad. If you just need to reuse Java API libraries with Fan is enough but if is to integrate to a existing Java system maybe Scala is better match.
Me I liked Fan because is simple and easy language as a dynamic language but statically typed and keeps Java syntax and have the features that the modern Java is missing as closures, type inference, actors, etc.
> Any language sensible enough to kick method overloading to > the curb and then head stomp it repeatedly can't be all > bad. > > http://guidewiredevelopment.wordpress.com/2009/05/22/i-am-h > ate-method-overloading-and-so-can-you/ > > Cheers, > Carson
Sorry man, don't quite share your enthusiastic hatred of overloading - in fact I agree with x in your post. I think it makes code more readable. Even from a problem solving scenario (language aside) it makes absolute sense - E.g. Ape being Abstract, Man and Gorilla being extended classes, method slap passing in parameter hand have different effects coz Gorilla is supposedly stronger - that's plain common sense. Probably a poor example but it's getting the point across - clarifies things from a problem solving angle (well at least to me). I also disagree that it is used infrequently - in fact if you're a framework writer as well as application developer, if your code is actually "clean" you use it very often.
> Sorry man, don't quite share your enthusiastic hatred of > overloading - in fact I agree with x in your post. I > think it makes code more readable. Even from a problem > solving scenario (language aside) it makes absolute sense > - E.g. Ape being Abstract, Man and Gorilla being extended > classes, method slap passing in parameter hand have > different effects coz Gorilla is supposedly stronger - > that's plain common sense.
That sounds like polymorphism to me, not method overloading. In any case, in a single-dispatch language like Java, method overloading is a poor to unworkable solution for this kind of problem.
> Probably a poor example but > it's getting the point across - clarifies things from a > problem solving angle (well at least to me). I also > disagree that it is used infrequently - in fact if you're > a framework writer as well as application developer, if > your code is actually "clean" you use it very often.
In Java, method overloading acts (mostly) just like having two different methods with no relationship. The only times this isn't the case is in the JVM and the rules are complex and unintuitive. There is no real value in method overloading with single dispatch language. It's a best aesthetic and at worst the cause of many hours of debugging.
Would it really kill you to write slapMan() and slapGorilla()?
One of the insidious features of static method overloading is that it reminds people of polymorphism, which is very useful, even though it behaves totally differently.
Things should have decent, unique, human understandable names. I assert that the fully qualified types of all the parameters of a function should not figure in the name of that function. From first principals I think most people would come to a similar conclusion, but we've been poisoned by decades of exposure the feature.
If it makes you feel better, any language that wants to transparently integrate with java has to implement overloading, so Gosu nee GScript has it. Ugh.
Previous Topic
