Following What is required for 1.0? post I'm very curious how Fan language is positioned in the minds of people here. I think this is very important question for language success. Even if we have authority to use Fan in our "internal" projects, successful projects are never being "internal". There are always third-parties going to extend project, and other interested parties we need to argue the choice of technology. Using Fan in our (Fan enthusiasts) projects is definitely best way to spread the world, however before spreading the world we need to argue ourselves why we choosing Fan.

Just to clarify, I'm not a Fan enthusiast (yet), I just feel a sympathy for the language from the first look. Also feeling a need for more comfortable development I'm looking for something beyond Java... Fan as Yet Another General Purpose language is not a positioning - most of languages gaining momentum now are general-purpose.

Let me please recap other languages around:

• Scala - a language strongly positioned as functional-OO mix. I do not believe that Fan could be positioned as strong functional language (also I do not want to say this is required), so let's leave functional world to Scala guys.
• Ruby - a language Fan seems to borrow a lot from. But I personally vote for Fan - absence of static typing do not attract me to this language (let me please avoid comments on implementation here). So positioning Fan as a "better Ruby" may succeed, however it is not strong. We can also think about Fan like about "better Java"... But how is Ruby positioned? I think Ruby is not positioned, Ruby is still synonym for Rails, and Rails is positioned as a successful web framework with a lot of hype past years.

So interestingly, I think that "better Ruby" will not attract developers, due to most of Rubyists attracted by Rails (not Ruby itself). "Better Java" will not attract Javaists (due to week positioning) as well - there are a lot of "better Java"s around. "better Groovy"...

• Groovy - positioned as a language, which is initially developed for Java scripting. If fact this looks to be strong positioning (at least all the engineers having need in scripting capabilities will consider Groovy). Lack of Groovy popularity as it seems to me is due to such positioning - actually realtime scripting capabilities do not look to have strong demand. At same time almost no one talks about Groovy as about "better Java" language, just focusing on scripting capabilities... This would not attract masses of course.

Also from bird flight view, comparison of Groovy with Fan do not give me strong signal about benefits of Fan language over Groovy. Significant visible difference is Groovy has strong Java integration (and focused on this integration), Fan declared to be multi-platform... If this the only one major difference I'd prefer Groovy, of course. Multi-platform feature could be a huge benefit, but this must be additional, optional benefit to support core positioning of the language. Static/Dynamic type system could be such a key feature, but it looks to be mainstream now (like Groovy) and not enough to win battle for developer's hearts.

Again, I'm not familiar with Fan and probably missed anything important, so I would like to finish with a question to Fan enthusiasts: "Why did you choose Fan among other languages?".

Thank you, and Kind Regards, Andrey

Andrey,

Great post, some good ideas. My thoughts...

I don't think Fan will appeal to hard-core functional programmers. Fan definitely has functional programming built-in, but it is definitely designed to aid the development of OO libraries. So I agree it doesn't make sense to market Fan as a functional language per se.

As far the static/dynamic thing goes, Groovy is a dynamic language with optional static typing. Fan is a static language with optional dynamic typing. I think there is a world of differences there. Most importantly static method binding is going to put Fan more on par with Java and C# in terms of performance (boxed numbers obviously have a very significant performance impact though). Fan is more of a systems language - for example the compiler is written in Fan itself (not something you see with the typical scripting languages).

It is going to hard to pinpoint what the killer feature of Fan is because by design it is a deliberately simple language without any experimental features. A couple people have called it a "blue collar" language which is actually a great description. The goal of Fan is not to break new ground in language design. It is to solve all the practical problems which are typically architecture or API issues instead of language issues. Those things which I think sets Fan apart:

• Declarative programming: I think Fan does break new ground when it comes to integrating imperative programming with declarative programming. This is partly language, but more importantly it is having a standard serialization model deeply embedded into the core.
• Memory model: pretty much every mainstream language currently uses a shared memory model. We all know how important concurrency is going to be. Race conditions and deadlocks are the new big problems (what memory corruption and leaks were in C/C++ was when Java came along). I don't think Fan has completely solved this problem, but we are starting off with the right fundamentals: no shared mutable state, immutability built into the language, messaging passing, and future work on namespace transactional memory.
• APIs matter more than language features. To me the goal of a language is to support the APIs. Real code is based on using APIs and creating APIs. Now I'm completely biased, but I think elegant APIs are one of Fan's greatest strengths. We definitely can't compete on quantity, only quality. But time will help solve the quantity problem.
• Portability is a key feature of Fan. Maybe it doesn't appeal to a lot of software shops, but there are a lot of companies out there that struggle with Java versus .NET issue. I think this will be a sweet spot for Fan. We are also starting to look at Fan to JavaScript compiler - stay tuned.

So I'm not sure how you add that all up, but I think those are some the big features that separate Fan from the rest of the pack.

Fan's functional part is defenitely not appealing. The problem is that Fan has Ruby as idol. And Ruby has this total mess of blocks, procs, lambdas and methods. What's the difference? In a functional language a function is a function. As simple as that, no strange unexpected behavior. It can't be that difficult as Lisp has figured it out decades ago. As Fan wants to be like scripting languages, is there any scripting language beside JavaScript (which has a clumsy syntax) that does that right? Python does not, but for another reason.

The problem is that Fan has Ruby as idol.

I'm not sure where you got that from. The only thing similar about functions in Fan and Ruby is the | | syntax which is a pretty superficial comparison. In Fan a function is just a function, and methods are just named slot wrappers for functions. There are no other concepts, so the core abstractions are quite elegant. Rather I think the reason Fan isn't suitable for hard-core functional programming is that Fan is really centered on the OO paradigm. I think a middle-of-the-road type system like Fan doesn't really work for functional programming - you either need to go dynamic like Lisp or go sophisticated like Scala. I'd welcome suggestions about improvements to the functional aspects of Fan, but let's start a new thread for that.

Actually before I realy wrote some Fan code I expected the following to work:

class SomeClass {
   static Int testFunction(|Int->Int| f, Int arg)
   {
      return f(arg)
   }

   static Int function1(Int x) { return x }

   static const |Int->Int| function2 := |Int x->Int| { return x }

   static Void main()
   {
      |Int->Int| function3 := |Int x->Int| { return x }

      echo(testFunction(function1, 42));
      echo(testFunction(function2, 42));
      echo(testFunction(function3, 42));
   }
}

But it doesn't because lambda functions and other functions are something different in Fan which was actually quiet confusing for me and looks like some kind of leaky abstraction or whatever (or influence from Ruby). I think anybody with even superficial knowledge of ML, Haskell, Clean or Scheme would be confused by Fan's functions.

The equivalent Haskell code to the above would be something like this

testFunction f arg = f arg

function1 x = x
function2 = \x -> x

main = let
          function3 x = x
       in
          do print $ function1 42
             print $ function2 42
             print $ function3 42

You see everything just works, named functions, lambda functions, local functions that capture their environment (AKA closures, and yes there isn't much to capture here) are all the same.

OK actually the code isn't exactly the same. function3 should look like this:

function3 = \x -> x

because Fan doesn't have named local functions. And the Haskell functions are more general as Haskell would infere polymorphic types (parametric polymorphism that is AKA "generics") and I'm currently too lazy to artifically introduce more limiting types.

And know I hijacked this thread :p , but this seems to happen rather often in this forum.

Personally I gotta agree. I would expect your example to work exactly the way you describe.

Helium,

Regarding your example code, there are two reasons why that doesn't work in Fan. First is that I'm not allowing a closure to be used as a field initialization expression. There really is no good reason for that restriction so I will fix that. The second problem is that you need to use the & operator to access function1 as a function - this is required because Fan allows you to omit the parenthesis when calling a function.

But for the purposes of this thread, I don't disagree that Fan isn't going to win over any hardcore functional programmers. By definition an OO language embraces the notation of state, and functional languages eschew state.

Hi!

I'll venture to add my few cents to the Fan discussion from a Java developer standpoint. While searching web for details of Java7 new features I found usual remarks of various languages solving the Java problem - Ruby, Groovy, Scala, Python or some more exotic like OpenML and zillion others which did not make it to TOP 100.

Nevertheless I followed one of the links that brought me to Fan website. Despite the java-soul-scaring example on the front page I clicked on the bold link at the bottom and took the Tour. It really suprised me that Fan wasn't obviously meant to be "rapid" (read untyped scripting) solution. I percieved Fan more as trying to remove a burden from what we currently know as Java. I started to be curious...

Then it happened that I have read all the site documentation (including roadmap linked discussions), some code samples from the download fan package and other topics from "Discuss" tab. And my curiosity continues which is a second surprise ;)

I'm still not sure about Fan primary goal but there are some points that stroke me clearly especially in this rather early development stage:

• pods (modules) with versions and dependencies
• standard build engine (self hosted in Fan)
• declarative configuration / serialization built-in
• DRY concept
• unit testing baked in to core
• built-in logging
• mostly readable syntax for a java-joe

Particulary things on this list caused me and my colleges more than few headaches last weeks. Bad language APIs hurt but not as much as some ill-formed concepts that go pretty deep in the language itself. Java itself is unnecessarily complex and JEE is a trully hideous monstous beast. I spent a full week trying to resolve some classloader/logging related problems somewhere deep in the application server called by 3rd party lib indirectly from our application somewhere from static method tangle and the resolution was there was nothing we could do about it becouse jars are really so poor.

It reminded me again the current (heated) discussion around OSGi and JSR 277/294. So far the java moduling system is in a pitous condition and I can't see the light at the end of a tunnel.

Any replacement/enhancement of Java should at least resolve such fundamental problems to even have a chance to be successful. Besides stable language design (which is a must on core concepts) the specs should be clear at least on:

• Versioned modules. The pods seem to be fine for that at first sight but we need to ensure that dependencies and versions are ok. Particulary the versioning part is tricky if we want to avoid problems like ones described here. I am not sure if Fan supports multiple versions of one pod per application but it is crucial. Anything else effectively kills the encapsulation. This also covers facets, namespaces and Uris.
• Build system. A thoughtful system is lacked not only by Java but also C/C++ and bunch of other languages. Maven2 is close with the repository concept but so far it is stuck half-way.
• Bridging to Java (native) - very important issue, the question is whether unified bridging to other languages is really needed or if it is ok to have separate bridges for separate languages
• Serialization / Remoting concept - comparable to Java
• Security model - comparable to Java (SE), JEE security model is quite unhelpful
• Easy configuration - I believe Fan has already won on this item
• Built in logging - comparable to logback, ie. thread and context aware, configurable, yet simple
• Unit testing - basics are definitely there but what about component configuration, stub/mock replacement as in Guice/Spring/custom DI frameworks
• What about AOP and auto-proxying generally, e.g. Salve
• What about component web frameworks like Wicket - won't the collide with existing Fan solutions?

I'll rather stop now ;). The very short summary is that Fan 1.0 should have (good enough) stable lang spec, resolved versioning and modularity, bridging to wide-spread language (at least java), well thought-(not neccessarily fully implemented) concepts of build/remoting/threading/aop. And all this by the end of 2008 ;)

P.S. I'd like to note that Fan looks very interesting and promissing, congratulations on that.

I've fixed the issues Helium identified in this post. Closures can now be used anywhere an expression is expected including as field initializers and as parameter defaults. This was always the plan, I just needed to tidy up the compiler.

I've also fixed an issue where function types weren't allowed for const fields. Const fields typed as a function now work just like list, maps, and types - they compile with an implicit call to Func.toImmutable which will fail at runtime if you don't actually assign an immutable function to the field.

The code in Helium's post works as expected (note the one change where we need to use & operator on function1):

class SomeClass
{
  static Int testFunction(|Int->Int| f, Int arg) { return f(arg) }
  static Int function1(Int x) { return x }
  static const |Int->Int| function2 := |Int x->Int| { return x }
  static Void main()
  {
    |Int->Int| function3 := |Int x->Int| { return x }
    echo(testFunction(&function1, 42));
    echo(testFunction(function2, 42));
    echo(testFunction(function3, 42));
  }
}

There are two main choices for "Java NG".

• Groovy - Dynamic, scripting. Similar syntax to Java. Excellent integration. Generally poor performance.
• Scala - Static, functional leaning. Syntax derived from Java but reasonably different. Complex approach in some areas due to functional mix. High performance.

My opinion is that "Java NG" must be statically typed, for code reliability and performance reasons. This rules out Groovy.

My opinion is that Scala is too complex for the mainstream. Just try reading the blogs of those writing about Scala and you'll find your head hurting. (Scala appeals to the academic, very smart, end of the community, often liked to the functional community). This rules out Scala.

Before Fan, I was working to get Java changed, as that seemed to me to be the best of a bad set of options. Fan changes that game, and brings the key middle ground back into play.

I see Fan's golden rule as pragmatism. And that will prove vital as the final decisions are taken on the core language and APIs. Key elements from this include the type system, immutability, casting, pods and declarative coding.

We each have a list of target changes we think are necessary. Some are obvious conclusions to existing debates (construction, equals/compare, pod versioning, Java/Net integration, public pod repository), some will be more controversial (composition).

My final goal is to eliminate as many errors as possible by language change that are currently caught by static analysis (eg.FindBugs) or production errors. All new languages should build on prior knowledge with errors and design patterns, and it will be a great marketing line ("Fan elimates x% of errors previously caught by tools like FindBugs").

Fan elimates x% of errors previously caught by tools like FindBugs

Could be nice, but I'd at least like to add: "... without requiring 5x the code or introducing new kinds of easy ways to mess things up badly (like checked exceptions did for Java)."

And I think you also agree that static checking isn't always best, or else you'd be arguing for Scala's generics support.

I like not-null-by-default and explicit nullability because I think it fits the good category. Makes static understanding easier in an area that's naturally difficult (how many useless, fear mode null-checks litter code all the time because we don't even know what to expect?), but so far I don't expect it will cause horrible pain.

Maybe a late comer to the dsicussion, but this is what I saw in Fantom when I encountered it: A do-over of Java, fixing many of it's greatest omissions, plus the ability to really "run anywhere" thanks to multiple backends (JVM, .NET, Javascript).

The ability to write Fantom code that runs on the server AND in the browser is very appealing and I think that this can be emphasized more. I really liked the look of Opa because they do that well (supposedly) and this is pretty much their whole USP.