Strategy Choice

[Nicolas Cannasse]

Hi,

I definitely agree with what Peter said.

There are definitely many things we can do better in Haxe, on my
different fronts.

Each of you have different needs and a different views of what would be
"the most important" for your own usage of Haxe. So do I.

But we should consider Haxe as-a-whole.

So before jumping to conclusions, let's try answering these questions
first :

- in which area can we convince the most users to join us ?

- what do we need to do to make them hear about us ?

- how to we present Haxe to them so they get excited about it ?

- what will be the top 3 show-stoppers for them when evaluation Haxe ?

- how do we address theses ?

If you think we should target frustrated JS devs, then try answering
these questions in this context. If not, then please answer as well :)

Best,
Nicolas

[singmajesty]

1.) Defining a need

The first step is defining a need that a developer may have. This varies between developers, and their comfort level with each technology.

I found NME when I needed a productive method of developing fast, native games for webOS. There was nothing else available. Although Haxe is a better environment than Javascript, in my opinion, most people don't think there is a problem with their (slow, unproductive) way of developing web applications. If you cannot convince someone that there is a problem, they will not be interested in solutions.

2.) Providing a clear solution

Part of the idea behind creating haxenme.org, and later haxejs.org, was to try and clarify messaging around solutions for problems a developer may face. After you identify a problem (like cross-platform games, or productive web application development), you need to be able to clearly communicate how this can be solved.

Hopefully no one is confused, they feel excited, and are interested in taking the next step.

3. ) First impressions

When someone decides to give it a try, you need to help them run a working example as quickly as possible.

Unless there is a very good reason, they should probably be able to download and install the software in one quick step. This is one reason why I am in favor of offline installers (which don't rely on ports or other network issues), and getting all the components you need installed at once. Hopefully it should work immediately after the install process completes.

Directing them to a cool sample (that works!) will immediately show them that the technology works, and it works on their computer. It opens the door for them to play and experiment from a place that they know will already work. This is when they may decide that they are willing to try out the technology as their solution, and commit further time to work with it and give it a try for their own ideas.

4.) End-to-end support

This is when "sweating the details" matters. As much as possible, it all should work without fuss. This is one of the reasons why the command-line tools have been so vital to NME's success. When it works -- even if the user's computer is misconfigured -- even if they are on an unpopular platform -- it continues to inspire confidence that the software is a viable solution.

Although I would love to think that if I bring a piece of software 98% of the way to the finish line, users will be understanding enough to help bring it across the rest of the way, that isn't really the case. If it doesn't work, they will probably assume it cannot be fixed. That begins to throw the whole project into question. NME is not perfect in this regard, but the more that the little details are taken care of, the more that the magic of "it just works!" resonates with users, and inspires excitement.

5.) Reducing barriers to entry

Everyone has their own way of working. Although there is value in providing recommendations, people want to be comfortable working the way they like. This is where platform support (Windows, Mac, Linux) and IDE support begins to matter more. Driving a solid IDE experience, with choices, allows users to slide into Haxe development from the other languages they are used to using. Now it is a blessing, not a pain, to work in a new language.

6.) What about my favorite _____?

Box2D, MySQL, SQLite, 3D, etc.

The more that desirable libraries are available, work as expected, and don't introduce unfamiliar APIs, the better.

[singmajesty]

Specifically,

I think that NME needs to continue to gain better documentation, even more lenient command-line tools, more showcase applications, and even more polish between targets, so everything works consistently.

I think there is a chance that Javascript developers may get interested if we offer solid (tested) support for the full API of popular libraries, like three.js, Sencha Touch and other libraries. Make that quality of life as great as possible. Make it easy to understand the "Haxe way" of writing the same applications. Highlight the benefits, and flush out some of the possible issues that affect some Javascript libraries, like file size.

I am working on creating tools to automatically generate bindings for C++ libraries. If we have automated tools to make popular C++ libraries fully accessible from Haxe, it could have huge potential.

Can you imagine if we are able to automatically generate Haxe classes from the Android API? From the iOS API? BlackBerry? Then what would happen if we created a cross-platform library that uses these classes under the hood, to bind them into a single cross-platform API?

Some of the biggest audiences for Haxe are developers who are using a programming a language (like Obj-C, Java, C++, JS) out of necessity, not because they like it. If we provide powerful (and mature) ways to deploy the same API across multiple platforms, the power of writing code once and having it work in multiple environments is incredibly powerful and cool.

[niel drummond]

My points. To market a language you need to solve a problem people have on another platform.

- server-side: build more serialization libraries/extensions between platforms, server side devs struggle to do inter-op between platforms since REST decided to become in-vogue. So, if you have avro, protobuf, messagepack and similar libraries working on more than simple primitive types, this would be a nice argument to developers for using haxe to interoperate. haxe is strong in multi-runtime issues, and it doesn't leverage this on the server side. 

  I would be wary of having haxe as a full stack server side language - there is a lot of infrastructure code missing that is often necessary to build scalable services, and building this code would fragment its implementation to particular runtimes where it's performance is acceptable, or the implementation is easiest. I mean bindings to NoSQL libraries, actor/STM concurrency libs, immutable collections, hot-swapping, automated deployment, development server environment, REPL, better library management etc etc. 

- javascript: IMO, having haxe-js code that can be used from javascript is essentially a sorely missing feature. It is possible with the flash-output and SWC/AS3, but doing this in javascript is not realistic, because native js getter/setters are still not being used (one must use Reflect.setProperty), extending haxe classes from javascript is not streamlined, and now it seems the motivation is to rewrite standard methods of core primitives in the STD lib at the compiler level. It won't motivate anyone to do haxe-js unless they switch over completely.

  The core stdjs types could be made quite useful now that covariance exists, perhaps by wrapping some using and macro magic around them, so that iterating and mangling the DOM is easier. Remoting seems to be a hidden gem with lots of potential, but ease of use, or programming semantics are not intuitive compared to competing libraries.

 

- gaming: well, I guess people are telling me every day what that should have... I dare not say anything lest it cause more hair loss...

Generally, I find developing with haxe compared to other languages I currently use regularly puts a lot of emphasis on static typing (which is great), but ignores some of the disadvantages: fragmentation of community libraries, incompatible libraries, duplicate but also incompatible code, re-inventing the wheel syndrome, and an overall lack of synergy. There are lots of ways to mitigate this, but the first is to see it as a problem. 

NME has managed to solve this by focusing rigidly on one common API. Maybe it's possible to have a dependency management tool that resolves according to the AST snapshot of the class/method API of one or more projects, thereby focusing development efforts according to an interoperable API, rather than individual arbitrary project and version dependencies.

- Niel

[Nicolas Cannasse]

Hi Neil,

I agree with you overall, and I think that's what we're talking about
here. Find the usages which makes Haxe great, and try to focus on these
so they become much more usable.

> Generally, I find developing with haxe compared to other languages I
> currently use regularly puts a lot of emphasis on static typing (which
> is great), but ignores some of the disadvantages: fragmentation of
> community libraries, incompatible libraries, duplicate but also
> incompatible code, re-inventing the wheel syndrome, and an overall lack
> of synergy. There are lots of ways to mitigate this, but the first is to
> see it as a problem.

It's indeed a problem, but it's more a human one than a technical one.

We need to put more visibility on "top" libraries so newcomers will tend
to contribute more to these instead of reinventing the wheel. Seems like
it works for NME at least.

Best,
Nicolas

[Hugh Sanderson]

Hi,

Yes, I think the success of NME is due to the fact that is is a *library* not a *platform*.  If fact, it is multi-platform.

So we are not trying to sell people HXCPP as a technology, we are selling them NME as a game-making library, which uses HXCPP on mobile.

So the same thing may go for , eg, php.  Rather than having a "haxe/php" homepage, have a "haxe webserver" page, which can be deployed on LAMP/Google Aps/etc.

The difficulty in this is the dedication required to get a required library "over the hump" and the problem of "too much choice" in API selection.

NME succeeded here, because I have been banging away at if for 4 years, and the choice of the flash API meant that I only had 1 major refactor (not counting jeash) rather that making huge changes in direction every 6 months, as is really tempting on most frameworks.

Another interesting point, is that I wonder if NME's longevity has prevented other (eg, pure opengl based) game libraries from flourishing.  This could be both good (stops fragmentation) but also very bad (we may be missing out on the best game library ever made).

I know there are some webserver libs out there, but is amazing how it is the little things that make the difference.  I think the turning point for NME was the install-tool.  After writing a blog post on "how to get it going on android", I realized it was a pain in the bum that could be 100% automated. And this is when the community (particularly Joshua) started to get its weight behind it.  So maybe this is also the answer for the web-server.  Having the installation/configuration/uploading tool may in fact be more important than a particular framework.  A sort of meta-webserver-framwork that "puts you on rails".

And the other point here is that is may require more than one person.  Not sure how many libraries have major contributions from multiple people.

So more generally, a solution might be to champion a "semi-official" library/engine for most of the use-cases (obviously still allowing people to write their own stuff).  Steal an API where possible, form some community consensus when not possible.  Make it simple enough that the basics are covered, but that the "style" is still open to the individual.  eg, the Flixel library on top of NME.  Make sure more than one person is committed for more than one year.

Well, that is my ramblings.

Hugh

[Jason O'Neil]

Interesting insights into NME, I can definitely see how those factors have helped it be successful...

As a haxe developer who pretty much hasn't used it for flash/nme, but rather for Javascript and server-side development, I feel like contributing my thoughts on those:

Javascript

There seems to have been a fair amount of interest in haxe/js lately.  I'm pretty committed to using this going forward (I already have a few projects on the go), so I'm happy to invest time into developing a good framework.

At the moment my Domtools library has gained a bit of attention without being finished yet, but this will provide a good foundation for building a UI toolkit and also for some pretty clean data-binding, which when used with Haxe will be super-slick.  Franco has expressed interest in joining his efforts from his DHX library, so whatever the love-child of these is might be a good base for a framework, combined with a basic MVC structure etc.

There is also the path of using externs, (ExtJS, angular, ember, backbone etc), but I find that for anything more complex than jQuery, the extern system becomes quite difficult to setup and maintain.  I was able to get some basic externs working for ExtJS, but the moment you try to do anything too complicated you begin hitting issues where the Haxe way of doing things doesn't fit with the Ext way of doing things.  A few newbie users have been burnt by this :(  Still, I know other people disagree and say don't re-invent the wheel.  I just want something more haxe-like for when I'm writing Haxe.

Server Side

I first came to haxe from a PHP background, and so have definitely found it's server targets helpful, though I haven't had experience and so am envious of the amount of tooling and libraries available for Django / Rails etc.  The big advantage Haxe has over these more mainstream frameworks is code sharing and remoting, etc.  I think it's worth pursuing a strong haxe server target still :)

So is it NodeJS, or PHP/Neko?  The paradigms are pretty different and I don't know how well a single framework would span across both.  Happy to be proved wrong though.

I think Ufront is probably the strongest candidate so far, but it's pretty evident from the mailing list that not many people are using it.  Whenever someone has asked about a problem the replies are few and far between.  If we can make it easier for existing Haxe users to start with it then we might get a few more users and more support.

To make this easier I've been working on a haxelib tool to help: https://github.com/jasononeil/uftool The idea being that you can easily set up a base project, add controllers, models, launch a dev server, install database tables etc.  Having an out-of-the-box admin interface based on your models would be cool as well (See Djangos: https://docs.djangoproject.com/en/1.4/intro/tutorial02/).  However, it's not paid work so it might be a while before it's ready...

Again I agree that making installation easy and having multiple people supporting it will be important.  If I'm going to be part of it I think I'll need to use it myself for a project so I have a vested interest in it.  Maybe even some of the haxe community sites could experiment with running this (eg tryhaxe.org).  That would make a good real-world-example that we can possibly share to expand the number of people using it.

Jason

[Nicolas Cannasse]

Le 28/05/2012 09:41, Jason O'Neil a écrit :
[...]
> *Javascript*

>
> There is also the path of using externs, (ExtJS, angular, ember,
> backbone etc), but I find that for anything more complex than jQuery,
> the extern system becomes quite difficult to setup and maintain. I was
> able to get some basic externs working for ExtJS, but the moment you try
> to do anything too complicated you begin hitting issues where the Haxe
> way of doing things doesn't fit with the Ext way of doing things.

Hi Jason,

I might be interested in knowing more about that. For instance this is
because we wanted to use JQuery with strict typing that I added the
@:overload feature.

There might be some additional tricks possible to do as well for other
libraries.

I think that's very important that JS developers "feel at home" with
Haxe. Not maybe the most hardcore ones, since they will mostly likely
prefer JS itself, but the ones that feel like they lost some great
things while moving to JS - such as completion and static typing.

It's nice to propose pure Haxe-oriented solutions such as DomTools, but
OTOH I think that - when it's relevant - having the most popular/useful
JS libraries directly accessible (and typed) with Haxe is also very
important.

> *Server Side
[...]

> So is it NodeJS, or PHP/Neko? The paradigms are pretty different and I
> don't know how well a single framework would span across both. Happy to
> be proved wrong though.

That's an interesting question :)

- PHP is nice for "backward compatibility" : a lot of shared hosting,
people know how to setup/maintain it, you feel "at home" if you've
already used it (and most people did I guess)

- Neko is quite powerful, integrates very nicely with Haxe, but I guess
it would require a lot more efforts to promote it as a new platform. One
of the selling points of Haxe is the ability to run on existing "proven"
platforms. Bringing our "own new platform" somehow negates this argument.

- NodeJS is interesting, and while I question some parts of its
architecture, I still can understand it has a lot of buzz right now.
However seems like one of the big part of this success is about using JS.

People coming from server-side programming are usually more interested
in structured programs than others. I guess we first need a good
framework that would assemble all the tools already available (Spod,
Temploc/Erazor, Dispatcher, etc.) with documentation and examples, and
that would run on PHP/Neko/Java/C#, that would already be a nice selling
point :)

> I think Ufront is probably the strongest candidate so far, but it's
> pretty evident from the mailing list that not many people are using it.
> Whenever someone has asked about a problem the replies are few and far
> between. If we can make it easier for existing Haxe users to start with
> it then we might get a few more users and more support.

UFront is nice, but is only a part of the framework. For instance I
think there's almost no relation between UFront and Spod.

> Again I agree that making installation easy and having multiple people
> supporting it will be important. If I'm going to be part of it I think
> I'll need to use it myself for a project so I have a vested interest in
> it. Maybe even some of the haxe community sites could experiment with
> running this (eg tryhaxe.org). That would make a good
> real-world-example that we can possibly share to expand the number of
> people using it.

I think that to make a good framework you have first to use it yourself
for some time, and as part of a team (not only you as the sole
developer). This makes sure that is works as expected even for the
people that didn't wrote it :)

At least, that's the way Haxe became better while used at Motion-Twin.

That's why I think it's important to have more companies using Haxe :
they are in that position to create or extend existing tools to bring
them to a better usability level, and maybe even write some
documentation for it :)

Best,
Nicolas

[Joshua Granick]

I also believe many JS developers are looking for support for existing
libraries.

The problem with Enyo, Sencha or possibly Ext.JS is the "factory" model,
which is incompatible with a class structure.

In order to create an object, it prefers a generic, definition object:


{ kind: "Button", label: "Hello World" }



...then at "runtime", you access the "real" instance:



$.button.setLabel ("HELLO WORLD!");



This has caused me to use two sets of classes for each object, like Button
or ButtonInstance, but it is still somewhat uncomfortable. At first I
tried to define both sets of values in one object, but then you have the
problem of calling constructors when the initial object (the generic one)
should be extra simple. Any additional methods or values on the prototype
have a tendency to blow things up and cause silent failures at runtime.

I have also worked with Javascript libraries that use a more traditional
approach to inheritance. Jo, for example, is not the most popular mobile
framework, but it works perfectly with Haxe.

[Chris D]

- in which area can we convince the most users to join us ?

It would be hard to get data on this. I am sure most people seem to thik;

• Flash developers
• JS developers
• Game Developers who would be interested in cross platform 2D games with nme ( would love to see hxgl for 3d )
  

As for myself I looked up haxe after not being satisfied with adobe, also from reading practical examples from http://www.joshuagranick.com/

- what do we need to do to make them hear about us ?

I think one of the biggest movers for people hear about haxe is it's evangelists, haxe.org should work to support them directly with tools and exposure. It is "word of mouth" spread from "successful" individuals and companies that is the blood of something to hit mainstream.

• Adobe has powerpoint http://www.adobe.com/flashplatform/evangelism_kit/ Inside there are some case studies of Challenge / Solution / Results for companies creating products, I am sure there are some case studies haxe can use. This is great ammo for convincing an investor mindset to use haxe. I have seen many slideshows of haxe that are similar to this, it would be good to see an official one.
  
• Also useful for bloggers etc is a media kit for vector images of logos / banners and promotions.

- how do we present Haxe to them so they get excited about it ?

Haxe needs to present itself as a stable, supported and active technology that produces great successful work.
Showcases, case studies, evangelists all need to be highlighted.

I like the sound of;
"Haxe is a multi-platform, open-source programming language that compiles to other languages natively" rather than "platforms" natively.
Or haxe is the babbelfish of programming languages ;)
 
- what will be the top 3 show-stoppers for them when they evaluation Haxe ?

Lack Support and future as no one company is backing it
Lack of tools and IDE Support
Learning Curve

- how do we address theses ?

I think Nicolas' thoughts on a Haxe Foundation will enable investors to have a bigger sense of "long term security" for the language. Also emphasizing that Nicolas is not the only one contributing to the compiler.

I have been using the php Drupal project for a while and there are many parallels.

• The beggings of drupal are from one developer creating a message board to a community of developers to a foundation.
• It is also still very developer not designer centric, but there is enough evangelists, huge companies, success stories "Grammy awards, Whitehouse websites" to see it's long term success and investment from a massive set of companies and developers.
• Drupal can also be seen as haxe as one solution to many problems and heated debates about its focus are a constant. Eg "it can be a blog, cms, ecommerce, mobile app database, etc".

I am not saying that haxe should jump to do what drupal does but I think its tasty food for thought;

http://groups.drupal.org
Where discussion/collaboration about drupal happens that helps solve the focus of the uses cases etc.
eg http://groups.drupal.org/drupal-commerce or http://groups.drupal.org/project-management

Currently for haxe I think people do this in the nme or haxe.org forums

http://drupal.org/project/modules - this is where all the "contrib modules" or in haxe terms Haxelibs happen.
Haxe libs works ok but the drupal project website has specific advantages such as;

• Drupal Version downloads http://drupal.org/project/services we dont know other than readme's and commit logs whether a haxe libs supports 2.08 or 2.09 etc
• Module issue / bug / feature requests http://drupal.org/project/issues/services?categories=All haxelibs does not have anything like this other than a link to the repository or developer
  

Enough of drupal :)

Haxe IDE support is getting better and this is obviously going to take time and hard work / community support for it to mature.

I think that the Learning Curve for haxe is only not a real issue but more of a perceived one of developers leaving their comfort zone to a compiled language.
Haxe is simple to learn, for simple projects. Evangelists can continue to help with this. Videos / side by side code examples help with this.

Although haxe is far more complex there is another parallel with how web developers have adapted Less and Sass for css. Developers who may not have ever of used a compiler(or known they have) or command line have gone out of their way to improve the workflow and syntax of css. I think http://www.haxejs.org/ can learn from the side by examples of http://lesscss.org/ and http://sass-lang.com/.


As still a relatively new haxe developer I will do my best to contribute in a "evangelist" website I am making :)

[Jason O'Neil]

+1 for side-by-side code comparisons. http://haxenode.org/ is already
doing this, and was part of the reason I was happy to give it a go the
first time. It also makes it much easier to understand it in the
context of the "native" documentation.

On Tue 29 May 2012 10:39:17 WST, Chris D wrote:
>
> - in which area can we convince the most users to join us ?
>
> It would be hard to get data on this. I am sure most people seem to thik;
>

> * Flash developers
> * JS developers
> * Game Developers who would be interested in cross platform 2D games

> with nme ( would love to see hxgl for 3d )
>
> As for myself I looked up haxe after not being satisfied with adobe,
> also from reading practical examples from http://www.joshuagranick.com/
>
> - what do we need to do to make them hear about us ?
>
> I think one of the biggest movers for people hear about haxe is it's
> evangelists, haxe.org should work to support them directly with tools
> and exposure. It is "word of mouth" spread from "successful"
> individuals and companies that is the blood of something to hit
> mainstream.
>

> * Adobe has powerpoint

> http://www.adobe.com/flashplatform/evangelism_kit/ Inside there
> are some case studies of Challenge / Solution / Results for
> companies creating products, I am sure there are some case studies
> haxe can use. This is great ammo for convincing an investor
> mindset to use haxe. I have seen many slideshows of haxe that are
> similar to this, it would be good to see an official one.

> * Also useful for bloggers etc is a media kit for vector images of

> logos / banners and promotions.
>
> - how do we present Haxe to them so they get excited about it ?
>
> Haxe needs to present itself as a stable, supported and active
> technology that produces great successful work.
> Showcases, case studies, evangelists all need to be highlighted.
>
> I like the sound of;
> "Haxe is a multi-platform, open-source programming language that
> compiles to other languages natively" rather than "platforms" natively.
> Or haxe is the babbelfish of programming languages ;)
>
> - what will be the top 3 show-stoppers for them when they evaluation
> Haxe ?
>
> Lack Support and future as no one company is backing it
> Lack of tools and IDE Support
> Learning Curve
>
> - how do we address theses ?
>
> I think Nicolas' thoughts on a Haxe Foundation will enable investors
> to have a bigger sense of "long term security" for the language. Also
> emphasizing that Nicolas is not the only one contributing to the compiler.
>
> I have been using the php Drupal project for a while and there are
> many parallels.
>

> * The beggings of drupal are from one developer creating a message

> board to a community of developers to a foundation.

> * It is also still very developer not designer centric, but there is

> enough evangelists, huge companies, success stories "Grammy
> awards, Whitehouse websites" to see it's long term success and
> investment from a massive set of companies and developers.

> * Drupal can also be seen as haxe as one solution to many problems

> and heated debates about its focus are a constant. Eg "it can be a
> blog, cms, ecommerce, mobile app database, etc".
>
> I am not saying that haxe should jump to do what drupal does but I
> think its tasty food for thought;
>
> http://groups.drupal.org
> Where discussion/collaboration about drupal happens that helps solve
> the focus of the uses cases etc.
> eg http://groups.drupal.org/drupal-commerce or
> http://groups.drupal.org/project-management
>
> Currently for haxe I think people do this in the nme or haxe.org forums
>
> http://drupal.org/project/modules - this is where all the "contrib
> modules" or in haxe terms Haxelibs happen.
> Haxe libs works ok but the drupal project website has specific
> advantages such as;
>

> * Drupal Version downloads http://drupal.org/project/services we

> dont know other than readme's and commit logs whether a haxe libs
> supports 2.08 or 2.09 etc

> * Module issue / bug / feature requests

[Jason O'Neil]

What if we had a way to write a custom constructor for an extern class?

extern class Button {
ￜￜￜ
ￜￜￜ public function new(myName, myColor) {
ￜￜￜ ￜￜￜ // whatever JS is required to setup new Button object...
ￜￜￜ ￜￜￜ return ButtonFactory.create({name:myName, color:myColor});
ￜￜￜ }

ￜￜￜ public var externProperty:Int;
ￜￜￜ public function externMethod();
ￜￜￜ
}

Would that help?

Jason

On 29/05/12 00:06, Joshua Granick wrote:

I also believe many JS developers are looking for support for existing libraries.

The problem with Enyo, Sencha or possibly Ext.JS is the "factory" model, which is incompatible with a class structure.

In order to create an object, it prefers a generic, definition object:


{ kind: "Button", label: "Hello World" }



...then at "runtime", you access the "real" instance:



$.button.setLabel ("HELLO WORLD!");



This has caused me to use two sets of classes for each object, like Button or ButtonInstance, but it is still somewhat uncomfortable. At first I tried to define both sets of values in one object, but then you have the problem of calling constructors when the initial object (the generic one) should be extra simple. Any additional methods or values on the prototype have a tendency to blow things up and cause silent failures at runtime.

I have also worked with Javascript libraries that use a more traditional approach to inheritance. Jo, for example, is not the most popular mobile framework, but it works perfectly with Haxe.





On Mon, 28 May 2012 02:59:00 -0700, Nicolas Cannasse <ncan...@motion-twin.com> wrote:

Le 28/05/2012 09:41, Jason O'Neil a ï¿œcrit :
[...]

*Javascript*

There is also the path of using externs, (ExtJS, angular, ember,
backbone etc), but I find that for anything more complex than jQuery,

the extern system becomes quite difficult to setup and maintain.ￜ I was

able to get some basic externs working for ExtJS, but the moment you try
to do anything too complicated you begin hitting issues where the Haxe
way of doing things doesn't fit with the Ext way of doing things.

Hi Jason,

I might be interested in knowing more about that. For instance this is because we wanted to use JQuery with strict typing that I added the @:overload feature.

There might be some additional tricks possible to do as well for other libraries.

I think that's very important that JS developers "feel at home" with Haxe. Not maybe the most hardcore ones, since they will mostly likely prefer JS itself, but the ones that feel like they lost some great things while moving to JS - such as completion and static typing.

It's nice to propose pure Haxe-oriented solutions such as DomTools, but OTOH I think that - when it's relevant - having the most popular/useful JS libraries directly accessible (and typed) with Haxe is also very important.

*Server Side

[...]

So is it NodeJS, or PHP/Neko?ￜ The paradigms are pretty different and I
don't know how well a single framework would span across both.ￜ Happy to
be proved wrong though.

That's an interesting question :)

- PHP is nice for "backward compatibility" : a lot of shared hosting, people know how to setup/maintain it, you feel "at home" if you've already used it (and most people did I guess)

- Neko is quite powerful, integrates very nicely with Haxe, but I guess it would require a lot more efforts to promote it as a new platform. One of the selling points of Haxe is the ability to run on existing "proven" platforms. Bringing our "own new platform" somehow negates this argument.

- NodeJS is interesting, and while I question some parts of its architecture, I still can understand it has a lot of buzz right now. However seems like one of the big part of this success is about using JS.

People coming from server-side programming are usually more interested in structured programs than others. I guess we first need a good framework that would assemble all the tools already available (Spod, Temploc/Erazor, Dispatcher, etc.) with documentation and examples, and that would run on PHP/Neko/Java/C#, that would already be a nice selling point :)

I think Ufront is probably the strongest candidate so far, but it's
pretty evident from the mailing list that not many people are using it.
Whenever someone has asked about a problem the replies are few and far

between.ￜ If we can make it easier for existing Haxe users to start with

it then we might get a few more users and more support.

UFront is nice, but is only a part of the framework. For instance I think there's almost no relation between UFront and Spod.

Again I agree that making installation easy and having multiple people

supporting it will be important.ￜ If I'm going to be part of it I think

I'll need to use it myself for a project so I have a vested interest in

it.ￜ Maybe even some of the haxe community sites could experiment with
running this (eg tryhaxe.org).ￜ That would make a good

real-world-example that we can possibly share to expand the number of
people using it.

[James Hofmann]

I'm in contact with a lot of indie game developers these days. I would categorize them into these groups:

1. Platform diehards - mostly concentrated in C++ users, but also seen with C#, Flash, Java, even JS. They want to use their favorite toolset forever, but they are also often rationalizing a prior investment.

2. Low awareness, "go with the crowd" developers. These are users of whatever tools and frameworks seem popular in their circles - e.g. SFML, XNA, Flashpunk, Unity. This is probably the most common group.

3. Low technical ability - many of the users of Game Maker, Flash IDE, Unity, etc. For these users code tends to represent a major hurdle and they want to get something running quickly, however I have observed that the majority of the benefit they're getting is essentially from having a game-focused  IDE, where coding features are mixed with asset-management features: placing objects in a scene, assigning graphics and collision properties, etc. Coding tasks still require code (and usually assistance with such.)

4. Pragmatists and long-term thinkers. These people have usually already looked at Haxe at least once. They haven't all bought in, but most of their concerns stem from maturity problems or project-fit, not fundamental issues with the technology.

5. Confused newbies. These are people who don't have strong enough ties to end up in group 2, and are motivated enough to want to be in group 4, but also don't have the background necessary to make good decisions, so they are in the unfortunate position of asking the wrong questions to solve problems they haven't actually encountered yet. They tend to either be scared about making a decision, or vastly overconfident.

Unsurprisingly, the group that has led the way so far is group 4. Group 5 gets scared away too easily because they're looking for social markers of adoption(popular game x uses Haxe!!) and Groups 1 and 3 don't want to hear about a new language. Group 2 is a bit more interesting, because they usually aren't against the idea of switching, but they need to be prodded to go out and try something new.

But when I look at what they're thinking about, I get the impression that there's a general model to apply in terms of "what to develop to make the platform maximally valuable," vs. other marketing/evangelical efforts, and it could apply for any domain, not just gaming:

Build a lot of "boring" stuff. This is the stuff that ships product - support for file formats, utility code, algorithms, etc. It's been done before, but the important thing is that when the boring thing is also somehow a substantial improvement on the old and reduces the amount of patchy, ugly complexity, it becomes exciting. Rails didn't solve an intrinsically cool or sexy problem, and Haxe and NME don't, either. But because they took the overall quality of the solution to another level, they became a little more exciting by default, and win adoption from the pragmatic developers, who subsequently seed changes that can gradually bring in the other groups.

My role model for making boring sexy is STEPS: http://www.vpri.org/pdf/tr2007008_steps.pdf (and yearly updates available from http://www.vpri.org/html/writings.php) - by taking things that have been solved and then trying to envision a drastically simpler solution, they're managing to demonstrate an unheard-of amount of productivity, compactness, and efficiency. Bringing even a tenth of that magic to "real world" computing would bring in a huge amount of interest.

In my triad library ( https://github.com/triplefox/triad/tree/master/dev/com/ludamix/triad ) I've been attacking a lot of boring problems in similar terms of simplification, but I stumbled into taking on one with a ton of opportunities, which is real-time synthesis in the browser. You may have seen the demo I had a few weeks ago, which I've kept incrementally improving: http://www.ludamix.com/apps/triad-synth/index.html There are a lot of little synth demos floating around the net, but most don't aim to build out a complete framework usable for gaming or other interactive systems. But I decided to head in that direction with the "boring first" approach - making an adequate sequencer, an adequate sampler, etc. and I'm finding that I'm getting good results, even though I'm pretty out of my depth with any serious DSP work; I can keep my featureset small, run little experiments, copy when there are areas I don't understand, and focus primarily on refinement of a few "cornerstone" aspects and try for a high level of day-to-day usability. My theory is that this will eventually attract skilled users from the problem domain to contribute some features. Indeed, when I look at the overall "web audio" ecosystem it makes more sense to go small, because at least with HTML5, most of the heavy processing is going to be done from browser APIs anyway.

[Joshua Granick]

It is possible that would help.

The real problem is when you get into inheritance, or having a constructor
defined. For example, Enyo will use any method you have defined on your
"simple" object, so if you have a constructor, it will use that instead of
the real one... which doesn't work out well.

We really need a way (in this scenario) to define objects with "optional"
properties.

Something like:



typedef Button {

var height:Float;
var label:String;
var width:Float;

}


...


var hi = new Button ();
hi.height = 30;
hi.label = "Hello World";
hi.width = 100;


... (or) ...


var settings:Button = { label: "Hello World" }



If you try something like this today, it will throw an error, because not
all of the properties are defined. It is for this reason that some kind of
"optional" object, which provides completion for the "suggested"
properties and methods, would be useful. I think there may have been some
discussion on this for Haxe 3.0... or was there something in Haxe 2.09?
Maybe like this?


typedef Button {

var ?height:Float;
var ?label:String;
var ?width:Float;

}






On Mon, 28 May 2012 19:58:04 -0700, Jason O'Neil <jason...@gmail.com>
wrote:

> What if we had a way to write a custom constructor for an extern class?
>
> extern class Button {
>

> public function new(myName, myColor) {

> // whatever JS is required to setup new Button object...

> return ButtonFactory.create({name:myName, color:myColor});
> }
>

> public var externProperty:Int;
> public function externMethod();

>
> }
>
> Would that help?
>
> Jason
>
> On 29/05/12 00:06, Joshua Granick wrote:
>> I also believe many JS developers are looking for support for existing
>> libraries.
>>
>> The problem with Enyo, Sencha or possibly Ext.JS is the "factory"
>> model, which is incompatible with a class structure.
>>
>> In order to create an object, it prefers a generic, definition object:
>>
>>
>> { kind: "Button", label: "Hello World" }
>>
>>
>>
>> ...then at "runtime", you access the "real" instance:
>>
>>
>>
>> $.button.setLabel ("HELLO WORLD!");
>>
>>
>>
>> This has caused me to use two sets of classes for each object, like
>> Button or ButtonInstance, but it is still somewhat uncomfortable. At
>> first I tried to define both sets of values in one object, but then
>> you have the problem of calling constructors when the initial object
>> (the generic one) should be extra simple. Any additional methods or
>> values on the prototype have a tendency to blow things up and cause
>> silent failures at runtime.
>>
>> I have also worked with Javascript libraries that use a more
>> traditional approach to inheritance. Jo, for example, is not the most
>> popular mobile framework, but it works perfectly with Haxe.
>>
>>
>>
>>
>>
>> On Mon, 28 May 2012 02:59:00 -0700, Nicolas Cannasse
>> <ncan...@motion-twin.com> wrote:
>>

>>> Le 28/05/2012 09:41, Jason O'Neil a écrit :
>>> [...]
>>>> *Javascript*
>>>>
>>>> There is also the path of using externs, (ExtJS, angular, ember,
>>>> backbone etc), but I find that for anything more complex than jQuery,

>>>> the extern system becomes quite difficult to setup and maintain. I

>>>> was
>>>> able to get some basic externs working for ExtJS, but the moment you
>>>> try
>>>> to do anything too complicated you begin hitting issues where the Haxe
>>>> way of doing things doesn't fit with the Ext way of doing things.
>>>
>>> Hi Jason,
>>>
>>> I might be interested in knowing more about that. For instance this
>>> is because we wanted to use JQuery with strict typing that I added
>>> the @:overload feature.
>>>
>>> There might be some additional tricks possible to do as well for
>>> other libraries.
>>>
>>> I think that's very important that JS developers "feel at home" with
>>> Haxe. Not maybe the most hardcore ones, since they will mostly likely
>>> prefer JS itself, but the ones that feel like they lost some great
>>> things while moving to JS - such as completion and static typing.
>>>
>>> It's nice to propose pure Haxe-oriented solutions such as DomTools,
>>> but OTOH I think that - when it's relevant - having the most
>>> popular/useful JS libraries directly accessible (and typed) with Haxe
>>> is also very important.
>>>
>>>> *Server Side
>>> [...]

>>>> So is it NodeJS, or PHP/Neko? The paradigms are pretty different and

>>>> I
>>>> don't know how well a single framework would span across both.

>>>> between. If we can make it easier for existing Haxe users to start

>>>> with
>>>> it then we might get a few more users and more support.
>>>
>>> UFront is nice, but is only a part of the framework. For instance I
>>> think there's almost no relation between UFront and Spod.
>>>
>>>> Again I agree that making installation easy and having multiple people

>>>> supporting it will be important. If I'm going to be part of it I

>>>> think
>>>> I'll need to use it myself for a project so I have a vested interest
>>>> in

>>>> it. Maybe even some of the haxe community sites could experiment with
>>>> running this (eg tryhaxe.org). That would make a good

[Richard Blakely]

Hi Everyone, 

My take on the q's from Nicolas;

- in which area can we convince the most users to join us ? 

>> Infinite Adaptability. Your 1 code base will work forever...

- what do we need to do to make them hear about us ? 

>> Show evidence that backs the claims of the argument.

- how to we present Haxe to them so they get excited about it ?

>> Case studies are compelling.

- what will be the top 3 show-stoppers for them when evaluation Haxe ? 

>> Proof of success, reliability, and sustainability.

>> Training/Deployment Costs

>> Long term risks/costs

- how do we address theses ? 

>> Yes, we do.


Just Ideas, thank everyone!

-Richard

On Friday, May 11, 2012 11:40:09 AM UTC-7, Nicolas Cannasse wrote:

[Lee Sylvester]

Hey Richard,

 

Not sure you read that third point properly ;-)   Personally, I think we can target those last points by providing companies with the knowledge to overcome them.  Companies like Influxis, essentially, where the language is used in the workplace to make things happen and where a good corporate image is portrayed.

 

Lee

[Richard Blakely]

Hey Lee,

A company's first impression and understanding from the moment they research what "what is haxe" will be the key to its dominance. If we have a simple, powerful argument, some great case studies to back up the claims, and a well built knowledge base and community. There is no reason why Haxe wouldn't at least have to be considered when a company is beginning a project.

I agree, corporate case studies would be the best, the larger the company the better... Discussing how it they've integrated haxe into their work flow and the benefits they experienced.

Where to go next? the foundation, updating the website, case studies, enterprise quality knowledge base and training...

-Richard


________________________________________
From: haxe...@googlegroups.com [haxe...@googlegroups.com] On Behalf Of Lee Sylvester [lee.sy...@googlemail.com]
Sent: Saturday, August 11, 2012 6:15 AM
To: haxe...@googlegroups.com
Subject: RE: [haxenext] Re: Strategy Choice

[Lee Sylvester]

I agree entirely. It does make me think of the Ruby situation, though. Ruby had a huge take surge after the success of Basecamp. I think such a corporate success with Haxe would have the same effect

Lee

[Tero Tolonen]

Two questions asked by my friends, who are very experienced software pros, when I told them about Haxe:

1. Does it have good IDE?
2. How peculiar code it produces?

[Chad - Bible Us]

in which area can we convince the most users to join us ? 

For me I've had haxe on my radar for a while, i downloaded it a few times and messed with it. I think for me the fact I am calling it it addresses the problem. As a new user, my impression of haxe is that with it I can download it, open it in some IDE write some JS styled code, and export to any language. But when I try to start down the path, I get lost at step 1, and give up at step 2.

We need a packaged thing that we can just download and press go. And see it work, a proof of concept. Then once we are convinced of the concept we are more likely to play. But if it takes more than 10 hours just to get to see a proof of concept, that is where you are loosing people. 

I think a unified approach from the community would also be good. This leaves us noobs not really knowing what way to turn. Over here you have a kickstarter ide, over here you have a github with a small description called "interns" over here you have the source code of haxe, which is even more mind blowing. Where do I start. I can't afford too many development hours setting up a new system that will give me more bang per line of code, but I can spend some...keep me convinced along the way that this is "right" for me and my needs. So maybe even a section when to use haxe?