It's extremely interesting to follow the discussions around Fan. I was just wondering, is there a road map or general plan laid out? In other words, is it stable enough to start dappling on syntactical support soon in i.e. NetBeans?

/Casper

You can find what I've documented for a roadmap here.

Something like a new programming language always has a big catch-22. You don't know if you've really gotten it "right" until you've got a fairly large body of code written in the language. But you can't really encourage people to start writing code until you lock down changes to provide stability.

At this point, I've actually written quite a bit of Fan code and I'm starting to feel that it is "right enough". The only unresolved issue which has been heavily discussed is unified or modified with-blocks. But I would say that it is looking increasingly unlikely to change from its current design.

Other than the slot literal change, there really haven't been any breaking changes in the core since last year. So I would say things are looking pretty stable. I'm just talking about the language and core sys APIs. Some of the higher level APIs like web, webapp, and fwt are still works in progress.

I'm pretty open minded how the community would like to proceed down a path to getting to a stable 1.0 release. We can shoot for a quick 1.0 release blessed to be stable, then branch to a 1.1 release. If we decide we need a breaking change it would be in 1.1 only (or we turn 1.1 into 2.0). That gets a stable release people can count on quickly, but has a lot more overhead versus dragging 1.0 out.

My thought is that the language isn't going to change much from where it is right now. What is missing is a lot of key APIs and that is what I really want to focus on for the next year or two. So my inclination is to continue doing bi-weekly builds on the 1.0 branch which would be fairly stable, but continue to keep adding APIs and flush out new subsystems.

We have hundreds of thousands of lines of code (and more than 5000 classes) in our source code for UNA. As I don't like the direction Java is heading (C++), I'm looking for something different -- something that is cleaner, simpler, with better support for concurrency.

I'm not sure if Fan is it, because it doesn't have play well with Java code, does not support Software Transactional Memory (which appears to be the next big thing for concurrency -- not message passing), and is in its infancy. However, it's the first language I've seen where I can honestly say, "I think my developers would really dig that!" So I'm keeping a close eye on Fan, and from my point of view, a quick 1.0 release that's stable (if not feature complete) is superior to a feature-complete 1.0 release that doesn't happen for another year.

I would also like it if each release of Fan were capable of upgrading source code written in the last version. For this you need two parsers, a common AST, and a way to transform from one to the other. Then you don't get stuck in Java's rut, which is having billions of lines of code that no one wants to change, so the language keeps on contorting itself to incorporate the features that everyone wants.

Something differen, STM, Java compatible? Sounds like Clojure is an option if there wouldn't be the point "I think my developers would really dig that!" (unless they have some Lisp experience).

Clojure is hideous (just like Lisp). Java developers will never embrace it. :-)

So I'm keeping a close eye on Fan, and from my point of view, a quick 1.0 release that's stable (if not feature complete) is superior to a feature-complete 1.0 release that doesn't happen for another year

Noted

because it doesn't have play well with Java code

I agree this area needs work. The focus on portability has short changed calling Java APIs directly. There is an easy fix and a hard fix. The easy fix is to script Java APIs using the "->" operator, but this won't be statically typed or as efficient. The hard way is to try and expose more of the Java and .NET type system into Fan directly either thru stub tools or using other mechanisms. I'd be interested in feedback on which direction people would like to see. Probably the easiest way to achieve efficient, high fidelity with Java APIs is thru a Java-to-Fan stub tool.

does not support Software Transactional Memory

Messaging passing is definitely not the only solution I'm pursuing for Fan. In fact Fan will be moving towards a sort of STM thru the Namespace API. My next business I'm starting will be based on cloud based computing, so expect serious work in this area over the course of the next year.

I would also like it if each release of Fan were capable of upgrading source code written in the last version. For this you need two parsers, a common AST

If we make any breaking changes, then I agree we should definitely look at this.

I wonder if there is an option to integrate a more powerful multi-language feature:

Void process(Int value) {
  str := "Hello"

  java {
    System.out.println(str + " number " + value);
  }
}

This kind of approach would not be limited to just Java - it is essentially a mechanism whereby any other language could be added to Fan.

My view on implementation is that it is essentially a plugin compiler that is called by the Fan compiler on demand. The plugin is given the block of code to be compiled, and a means to extract variables. (I'm not saying this is easy, but it is achievable).

While the immediate implementation might appear to be integrating Java/.Net, this has far more potential. The world seems to be going "polyglot" at the moment, and this is a great answer. How about JRuby or Jython embedded in Fan?

The real power is beyond standard languages however - how about full high quality DSLs, for SQL, XPath, generating XML. Obviously, writing these DSLs would be hard - not a task for a typical developer. But that is probably a good thing, as it means that those that do appear should be better thought through.

And whats more, in many respects, these are just AST generators. So, Fan constructs like while, for and maybe with-blocks could theoretically be written as plugins.

Interesting follow up up to your multi lingual blog entry: http://www.jroller.com/scolebourne/entry/enhancing_java_multi_lingual_blocks

Essentially Fan would become a lingo franca bootstrapping layer, not only uniting the CLR and JVM (which is impressive by itself) but also languages on top of it. Would you be able to carry enough of the required semantics in just fcode though?! While .NET acknowledges that the whole world can not be encapsulated by its libraries, Java takes a somewhat more conservative stand on interoperability.

Namespace looks like it could be great for a distributed hashtable, which is often a key feature of STM. However, it's not fine-grained enough for working with lots of cores on a single processor.

I'm thinking something like the following:

1. New modifier shared that can be used with any variable, which indicates the variable may be shared between different threads, even if it's not immutable.
2. New code block atomic, which atomically performs the operations in the following code block. shared variables may only be read from or assigned in atomic blocks.

The initial implementation of STM could be rather simple. Later on, if Fan grows in popularity, more complex implementations could be used, which analyze the code in atomic blocks and do the minimum work necessary to preserve the atomic semantics.

As for interop with Java, I'm not a fan of stubbing. It's too cumbersome to be of practical value. I'd prefer that we specify something like "classpath" when compiling Fan code, and the Fan compiler looks at the bytecode to reverse-engineer the classes to their Fan equivalents. Then you provide a simple way to create new instances of a Java object. e.g.:

java:java.util.Map map := Java.create("java.util.HashMap")

map.put("foo", "bar")

Not the declaration of the type of map, which uses the java prefix to signify the type. Perhaps dotnet would be used for .NET.

Actually, since Fan already knows the type of the Java object (and must know it, to retain the benefits of static typing), we could write:

map := java:java.util.HashMap()

map.put("foo", "bar")

Or perhaps everything in "java.util" would be virtualized into a pod. If we imagine that using sys is really shorthand for using fan::sys, then we might extend the notion to incorporate support for using Java packages:

using java::java.util 

...

map := HashMap()
map.put("foo", "bar")

Now that's something I like, and would offer very high performance.

I imagine that the Fan-style constructor would be used for the Java no-arg constructor. Other constructors would need generated names; e.g. make1, make2, make3, etc. Similar issue with overloaded method names.

Namespace looks like it could be great for a distributed hashtable, which is often a key feature of STM. However, it's not fine-grained enough for working with lots of cores on a single processor.

I think I might have to disagree with that one. My experience is that coarsely grained concurrency does better at keeping the cores busy versus lots of find grained interaction. I think STM is very promising technology - but it is still evolving, I think we'll see great strides in this area over the next few years. It looks like we might see hardware/OS support for it, in which case we'll need JVM/CLR support to really utilize that level.

For the short term I will be pursuing more coarsely grained transactions which are closer to how databases works IMO.

I am going to branch the Java integration discussion into its own topic since it is a big and important topic on its own right.