This is an extension of a subthread in the topic Java FFI Enhancements

There were several discussions there re features that need/don't need to be in Fan v. 1.0. I am concerned that many of those discussions are, to my eye, very inwardly directed at needs by posters deeply familiar with the language's operations.

My concern is that those features distract from what needs to be in 1.0 to attract more users. From my vantage point (as a reviewer of software dev tools for InfoWorld and a Jolt judge for 19 years), there are four things that are conspicuously missing or unresolved--all of which I would gripe about in any review:

• The user-home/project-home scheme
• A .NET FFI
• IDE support
• documentation

For purposes of wider adoption of the language, these are the key items to focus on for the release. (As a side note, cedric in a recent comment on Reddit, observed that Fan won't take off until #2 and #3 are addressed.)

I know that Brian/Andy have business needs that may require goals that are different than those of wider adoption, and I am cool with that, of course. But if getting more developers to use Fan is the goal of 1.0, then I feel the above items should exclusively define the agenda.

mr_bean - good points!

The user-home/project-home scheme

We'll definitely have this hopefully in the next week or two.

A .NET FFI

Interesting that you see this as a priority - why is that? From my perspective it seems that virtually everyone who is involved with Fan is mostly interested in 1st class JVM support and sees .NET as a distraction (Cedric included).

IDE support

Agreed this is a huge issue. Although it is hard to get serious IDE support until we have a stable language. So I mostly see this a serial effort. I am hoping that the community helps solve this, especially since true success requires supporting not just one IDE, but everybody's favorite IDE (Eclipse, NetBeans, VisualStudio, etc). However, no matter what we will continue to flush out Flux as a first class Fan tooling platform (just have to balance that with making a living).

documentation

I definitely agree there is no such thing as too much documentation. Although we have pretty comprehensive documentation already. What key docs do you think are missing?

Thanks, Brian

• The user-home/project-home scheme

Yes, this is probably needed for IDE's anyhow.

• A .NET FFI

I guess i'm biased since I don't use .NET, it would definitely be a plus to have to potentially attract .NET devs, I made the point on how that was important to have Java FFI working well, so can't really say .NET FFI is nor needed. Brian said most of ppl interested in Fan care more about Java, i'm not surprised, but yet that could be a chicken and egg thing, since you might not get .NET ppl interested until .NET FFI works well. On the other hand most lang target both JVM and .NET are dragging on the .NET front, Scala is way behind on .NET impl and that did not seem to hurt them.

• IDE support

This one is a no brainer, a lot of ppl won't even bother if their IDE is not supported. I know IntelliJ is done, I'm doing work for NetBeans .. Eclipse HAS to get done as well.

• documentation

I don't see that one. Fan docs are very good and up to date, excellent for a young, changing language. A book would be good, as it's kind of a sign of maturity .. but it probably need to be at 1.0 first. I think it could use some documentation OUTSIDE of fandev, to get more visibility/traffic. I mean things like RosettaCode, Wikipedia and so on.

One thing I'd like to add is:

• A publicly available "real" example.

Like sidewalk or a "pet store" kind of thing. It's pretty useful when checking out a language. This probably could be done by the community.

Either way you don't want to drag on forever either, release often & early :)

Brian said most of ppl interested in Fan care more about Java, i'm not surprised

The main issue, as I see it, is that Java is painful for coding in. While I prefer Fan to C# as a language, recent versions of C# can be much less painful than Java. They have less need to look around for alternatives. (And some alternatives already exist there anyway, such as Boo.)

However, powerful cross-runtime support could be a powerful draw for .NET folks if Fan gains traction. And some might come for the language, too. Fan is a nice platform all itself.

I'm not sure how much is needed for 1.0. FFI (and LINQ and FWT and ...) would make the cross-runtime thing a lot more of a sell. If it's not in for 1.0, then it ought to be for 1.1 (or whatever), and it needs kept up to par thereafter, or it ought not to be part of the stated goals/virtues. Those are my 2 cents.

I'm in the .NET is a distraction camp, too, though I can appreciate some might want it. I'd be ok with letting it lag/wither unless there's specific/active interest in it.

The missing integration from the Java side could indeed be a serious adoption blocker.

It is clear that many developers would like to enhance their existing projects using Fan - one of the best options for adoption I'd say because the code is living with the project. Not allowing this could limit newcomers to various sorts of petshop examples (after which they might lose their interest because it'd be all too artificial).

Extending java/net classes / implementing java/net interfaces should be fine. If the deployment wasn't too complicated... something like putting a new jar or two on the classpath would be great.

I have interest in .NET. Also in deploying Fan pods as Jars. There are some unresolved issues here.

I'm thinking deployment, in general, is the big deal. In terms of application programs, deploy a fan app to a .net assembly is probably going to give the best user experience -- quick app start, easy to install, whatever. That only applies to Windows apps, of course; I don't know if that's going anywhere. :-)

Deploying a desktop app that runs on other OS's I guess means Java; and if we've got decent Java app deployment then it's workable on Windows too, so the .net becomes less important.

Web apps, Fan to JS to run in a browser, server side Fan, cloud... I'd call this the third leg, at least as important but for different people.

I think those really are three different markets, with differing expectations and needs; all three could benefit greatly from Fan. Each needs to see a solid proof-of-concept, a how-to-get-started, and a what-to-expect from Fan.

I'm thinking deployment, in general, is the big deal.

I've mentioned before that I think deployment/export is an important goal, though I've often thought of it as post 1.0. That is, it's not vital for stabilizing the language. But we're discussing from a "selling it" perspective now, and there's some value to that, too, for a 1.0.

I think of Fan as its own platform, and that's one important way to run apps.

But it's obviously not the only way. Java folks will want to write Java apps, which means dumping some jars. Automatic Mavenization would be good, too. Even automatically building native executables (with correct DLL dependencies going along, since Fan for Java includes SWT at least at this point) would be super sweet. Lumping all JS into one file for each browser (like GWT) would also be cool. I think all of these are nice features.

Personally, I still think stability is the most important feature for a 1.0. I guess the "selling it" perspective can't be ignored, either, but I'd really look a bit at differing some of these things. (Note from later: that should have been "deferring". I guess I was a bit tired or something.)

Agree with katox.

As a Java dev, one of the first thing I thought to do with Fan after hello world, was to implement a new feature of an existing Java app using Fan. It's kind of a natural thing to do.

But not sure whether it's NEEDED for a 1.0.

@brian and @regular-crew-on-this-list

Thanks for the thoughtful feedback. To answer the questions:

Understood that we are all in agreement on the user/project home directory and on the need for an IDE plugin. One point on the plugin: Is anyone working on a Visual Studio plugin? Not needed for 1.0, but surely if we are going to cater to those developers. (See next point)

Re .NET FFI: I agree of the four goals I posted, it's probably the one that most can wait. Positioning Fan for Java developers with the added benefit that if you don't use the Java FFI, you can run on .NET is fine. But with the intense competition in Fan-like languages on the JVM (Groovy, Scala, Jython, etc.), Fan's critical mass may well have to come from the .NET side of the world, where there are fewer competitors (mostly the Iron... languages).

Documentation: Agreed with the many positive comments re the existing docs. Here are the limitations I see and encounter: Except for some brief intro materials, the docs are mostly Fan equivalent of Javadoc. Cool for reference, but not for learning.

Ideally, there should be a User's Guide with details about installation, runtime environment, etc. Right now there are well-written fragments, with gaps between them. (For example, if I run Fan on Windows, it defaults to using Java. How do I compel Fan to use .NET? I needed to write to Brian to get this question answered.)

APIs are necessary, of course, but they present no overview. Currently, the architecture is spread across multiple pages from which the user needs to assemble things. The repercussion is that it makes adoption difficult for tire-kickers, the curious, and those looking for a better alternative to Java. Someone earlier posted a note about writing a book on Fan. A book would be great, but a user's guide in the interim would really be all that's needed for 1.0. (I would be willing to contribute to that effort.)

It's funny you mentioned the doc being fragmented. I was thinking the same thing, so i started making a page on my site, lie a "fan cheat sheet", kinda useful to me as a quick reference/overview.

It's far from complete: http://wiki.colar.net/fan_cheat_sheet

I'm planning on starting doing a fan project and also using Fan from Java in next few days. I'll write about that too, that maybe could be a "getting started" stub.

Now I'm hardly a tech writer, so it probably will be good if Brian/Andy would look it over when i'm done and make sure it makes sense :)

I think this site has most of the info avail one place or another, but a user guide where it's all put together would definitely nice.

But with the intense competition in Fan-like languages on the JVM (Groovy, Scala, Jython, etc.), Fan's critical mass may well have to come from the .NET side of the world, where there are fewer competitors (mostly the Iron... languages).

I don't think there is a shortage of languages on .Net. Besides IronPython, IronRuby, etc. you have Boo and Cobra which would be close competitors to Fan. If you like functional/OO hybrids there is Nemerle and more importantly Microsoft itself will ship F# with the next Visual Studio. Not to forget that C# is already a lot better than Java.

I personally don't think we need some big magical 1.0 release. Its just not realistic to finish everything that would be required for it. And it makes no sense to hold up Java devs for weeks or months while we flush out .NET support. I think the goal here should just be to get a stable release from the language and API perspective. Once the symbols and app dir work is complete, lets make sure there are no breaking changes on the docket. Then we can determine if the current 1.0 branch is considered stable. Then subsequent builds will gradually flush out support for .NET and JavaScript (and fix bugs), with the "guarantee" your code will keep working.

@tcolar: cool; quick skim: Litteral and Swith are typos; and near the bottom you've got

Example: a,b,d is same as a.add(b).add(d), especially nice for Swing/Fwt.

but it should be a,b,d, I think. Actually then it'd be it.add(a).add(b).add(d), I think; as you've got it it's like it.add(a).add(b).

Thanks, will fix. Honestly I had not even proofed read it yet as it was under construction. Will try to complete/ clean it up by the weekend.

Docs need more examples of file i/o. There are hints here and there but there appears to be no tutorials / guides to show you how proper file i/o is done. While writing my web start deployment script I had to bang my head against the File and Uri API docs until I finally figured out what I was supposed to do.

@tcolar: you will need to update your section on field access to use *fieldName instead of &fieldName as this change will be effective in the next build.

@andy I understand your perspective. You're looking at it from within the community. As I mentioned in my comments, my perspective is outside the immediate community, as someone coming to it (as a reviewer or a user of other languages) and trying to develop an opinion on its viability, future use, etc.

Then again, Scala's already at 2.7.5, and last I tried the Eclipse plugin (aka Scala IDE for Eclipse), it wasn't very good. Been a few months, though.

Anyway, just to show that not everything needs done by 1.0 to get a lot of attention. (Think of Java itself, even.) My thought is that maybe 1.1 should be the "not much changed but the guts are tough and ecosystem sure is filled out" release.

Just a thought.

Ruby also is not as strong on IDE side as it might look at a first glance. I know serious grail developers who rather use textmate or other editors.

But the deployment is very different. You can't avoid it.

@mr_bean

Except for some brief intro materials, the docs are mostly Fan equivalent of Javadoc. Cool for reference, but not for learning.

Have you reviewed docLang::index? That covers virtually every aspect of the language in a fairly readable way - of course everyone likes different styles of documentation.

(For example, if I run Fan on Windows, it defaults to using Java. How do I compel Fan to use .NET?

See docTools::Setup