Welcome !

[Nicolas Cannasse]

Hi all,

Welcome to [haxenext] group, a place where we will discuss how to bring
Haxe to the next level.

As I explained in my invitation this is an open group, feel free to
invite anybody interested in helping in making Haxe grow and become more
popular. We are especially looking for people investing in Haxe with a
long-term vision.

In order to get started I have a simple question to ask you :

What would be for you the top 3 things that we need to fix/improve
to make Haxe more popular ? (in order of decreasing importance)

Please be very precise while answering this question. For instance
"improving the website" is bit too much abstract.

You're welcome also to provide an actual action-plan proposal that we
could follow in order to make it happen.

Based on your answers we will discuss what needs to be done first, and how.

Thank you !

Nicolas

[Franco Ponticelli]

• ironize the JS output
• remove any modification to basic types (String, Array, Math, Date)
• minimize the output of "Hello World"
• move to Github. Providing patches right now is possible and not complicated but merge requests in Github are really a 2 clicks operation and would speed up the integration process a lot. It could also help adding documentation. Apparently people don't feel good to update the documentation on the wiki. This is a particularly simple thing to do and can provide a major impact.
• build a competitor for ExtJS/Flex that works cross platform.

[Cauê Waneck]

 What would be for you the top 3 things that we need to fix/improve
 to make Haxe more popular ? (in order of decreasing importance)

Okay, you asked for detailed ;) 

In general:

• Create the Haxe Foundation. I know there are too many areas that would need funding, and I also know that there are companies / individuals willing to contribute and pay for them as well. 

For beginners / developers:

• Organize the documentation in a friendlier manner
• Many people complain about Haxe's documentation, IMO it's not bad, but it's scattered around in a very confusing manner, We need to have a "tour" for a beginner, with "recipes", and many examples. Even the examples at Wikipedia is a little scary, as the first example already introduces to Function types syntax!
• Create a "Try Haxe" site
• I think this could become something very social, and VERY fun. It could start with something like this:  http://golang.org/ , but I think we could expand to something like Wonderfl. I think the hardest part of that would be to make it safe, as it would be truly awesome to be able to showcase some simple client->server communication, for example. I can imagine that with a good system for tags, and a simple code analysis to get the used functions could render something which IMO is even better than documentation (of course one does not exclude the other): simple snippets and examples! Integrate that with an IDE and you have instant snippets on how to use an API!

Strategies

Site communication strategies

• Elaborate the various strengths of Haxe, and make a proper communication
• "Have your client and server developers speak the same language" - show sexy examples of haxe remoting here
• "Find errors before they find you" - focus here on JS and maybe think of a way to show how proper typed code runs faster on e.g. v8. Also maybe include here about PHP
• "A language that scales to your needs" - you can begin really small with PHP and a shared hosting, go through your own server with Neko and then go to the cloud with (GAE? XirSys?). Without changing the code base!
• "Faster than native" or "committed to speed" - I think we could talk about how the Haxe compiler does a better job in terms of performance than sometimes the native compilers. Talk about Flash and Alchemy opcodes, maybe talk again about the importance of strictly typed code for js (v8), show some benchmarks of NME vs Air, and I promise in the future some crazy benchmarks for C# and Java. By now we have a ~20x speedup on reflection for Java, but I'm not optimizing yet :)
• "Open source" - show how this is a strength related to how there's no way to simply "shut haxe down" (which is actually a quite common thought), and introduce the Haxe Foundation, also maybe offer through it a paying support plan for companies. This is important to show reliability. Make clear that actually investing in Haxe is investing on the future. Your code will be able to run on whatever is the next hype platform!
• "Instant compile" -  http://xkcd.com/303/
• "Don't Repeat Yourself" - small introduction on how type inferencing can keep your code small and performant
• ? please add more!

New targets strategies

• Unity 3D: 
• I think it could be a very important player for us. As far as I see it, people are migrating from flash to either Js or Unity. And while the Unity guys tried to do something that resembled AS3 with UnityScript, it's got tons of problems. I think when the C# target is stable, we could start writing blog posts about "AS3 transition to Unity" with Haxe. And we could make some libs (like Actuate) work with Unity, which would IMHO make them very interested
• Also some good remoting examples showing e.g. Unity->Flash (to get e.g. webcam results) and Unity->PHP/Neko would be great to show the possibilities that would open for them
• I'll do my best to integrate smoothly with the Unity IDE. It might be a good idea to talk with the Unity guys and see if we could have some kind of support from them. A simple option to automatically compile .hx code (like it does with c#, UnityScript and Boo) would be fantastic, but I think we could do much better.
• Use all our SWF decoding tools/knowledge to provide a way to play (simple) SWFs inside Unity. GUI design is a major problem for Unity, as their API for GUI is simply terrible. Each character (for texts) is one draw call, and the whole api is static (for example a button returns a bool!).  This might need Unity to back this up, but it wouldn't be too hard, as Unity does offer a very basic direct GL calls.
• Java
• I'm finishing a Java to Haxe code converter, which will be great for handling legacy code and making smooth transitions. Need help transitioning? Haxe foundation to the rescue!
• Again show some great speed numbers. I can promise that much more than I can promise for C#, as C# is much well made for speed
• Netduino, Android, etc...

[Cauê Waneck]

• build a competitor for ExtJS/Flex that works cross platform.

Maybe we already have that? Isn't ASWing running on NME? Maybe it's running on Jeash too?

IMHO It would be great to have something close to ASWing, since the Flash guys are used to it, the Java guys are used to it (by the way, it seems to me that the API is close enough to be compatible with Java almost out-of-the-box), and if we get it to run well on NME/Jeash, we've got a cross-target way to do GUI!

[Cauê Waneck]

• "Open source" - show how this is a strength related to how there's no way to simply "shut haxe down" (which is actually a quite common thought), and introduce the Haxe Foundation, also maybe offer through it a paying support plan for companies. This is important to show reliability. Make clear that actually investing in Haxe is investing on the future. Your code will be able to run on whatever is the next hype platform!

 

We could call this section either "Open source" or "Never gonna let you go!"

[Philippe Elsass]

I think this point ("you can't shut haxe down") could actually be a weakness unless you have an official, strong and opinionated group of maintainers. Which haxe doesn't really have for now. 

A recurring question is about using SWCs and JS libraries. Flash and JS are all about libraries and interop (assimilate!) is what really allows people to switch to haxe.

- for AS3 it should be highlighted very early in the doc (both for SWF and NME),

- for JS there's a real need for a solution somewhat matching the simplicity of "get a JS lib, drop and use in the project" (porting JS libraries to haxe is NOT a solution imho).

On a related note people should stop porting AS3/JS code to haxe unless they actually plan to maintain their port forever. haxelib is nice but too much stuff here seem half backed, not maintained or compete with other ports: it needs some kind of official curation work.

Finally as a JS dev myself, it was quite frustrating to use haxe; this lang is pretty much anti-JS in every possible ways, and figuring the right way to do the usual "all untyped" way of JS is hard. BTW in regard to the recent discussion about events, the doc on haxe.org seems a bit misleading: http://haxe.org/doc/js/events - no word about automatic function closures and, to add to the confusion, the page is suggesting Distill as some kind of officially-supported/recommended event binding solution.

On Wed, May 9, 2012 at 7:34 AM, Cauê Waneck <wan...@gmail.com> wrote:

• "Open source" - show how this is a strength related to how there's no way to simply "shut haxe down" (which is actually a quite common thought), and introduce the Haxe Foundation, also maybe offer through it a paying support plan for companies. This is important to show reliability. Make clear that actually investing in Haxe is investing on the future. Your code will be able to run on whatever is the next hype platform!

 

We could call this section either "Open source" or "Never gonna let you go!"

--
Philippe

[Cauê Waneck]

I think this point ("you can't shut haxe down") could actually be a weakness unless you have an official, strong and opinionated group of maintainers. Which haxe doesn't really have for now. 

Well, I think you're right, it doesn't belong there. But anyhow our PR should handle this kind of thought and make an answer for it. There is some belief that the whole Haxe project depends on Nicolas, and it's not like that. First of all, there are more devs working on the Haxe code base than Nicolas; Also, working with Haxe actually makes you less vulnerable to possible technology changes than the opposite. The last good example we have is Adobe with Flash, or Oracle with Java (which didn't give up, but many Java devs are migrating away from the platform).

The code being open-source is an extra security in that sense.

A recurring question is about using SWCs and JS libraries. Flash and JS are all about libraries and interop (assimilate!) is what really allows people to switch to haxe.

That's also a good point. Use libraries from Flash, JS, Java and C# natively!

 

- for JS there's a real need for a solution somewhat matching the simplicity of "get a JS lib, drop and use in the project" (porting JS libraries to haxe is NOT a solution imho).

That would be cool, but it would be a lot of work, IMHO, specially to extract types from it.

[Philippe Elsass]

The point is that I'm suggesting that haxe.org would present "people behind haxe", which means some people should decide to stand up for haxe as official maintainers (with suppleants preferably) for the various aspects of haxe ecosystem. This group would look as (if not more) serious as any company-supported technology. This is probably not an easy/light task but I believe this is needed eventually. Also those people would do some curation in their field to voice how things should be done (but you can do your way if you know more).

One point that needs doc is casting I think. There's a quick mention in http://haxe.org/ref/Dynamic but I believe it would be worth a full page with many samples where it's meaningful. It was really bothering me until I went to use unsafe casting most of the time, thank you.

Now "selling" haxe to JS devs requires to let go some control. JS devs are used to work in an untyped world and being too strict adds a lot of friction and confusion. For instance I believe the compiler could only issue warnings (unless requiring "strict typing") for JS externs. In a related note, in an era of jQuery-like libraries, stdjs is probably too impressive for newcomers as it basically requires people to have read the W3C specs (ie. 1% of JS devs).

That said there are ways to (approximately) type JS libraries:

- JS Doc:

http://code.google.com/p/jsdoc-toolkit/

- Google Closure (based on JS doc):

https://developers.google.com/closure/compiler/docs/js-for-compiler

- JsDuck:

https://github.com/senchalabs/jsduck

I believe for JS externs the compiler could only issue warnings (unless specifying some "force strict typing" directive). JS devs are used to work in an untyped world and being too strict adds a lot of friction and confusion.

Oh and haxe-js should really highlight the code mapping stuff.

--
Philippe

[Peter Halacsy]

 What would be for you the top 3 things that we need to fix/improve
 to make Haxe more popular ? (in order of decreasing importance)

Hi guys,

my top things

1.position haxe

is this really for multiplatform? or a safe platform like .net or java? who are our competitors? who are our target groups

find the strategy

2. some collaboration policies

 is this a very democratic community? who makes the decision? is this design by committee?

3. top priority projects based on #1 and #2

if we are the competitor of java, then we should have project compete with scala and hadoop 

if it's a multiplatform tool then we need to work on nme

if it's a type safe web language then we need gwt like stuff

so I would like the decision makers set the priorities for a year. And define projects. 

sorry these are not features etc, but I believe having a common goal, shared value and clear strategy are the most important

hp

[Nicolas Cannasse]

> 1.position haxe
> is this really for multiplatform? or a safe platform like .net or java?
> who are our competitors? who are our target groups
> find the strategy

This is indeed very important. So far Haxe can make... everything. And
trying to be everything is a good way to become nothing :)

Haxe have many different usages, such as :

- NME : targeted at mobile games with an emphasis on performances and
crossplatformability. Strong technical aspects, but I think still very
far in terms of getting-started/documentation/overall workflow compared
to competing frameworks

- JS apps : OO + flexible typing greatly help building JS apps "in the
large", help with teams, maintainability, scalability. OTOH the
traditional JS world is more about dynamically typing. Thanks to
overloads we can now "speak JS" better (such as JQuery) but it will
still be hard to convince JS natives to jump on board. Much more easy
for people coming from Java/AS3 or other structured languages.

- Flash dev : a lot of people come from here, Haxe being better and more
performant than AS3. That's however not enough to bring the masses,
unless we also sell them HTML5/mobile compatibility (with NME). Still
focused on gaming, we don't have something like Flex.

- Web dev : not that much used compared to others, but we have strong
selling points with SPOD for ORM, Temploc/Erazor for templates. Still we
don't have a complete standard customizable framework well documented
such as RubyOnRails.

- Interoperability : the ability to use the same language on both client
and server on both flash/js, etc. is quite unique. It will surely help
people to move 100% Haxe but I guess it's a hard selling point for a
first try.

> 2. some collaboration policies
> is this a very democratic community? who makes the decision? is this
> design by committee?

I guess it depends which decisions we're talking about. As for the
language itself, I will keep the veto in order to guarantee that it does
not become bloated or get some incompatible features.

However we've been opening up the development much more in the past year
and we have new compiler contributors such as Bruno (JS modern and
source mapping), Caue (C#/Java) and Simon (macros and other compiler
patches).

I guess we are on a nice road to increase the contributors. We've been
discussing GitHub at some point but I still think that might make too
many people keep their own fork with their own changes, which is not the
best for a common language which require more stability.

As for the other decisions, so far we have not any process since we
don't have an official body either. I'm fine with something much more
democratic here.

> 3. top priority projects based on #1 and #2
> if we are the competitor of java, then we should have project compete
> with scala and hadoop
> if it's a multiplatform tool then we need to work on nme
> if it's a type safe web language then we need gwt like stuff
>
> so I would like the decision makers set the priorities for a year. And
> define projects.

The question I have here, is what would be the exact impact of such
decisions ? For instance let's say we decide that building a
crossplatform IDE is the best strategical move. Who actually write it ?
Does companies give some time or money for it ? Do we have enough people
involved for it right now ?

Having a strategy is very important, but we need also to ensure that we
have ways to apply it in practice.

Best,
Nicolas

[misprintt]

   What would be for you the top 3 things that we need to fix/improve
   to make Haxe more popular ? (in order of decreasing importance)

Hi all,

My top three are:

1. Reduce barriers for JS developers to get on board

2. Overhaul Haxelib (popularity/featured libs, best practise guidelines, specific platform/haxe version compliance)

3. Make working with native code as seamless (and friendly as possible)

1. Reduce barrier for JS developers

• IMO the 'benefits' list on haxejs.org is a good start for selling the value proposition, but plenty of JS developer don't already know about language concepts like type inference,  generics, enums, etc
• We need to show simple examples that demonstrate the immediate values to a potential dev. I've uploaded a few (outdate) internal slides as an example of what I mean http://ui.massive.com.au/haxe/haxe-concepts.pdf 
• Taking this a step further – we could look at 'learn haxe in 30 minute' style tutorials to specific developer groups -  that try to sell/demonstrate the practical value of adopting the technology.
• I also like the idea of an in-browser sandbox for trying/viewing samples

2. Overhaul Haxelib

It's already been mentioned that Haxelib is littered with undocumented, unsupported and sometimes misleading libraries.

It takes a lot of time for developers to sort through and find appropriate libraries – many people end up on the mailing list looking for support/clarification on a library, many developers end up reinventing their own solution to existing problems (out of ignorance or frustration). Furthermore, every library represents the idiosyncratic conventions of the individual developer – often this clashes with user's own conventions and other libraries (IMO a big factor in the 'reinvent the wheel' mentality)

This all ends up reinforcing a common negative perception of open source platforms – immature, fractured and unreliable ecosystem

Suggestions

• Better visibility of usage/popularity/ratings of libraries (look at node's module registry as a simple example http://search.npmjs.org/)
• Featured libraries (good excuse to provide a tutorial/example when featuring a specific library)
• More formalised indication of supported targets and versions (like a compliance matrix)
• Developers need to know:
• which targets platforms are fully supported (versus partial or unsupported)
• Which version(s) of haxe it officially supports
• If it hasn't been submitted against the latest version, then indicate as such
• Related or similar libraries
• Ability to switch between production and unstable versions (when working against nightly haxe),
• Comments/feedback
• Recommended language guidelines (coding best practice standards) for developers to follow – would help maturity and consistency of the ecosystem
• How do we reduce duplication and endless 'meta libraries'? Can we identify some commonly recurring patterns and facilitate some community driven initiative to get existing lib developers to 'join forces' and implement 'official' community libs that follow language guidelines. 

3. Working with native should be as easy as possible.

I feel that it is important that 'leveraging native' is an integral part of Haxe's value proposition.

This is applicable across all targets - there is so much existing code out there in native languages that doesn't need to be reinvented/ported. Maintaining externs for large native APIs adds an overhead when those APIs are constantly evolving.

I agree with Philippe's suggestions around reducing barriers around leveraging existing javascript – while strictly typed externs are easy to make (once you know how), to newcomers it feels like a big hoop to jump through just to work with native. 

Anything we can do to make this more automated, or more forgiving is a good thing.

Some ideas around this:

• 'import native' tools that allow developers to select which native classes (and methods) to generate externs for.
• dedicated externs haxelib 'section' (filtered by target language) versioned against the original API versions for clarity

Cheers,

Dom 

[misprintt]

I guess we are on a nice road to increase the contributors. We've been
discussing GitHub at some point but I still think that might make too
many people keep their own fork with their own changes, which is not the
best for a common language which require more stability.

I believe the benefits of moving to GitHub greatly out-way the risks of fragmentation.

We want to encourage contribution - and this provides an easy, safe, controlled way to do so. There will always be the occasional developer who wants to go down their own path, but most want to see the platform grow stronger.

  

[Peter Halacsy]

On Fri, May 11, 2012 at 2:26 AM, misprintt <domdel...@gmail.com> wrote:

   What would be for you the top 3 things that we need to fix/improve
   to make Haxe more popular ? (in order of decreasing importance)

Hi all,

My top three are:

1. Reduce barriers for JS developers to get on board

2. Overhaul Haxelib (popularity/featured libs, best practise guidelines, specific platform/haxe version compliance)

3. Make working with native code as seamless (and friendly as possible)

hi,

although I like this project this is a very good example of having no strategy. WHY this projects and why not 3 other? Is this the right for the bright future?

hp 

[Peter Halacsy]

On Wed, May 9, 2012 at 11:54 PM, Nicolas Cannasse <ncan...@motion-twin.com> wrote:

1.position haxe
is this really for multiplatform? or a safe platform like .net or java?
who are our competitors? who are our target groups
find the strategy

This is indeed very important. So far Haxe can make... everything. And trying to be everything is a good way to become nothing :)

basically I like this.

this is like mono / .net / java. No?

today the website says: haxe is a multiplatform. But if it's not the key advantage than we should reposition

so I would like the decision makers set the priorities for a year. And
define projects.

The question I have here, is what would be the exact impact of such decisions ? For instance let's say we decide that building a crossplatform IDE is the best strategical move. Who actually write it ? Does companies give some time or money for it ? Do we have enough people involved for it right now ?

 I think we can do at least 2 things. Both are kinda focusing

1. we tell everyone in the community that flash ide is the most important. The best people doesn't work on other projects. We ask everyone to contribute. We focus/motivate the community

2. we raise money for the project. Companies would love this as the project is accountable. Prezi give $50K and if there is no ide in 6 month won't give more money anymore. 

hp

[Philippe Elsass]

I'm not convinced by a crossplatform haxe IDE project:

- from scratch, would be a many years project with uncertain outcome,

- based on an existing IDE: why not, but remember ASDT? as soon as FDT appeared with kick-ass AS2 support the project died.

User adoption will drive commercial IDEs development - I think IntelliJ and FDT are starting to measure they have a market here and the best way to push them to improve is to buy licenses.

User adoption is driven by haxe being an answer to a very practical, immediate, need:

- cross-mobile dev: NME (in good way, needs polishing),

- Flash-like JS: haxe-js (needs evangelists/curation, doc, samples, easier/better externs for Easel/Sencha/etc.),

and haxe's problem is friction for newcomers,

- RoR-like: needs an official, complete, ready to use, framework and samples.

IMHO Flash target and cross-platform aspects of haxe are low hanging fruits for people *already sold* to haxe. 

Peter, if a company is ready to invest for specific features why not contract directly with people to do it? 

BTW Nicolas, I'm available to develop HSS support in FlashDevelop ;)

--
Philippe

[Peter Halacsy]

On Fri, May 11, 2012 at 10:27 AM, Philippe Elsass <philipp...@gmail.com> wrote:

I'm not convinced by a crossplatform haxe IDE project:

my email and thread were not about ide but about the need of strategy and roadmap based on strategy

[Philippe Elsass]

Well that's why I think the strategy is to capture immediate needs: mobile and Flash>JS Flashers/Flexers reconversion.

But in both cases what would be the ROI for companies to invest?

--
Philippe

[Peter Halacsy]

On Fri, May 11, 2012 at 11:46 AM, Philippe Elsass <philipp...@gmail.com> wrote:

Well that's why I think the strategy is to capture immediate needs: mobile and Flash>JS Flashers/Flexers reconversion.

But in both cases what would be the ROI for companies to invest?

first: what do you need to do? 

[e-cat]

Hi, group.

On Tuesday, May 8, 2012 12:16:50 PM UTC+3, Nicolas Cannasse wrote:

...

   What would be for you the top 3 things that we need to fix/improve
   to make Haxe more popular ? (in order of decreasing importance)

I have been following haXe development for several years now, mostly on #haxe @ freenode.net, and in these years it has matured from an exotic language to my next tool of choice.

There's just one (1) top thing that we desperately need to improve, and this is documentation. For example, I tried to play a little with haxe.web.Dispatch, and the documentation on the site is not missing or incomplete - it is misleading. Functions it mentions are working differently than expected, features are missing or working differently. I understand, that the reason for this is the rapid development the platform is undergoing, and this is a good thing - but we absolutely need to have the documentation, and, most importantly, working examples stay up to date. One can't properly grok complex concepts like templates and haxe's enums and macros and reflection without good examples.

The rest is, well, nice to have. A good widget/controls library for NME, that would allow not only games, but applications development - and applications need tables, buttons, scroll bars and entry fields, which currently have to be hand-drawn. More databases support. Java or .net target. But nothing compares to good, comprehensive tutorials on how to implement those things.

I will track my progress as I explore the intricacies of this platform and will attempt to write down some notes and examples in the hope to provide this much needed aspect.

As to the format - despite niceties of wiki-like engines, great examples of working documentation projects are Microsoft's MSDN library and Adobe's Flash documentation.

[Frank Bos]

I also agree that number one priority is Documentation for Haxe. Microsoft's MSDN is amazing for languages that support overloading but for non-overloading languages like Haxe the as3 documentation is better. Adobe has documentation + examples for the most used classes. Check for example the docs on TextField ( http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/text/TextField.html ).

Haxe nme also lacks on this point. It is an amazing framework and tool to work cross platform. The problem is that most documentation can be found in the code itself. The people behind Haxe NME did an amazing job trying to mirror the air/flash api's but on some points it is lacking documentation on missing functionality.

[Nicolas Cannasse]

I agree that documentation is important, but it's also somehow hard to
do : library/compiler developers are usually to busy to write it, and
are not maybe the best for it since they know already things too much
well and are not maybe the best "teachers".

Does anyone here have an idea how we could actually make a better
documentation - in terms of practical process ? If that needs some
funding, I guess we can make it happen once the Foundation is setup.

Best,
Nicolas

[Frank Bos]

I guess you need some people dedicated to writing documentation like
Adobe has several language evangalist only this will cost some money :
(. If everything works out I am graduated in a few weeks and will have
some free spare time maybe I could write documentation a few hours a
week will keep in touch.

On May 30, 11:42 pm, Nicolas Cannasse <ncanna...@motion-twin.com>
wrote:

> Le 30/05/2012 23:34, Frank Bos a écrit :
>
> > I also agree that number one priority is Documentation for Haxe.
> > Microsoft's MSDN is amazing for languages that support overloading but
> > for non-overloading languages like Haxe the as3 documentation is better.
> > Adobe has documentation + examples for the most used classes. Check for
> > example the docs on TextField (

> >http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/fl...

[Nicolas Cannasse]

Le 30/05/2012 23:47, Frank Bos a �crit :

> I guess you need some people dedicated to writing documentation like
> Adobe has several language evangalist only this will cost some money :
> (. If everything works out I am graduated in a few weeks and will have
> some free spare time maybe I could write documentation a few hours a
> week will keep in touch.

An Haxe Evangelist program might be interesting to put together. Do
somebody have an idea what kind of things Adobe require and which kind
of compensation evangelist get in return ?

Best,
Nicolas

[Raoul Duke]

On Wed, May 30, 2012 at 2:42 PM, Nicolas Cannasse
<ncan...@motion-twin.com> wrote:
>> found in the code itself. The people behind Haxe NME did an amazing job
>> trying to mirror the air/flash api's but on some points it is lacking
>> documentation on missing functionality.

while i love the idea of real docs, i also guess there isn't much in
the way of resources / people / money / time to dedicate to doc making
and maintenance. so i'd say that personally i'd rather have really
well fleshed-out tests. unit and integration. that would give us
samples, and would help overall quality.

[Joshua Granick]

Documentation is valuable. Samples, recipes and blog posts are also a form
of documentation which can help provide results quickly. Thorough
documentation takes a lot of time, but in the end is valuable. NME could
use a lot of documentation, especially for introducing the concepts from
Flash we may take for granted, such as the display list, events and other
aspects of the API.

I agree that you ideally want teachers -- these should be people who are
experienced in the topic, but are also able to turn around and share that
knowledge with others. The best kind of teachers, in my opinion, are those
who have a foot in both sides of the subject. They are knowledgeable
enough to provide clear "best practices" and insight on the vital
knowledge required to use the language or framework. However, they
obviously need time to spend writing blog posts, samples and
documentation, and should (hopefully!) enjoy their time while they do so..

I think there are two kinds of documentation. You need "Get Started"
material to launch developers into full working samples of various
functionality, but then you also need the comprehensive material (the
encyclopedia of sorts) that really covers everything.

I have been thinking about this subject, and have decided that the best
approach to the "dictionary" style documentation is to generate it from
the code. This would be a matter of time to markup comments throughout
each class, but also put a priority on generating readable, accessible
documentation using haxedoc, chxdoc or whichever library is used to create
the output.

We still need to be able to support inline examples, match documentation
for method parameters, create nicer, easier to navigate and read
templates, and other aspects on the technical end to support
dictionary-style documentation that's worth reading.

[Jason O'Neil]

For the "dictionary" style documentation I think in-code documentation
is definitely the easiest to maintain and keep up to date and so I
would like to see this path taken.

The Xml output haxe generates (and haxedoc uses) could be passed in a
more useful way. A few ideas:

* Understanding basic Javadoc syntax, so we can style parameter
descriptions etc.
* Passing comments as Markdown, so we can style, add links, add code
examples etc.

If we allowed the in-code documentation to be more expressive, as well
as comments on the API page (now enabled for standard library on
haxe.org) we could start getting a more thorough documentation. I also
think any improvements we make for documenting the standard API should
be available to haxelib projects that upload their XML file.

TLDR: I'm all for in-code documentation + comments.

[Tim Keir]

One area possibly scaring off new adopters is the false positive virus warning from certain common AntiVirus vendors (e.g. Norton). I know it's stated on the download page, but making the user decide to trust an open source community they might not be familiar with yet over a reputable software company (e.g. Symantec) is a tall ask.

I have Norton AV installed on my work computer as part of company policy. In the past disabling the AV while you installed was straight forward but with the 2.09 release (or possibly an AV software update) it not only gave a false positive for the Haxe installer, but after disabling AV and successfully installing it and using Haxe for the rest of the day, upon my next reboot it had silently deleted the haxe.exe as it seemed to have kept track that the "compromised" installer had installed it. After re-installing it and manually whitelisting haxe.exe, neko.exe, etc I was up and running again. Certainly not a smooth experience if this was the first time I had tried Haxe. I've emailed Symantec but I haven't heard back.

Is this false positive issue fixable by a change in the way the installer is set up or is contacting the AV vendors the only solution?

On Tuesday, 8 May 2012 19:16:50 UTC+10, Nicolas Cannasse wrote:

Hi all,

Welcome to [haxenext] group, a place where we will discuss how to bring
Haxe to the next level.

As I explained in my invitation this is an open group, feel free to
invite anybody interested in helping in making Haxe grow and become more
popular. We are especially looking for people investing in Haxe with a
long-term vision.

In order to get started I have a simple question to ask you :

   What would be for you the top 3 things that we need to fix/improve
   to make Haxe more popular ? (in order of decreasing importance)

Please be very precise while answering this question. For instance
"improving the website" is bit too much abstract.

You're welcome also to provide an actual action-plan proposal that we
could follow in order to make it happen.

Based on your answers we will discuss what needs to be done first, and how.

Thank you !

Nicolas

On Tuesday, 8 May 2012 19:16:50 UTC+10, Nicolas Cannasse wrote:

Hi all,

Welcome to [haxenext] group, a place where we will discuss how to bring
Haxe to the next level.

As I explained in my invitation this is an open group, feel free to
invite anybody interested in helping in making Haxe grow and become more
popular. We are especially looking for people investing in Haxe with a
long-term vision.

In order to get started I have a simple question to ask you :

   What would be for you the top 3 things that we need to fix/improve
   to make Haxe more popular ? (in order of decreasing importance)

Please be very precise while answering this question. For instance
"improving the website" is bit too much abstract.

You're welcome also to provide an actual action-plan proposal that we
could follow in order to make it happen.

Based on your answers we will discuss what needs to be done first, and how.

Thank you !

Nicolas

On Tuesday, 8 May 2012 19:16:50 UTC+10, Nicolas Cannasse wrote:

Hi all,

Welcome to [haxenext] group, a place where we will discuss how to bring
Haxe to the next level.

As I explained in my invitation this is an open group, feel free to
invite anybody interested in helping in making Haxe grow and become more
popular. We are especially looking for people investing in Haxe with a
long-term vision.

In order to get started I have a simple question to ask you :

   What would be for you the top 3 things that we need to fix/improve
   to make Haxe more popular ? (in order of decreasing importance)

[Joshua Granick]

Have you experienced any problems with the NME installer?

[Tim Keir]

Good point, the NME installer is built upon the Haxe installer isn't it?

I don't believe so, the NME installer exe certainly doesn't trigger any warnings in Norton. I had already white listed C:/Motion-Twin when I installed NME so not sure whether installing without would change anything. I'll give it a go tomorrow at work and let you know.

[Nicolas Cannasse]

Le 31/05/2012 06:42, Tim Keir a écrit :
> One area possibly scaring off new adopters is the false positive virus
> warning from certain common AntiVirus vendors (e.g. Norton). I know it's
> stated on the download page, but making the user decide to trust an open
> source community they might not be familiar with yet over a reputable
> software company (e.g. Symantec) is a tall ask.

I've removed the two warnings about virus warning and the other about
installation path. I think Joshua 2.09 installer is fixing both issues
which were only related to the old installer.

Best,
Nicolas

[Skial Bainn]

I wrote Hocco which is a port of Docco, which allows you to write github style markdown. Take a look at the generated output for Hocco's twin source. Hocco was actually very easy and quick to write, which surprised me.

It uses pygments and markdown2 python libraries on google app engine, as I wanted everything to be contained in the library.

It could/should be updated to use either Jason's mdown lib or Nicolas's markaxe lib, which would get rid of the markdown2 server. It hasn't yet been tested against the latest haxe release, so it might not work any more. 

But something better can easily be built, so Hocco should be seen as a proof of concept.

--

Skial

http://about.me/skial

https://github.com/skial

http://blog.skialbainn.com

[Nicolas Cannasse]

Le 31/05/2012 05:07, Jason O'Neil a écrit :
> For the "dictionary" style documentation I think in-code documentation
> is definitely the easiest to maintain and keep up to date and so I would
> like to see this path taken.
>
> The Xml output haxe generates (and haxedoc uses) could be passed in a
> more useful way. A few ideas:
>
> * Understanding basic Javadoc syntax, so we can style parameter
> descriptions etc.
> * Passing comments as Markdown, so we can style, add links, add code
> examples etc.
>
> If we allowed the in-code documentation to be more expressive, as well
> as comments on the API page (now enabled for standard library on
> haxe.org) we could start getting a more thorough documentation. I also
> think any improvements we make for documenting the standard API should
> be available to haxelib projects that upload their XML file.

Check http://haxe.org/manual/documentation, and in particular chxDoc
http://code.google.com/p/caffeine-hx/wiki/ChxDoc

Best,
Nicolas

[Andras Csizmadia]

"What would be for you the top 3 things that we need to fix/improve
   to make Haxe more popular ? (in order of decreasing importance)"

0. Background and needs: I'm a senior multimedia developer, mostly i'm creating flash web applications / interactive solutions for online media campaigns.
    The interesting thing for me in HaXe is to create RIAs targeting both desktop and mobile browsers, using only one core codebase. So i can compile my software to Flash or HTML5 JS application, and use fallback techniques to solve flash on mobile issues (Thats why NME started me to really dig into the HaXe language).
    Also making native mobile/desktop apps and games is an interest. I've some experience with Adobe AIR and i'm not impressed by it's performance in many use cases.

--

1. "Integrate the brands": Create an organization on GitHub like "Haxe" and put HaXe sources there, also NME sources.
    For me it's a bit confusing to think with more brands at once and sell them to my clients (HaXe, NME, Jeash, Neash) so i would consider a name like HaXe SDK ("target any platform natively") which consists of the compiler + official nme framework.
    According to this, close obsolete domains and redirect users to a centralized area to be communicate or report bugs (i like haxenme.atlassian.org). Make it more strict for the users where to report bugs, right now there are around 5-10 places where i found issue reports.
    (+ Maybe integrate NME installer with Haxe)

2. Impressive examples for the clients. I like:
   http://flex.org/tour/
   http://flex.org/tour-de-mobile-flex/
   http://examples.adobe.com/flex3/componentexplorer/explorer.html
   Of course haxe showcase would be different kind. Ideally every example on every targeted would look like and work as same as its realistic.
   Actuate example: https://s3.amazonaws.com/data.tumblr.com/tumblr_lodu03EdFK1qzljg6o1_1280.jpg

3. Big focus on JS HTML5 output, improve Jeash part of NME as fast as possible.
    I want some kind of a way to easily implement a complex! design layout (made by a creative guy in .psd format).
    My usual workflow with flash:
    1. Optimize the psd (flatten and change layers which cannot be imported to Flash IDE)
    2. Import psd into flash
    3. Structure design object trees, make classes from view pages
    4. Compile FLA to SWC
    5. Use SWC classes in Flash AS3 only project as a Views
    If i want to cross compile a Flash and JS project i want to have some common practice to do this. (Pixel precise design is a standard in many companies).

Best Regards

[Andras Csizmadia]

FYI, i like this new concept of Flex:
http://www.fusecollective.com/apache-flex/website_v1.jpg
http://www.fusecollective.com/apache-flex/website_v2.jpg

[Joshua Granick]

For a long time, the Haxe installer has been written in Neko, and compiled for Windows, Mac and Linux.

The first version of the NME installer was built on the same code, but there were some issues (virus warnings, proxy issues on Mac, incompatibility on Linux) that led to the creation of new, specific installers for each platform.

The NME installer, for a few versions now, has been using the Nullsoft Scriptable Install System, or NSIS, which is the same installer used by FlashDevelop. The Mac installer uses Apple's PackageMaker, and the Linux installer is a bash script.

The current Haxe installer for Windows may be using NSIS, similar to NME. I'm not sure if you've received warnings with the previous version (which is like a console window) or the newer one (which has multiple steps, similar to normal Windows installs)

[airfoil]

On Tuesday, May 8, 2012 2:16:50 AM UTC-7, Nicolas Cannasse wrote:

In order to get started I have a simple question to ask you :

   What would be for you the top 3 things that we need to fix/improve

I've been following Haxe on and off for a few years, but over the last 7 months or so I've been actively following development (mainly due to NME). The biggies for me are:

* A standard UI Toolkit/Framework - This is the one thing that's kept kept me from completely adopting Haxe for a UI heavy game that I've been working on. I've written some of the game logic in Haxe and I've really enjoyed it. I started down the path of writing UI widgets that I needed, but I'd rather just write my game. The allure of my app running natively on the desktop and mobile keeps me interested in Haxe and NME, but I'm evaluating other languages/frameworks and at some point I have to stop evaluating and start shipping.

* With respect to documentation, more discussion and examples for macros. I kind of "get it", but I'd really like a deeper understanding of how things work. I learn best by seeing well explained examples and going from there. A cookbook style presentation for macros would be awesome.

* Finally, "Why should I use Haxe?" or "Haxe for $LANGUAGE Programmers" article(s) would be great as well. What are the compelling reasons for using Haxe? As someone who's worked with numerous languages over the years I can see the pros and cons relatively easily. For someone who isn't as experienced it would be great to provide them with compelling reasons for using Haxe. I also agree that Haxe needs some evangelists out front speaking at conferences, making blog posts, and pushing the language to the next level. I've made a few posts on Hacker News and other places trying to spread the word, but I think Haxe needs the "Haxe Guy" that's known for evangelizing the language and tools.

[Philipp Klose]

In my opinion it would be great to improve these following things:

• Move all major source code (Haxe compiler, hxcpp, nme, ..) to central place. If you try sell Haxe to someone it always very confusing to grep the sources from a variety of different place. As said a few times Github would be perfect for this. (Git also would help to provide multiple versions, stable, nightly, experimental, etc.. and make it way more easies to contribute to the sources.)
• Improve/change the documentation. I really love the way Sencha is documenting their products (ExtJS, Sencha Touch). Example: Ext.tip.QuickTipManager Documentation They have all I need in one place: API Documentation with set of small examples for all major classes to see how this classes are used in the field, a guides sections with everything from "Hello World" to "something weird and really complex", and a section with more advanced examples. The cool thing about this is, that everything is managed from their sources. (API documentation is embedded into the source code [Quicktip Manager source], the guides are written in some markdown files). This way they could manage to keep documentation up to date and provide documentation for all the current versions of their products. (When Haxe version moves from 2 to 3 it would be great to have both APIs documented on the website.)
  This again is a point where having the sources on Github could be very handy. Adding documentation to source code and/or the website would be easy as "click fork" -> edit stuff -> "send pull request". (A good example how this could work is the progit book which is editable and translated via a git repository)
• Improve the JavaScript target. I think this is the Haxe target platform with the most potential to improve. This includes: We need wrappers for good JavaScript libraries instead of creating everything on our own (and there are a lot of them). I mean, not only externs with a lot of parameters which are typed "Dynamic", but rather to make this libraries feel more "haxish".
  I personally would like to see more love Haxe JavaScript on the server side, so common.js JavaScript output would be great. (This is a task which could be done by the community easily.)
• As a Linux user I would love to see an IDE which is usable. (Maybe somthing like could9, it would be cross platform and could be written in Haxe; again this could be a community project.) 

Philipp

[Cauê Waneck]

• 
  As a Linux user I would love to see an IDE which is usable. (Maybe somthing like could9, it would be cross platform and could be written in Haxe; again this could be a community project.) 

Cloud9-like Haxe is an awesome idea and would be an awesome project to tackle!

Maybe we could invest on that? I mean, finance its development? I'd be happy to donate money for this project.

Cheers

Cauê

[Philipp Klose]

I already spend a lot of time on researching, checking out the possibilities. It shouldn't be that hard.

My choices would be

• Ace as the editor, it already has support for Haxe, has a nice and complete API for everything to need to do and can be more or less easily extended
  
• Maybe: Ext.JS for all the other GUI stuff, since it is one of the best GUI frameworks available for JavaScript it's fast and flexible enough for a GUI of an IDE. Also there are already externs for Haxe.
• Possible node.js for the server. I am currently working with Juraj on some type safe wrappers for Haxe <--> node.js. We could benefit from the insane speed of websockets and/or socket.io for autocompletion and all other tasks.

Any other suggestions/ideas?

Last time I spend a lot of time with coffee-script and PHP and I am slowly moving back to Haxe as development language. I'm really sick of Gedit as my current Haxe "IDE" so this will happen sooner or later. If there are some resources provided to speed this up I would be very happy about that.

Philipp

[Franco Ponticelli]

I agree with your choices except for ExtJS. It is a wonderful library but the changes it requires to the generated JS scare me ... maybe it is irrational.

In any case I think you can cover most of your needs with JQuery UI and the new coming release adds interesting new widgets.

Franco

p.s. Reinventing the wheel and do it all Haxe (using Domtools?) is still my first choice ;) ... except for ACE which is too big of a project and too specific to justify a rewriting.

[Philipp Klose]

Reinventing the wheel is something the Haxe-people are really fond of ;-)

I based my choices on "which would be the fasted way to get something I could work with". I've used ExtJS a few times before (but never in combination with Haxe) and once you figured how things work it is just "write some GUI" instead of "mess with the DOM" which is why I like it. I don't really understand what scares you about it, although you are right most stuff could be done with jQueryUI.

More interesting. What features are required/needed? Maybe we should start some kind of list of what people expect from a Haxe specific GUI!

It started one here: https://gist.github.com/2876010

Philipp

[Juraj Kirchheim]

On Tue, Jun 5, 2012 at 5:42 PM, Franco Ponticelli
<franco.p...@gmail.com> wrote:
> p.s. Reinventing the wheel and do it all Haxe (using Domtools?) is still my
> first choice ;) ... except for ACE which is too big of a project and too
> specific to justify a rewriting.

My first choice too. I am actually working on my own wheel when I find
the time and hope to have some results within the coming months.

Still, I think any haxe-based cross-platform solution (even based on
externals to ACE and Ext) would be a huge step forward to better
tooling, since it would allow us to all work together and all benefit
from it. Also I think it's a powerful sign of maturity, if a language
provides a high-quality IDE (which takes time, but getting started is
the first step) written with the language itself, so this might
further help in selling Haxe.

Regards,
Juraj