Several of us hover here a lot. We add value in the form of ideas, but I think we also distract from an important goal: finishing Fan up to some stable state so that people can rely on compatibility going forward.

Here's a thought I have. Would there be value in some of us listing what changes we think are most vital? Maybe no more than two (or three or four?) per person, just to keep the list shorter? Maybe then an approval vote (i.e., vote for as many as you want) just to see what people are thinking?

I understand some ideas only come after more time, but maybe it would give some idea of scope to the things we're all individually thinking about.

Also, in the end, I think Brian and/or Andy need to act as dictators in the matter. But dictators are allowed counsel, too. And they've been very kind in considering our thoughts, I must say.

Is it a good idea to make such a list?

Or maybe good, but best to wait until the constructor storm subsides?

I've been thinking something similar, just not quite so clear. In particular, I want to go through all the blog posts I've written about how Java could be changed and ll the other ideas which haven't been written up. Basically, I want to make sure that all my key pain points have been addressed. I'd like to get to this in August.

I think we also distract from an important goal: finishing Fan up to some stable state so that people can rely on compatibility going forward.

By reaching a stable state you loose an important advantage: you can't change the language anymore (you can only extend it).

I don't have any ideas about Fan in particular. My ideas concering programming languages would never be part of Fan (most of them being about advanced type systems and some about very dynamic stuff).

But if everybody posts two or three ideas in this thread and people start discussing all those things in this thread it will become very confusing here. The current system - one idea per thread - seems a lot clearer.

but I think we also distract from an important goal: finishing Fan up to some stable state so that people can rely on compatibility going forward

That is very kind of you to consider our distractions :-) Although I don't consider any of the discussions we've had so far a distraction. In fact the quality and thoughtfulness of the discussions has been quite remarkable. I think Fan is much better for it.

We spent two years on Fan in silence to get something working good enough to write real code and to avoid distractions. The decision to go public in April was explicitly to have six to twelve months of feedback to hone the original ideas.

The surprising thing about Fan is that its development has been quite a straight arrow. We've taken very few detours along the way, and really haven't made any big breaking changes of note once we got past the first six months.

Constructors are one area where a big breaking change could happen. But I'm leaning pretty heavily towards leaving them alone and only adding validation and calling sugar.

Stephen and a couple others have suggested a null/nonull added to the type system which could be a big breaking change. I think convincing me that is the right move for Fan is unlikely, although I certainly welcome the debate :-)

So my current perspective is that the language itself isn't going to change too much. However I think there are some key APIs which are needed before a 1.0 release:

• FWT
• Finish Web APIs (including client side)
• XML APIs
• Crypto APIs
• Concurrency APIs need work
• IDE support

So my perspective is that APIs, not language features are the critical priorities. It is interesting that we haven't had many API discussions on the forum. But I suspect that is because a) early interest is by language enthusiasts and b) you don't tend to get into API issues until you start writing real code.

I am open to implementing breaking changes, but the window is going to close in October or November. So I agree with Tom, it is best to get everything on the table this summer.

I was just meaning to get everything in one list. Not for discussion on one thread. And actually, I guess enhancing Sidewalk for clever integrated issue tracking would be an interesting thing to do first. A thread could be an "issue" if it could have a main description on it (modifiable by whom?) and allow a few metadata fields.

And a separate thread could be a release by having a list of issues as a metadata field.

That's almost what's already being done today. I guess I'm just recommending a bit of standardized metadata you could throw at the top.

Oh, and I recommend instead of approval voting that we get X points that we can assign at a time, allowing multiple on one issue if we want but only X total. I've seen that on bug trackers elsewhere, and I like the feel of it.

Anyway, just some thoughts.

I'll post some new threads with thoughts I've had.

Also, glad to hear we haven't worn out our welcome.

I was just meaning to get everything in one list

Right now I'm maintaining the "the list" of things to consider for 1.0 manually under the Roadmap doc.

My current "process" is to promote issues from the discussion forum to the roadmap doc when there seems to be broad interest in an idea and I think it is a good idea.

Okay. Sounds fine. I guess I meant a list including what us third parties were thinking about. But maybe that would just cause confusion.