About Strategy Choice

[Cauê Waneck]

Hey! I just changed the title so I wouldn't make noise in the main topic

I definitely agree with what Peter said.

In my view it's a little strange to to be so specific about a programming language, specially like Haxe. I've never seen e.g. Python defining itself as a "web language", or anything like that at all. It seems to me that this is something we should work on various "main" fronts, not market only one. For example, a friend of mine works as a consultant for transport planning / management, and he uses Haxe for all his work. He used to do it with C++, and I showed him how much more productive he would be in Haxe. He ended up developing some amazing libs, like http://code.google.com/p/jonas-haxe/ .

Anyway, I don't know if I could have convinced him if he entered the Haxe website and it was all about e.g. a better javascript.

The way I see it is that the focus idea should be for specific libraries, for example NME for games (like PlayN), or some kick-ass lib for writing server-side web development.

But not because e.g. NME is good for games that Haxe is only a "gaming platform".

Am I getting it wrong?

Cheers!

Cauê

[Peter Halacsy]

On Fri, May 11, 2012 at 8:58 PM, Cauê Waneck <wan...@gmail.com> wrote:

Hey! I just changed the title so I wouldn't make noise in the main topic

I definitely agree with what Peter said.

In my view it's a little strange to to be so specific about a programming language, specially like Haxe. I've never seen e.g. Python defining itself as a "web language", or anything like that at all. 

http://www.python.org/doc/essays/blurb.html

easy to learn, rapid to use  

[Cauê Waneck]

http://www.python.org/doc/essays/blurb.html

easy to learn, rapid to use  

Ah, I see, makes sense, but it's very broad, isn't it? Could it be considered a marketing strategy?

On those terms I would say Haxe is something like:

Get native performance with a familiar language, and use the best platforms for the job.

Meaning: it's fast, easy and familiar to use, and you have the flexibility to choose the platform which best fit your job. And even choose more than one and communicate seamlessly between them.

Am I doing this right? :)

[Nicolas Cannasse]

Le 11/05/2012 21:11, Cau� Waneck a �crit :

> Meaning: it's fast, easy and familiar to use, and you have the
> flexibility to choose the platform which best fit your job. And even
> choose more than one and communicate seamlessly between them.
>
> Am I doing this right? :)

You got good points here ;)

- familiarity : Haxe does not try to invent "YAKS" (yet another kryptic
syntax). You feel at home if you already did some
Java/JavaScript/PHP/AS3/etc.

- flexibility : by allowing you to target all the mainstream platforms,
you can always use the right tool for the job, and still keep building
your experience with the language. No more vendor lockin, pure freedom

But both of these apply to individual developers, not to companies that
want to know what is the business point of Haxe, which is also something
we need to address.

Best,
Nicolas

[Philippe Elsass]

Nicolas and Caue, most people use whatever language (even JS and Obj-C) if it allows to do the job efficiently.

Le 11 mai 2012 23:26, "Nicolas Cannasse" <ncan...@motion-twin.com> a écrit :

[Robert Bąk]

They do, but the overall efficiency of coding is going down, if you have to rewrite an app for 2 systems in different languages it's already at least twice the amount of work and code to maintain. 

I think "Don't repeat yourself" as a software development principle has been totally lost in the recent years, first because the web started copying more and more functionality which used to be server side to the browser (eg. form validation), and now because everyone wan't to sell your app only in their mobile store for their mobile system, and have no business in making the porting to other ones easy. And people can see the advantages, everybody wanted server-side as3 for years, there's node-js (and why else would you want to use as3 or JS on the server?).

The problem is how to show the advantages that Haxe has over the other solutions. I think the important things are that you can target so many popular environments (so a Flash dev, who learns Haxe to do JS, can reuse that back in Flash, but also on the server doing PHP, and is nicer to work with than any of them) and that the compiler translates the code instead of wrapping it with a runtime environment. This makes it a kind of Rosetta Stone for code, once you have it, all the languages you might need start making sense together.

--
   Pozdrawiam
   Robert Bąk

[Philippe Elsass]

What I mean is that the lang itself, or the fact it has many targets, isn't the entry point for newcomers. 

Of course, if a Flash dev is convinced to use haxe for JS/NME he may decide to use haxe for Flash dev too, but he won't chose haxe "because" he can use it back for Flash. 

The big deal is first to make him switch to haxe for JS/NME, and for that he must find it as easy to use haxe+EaselJS (not a hello world, but something he can build a project with) than creating a new AS3 project in his IDE. And that's why I'm working on a display list abstraction of NME's drawTiles so newcomers don't have to figure how to use it best.

--
Philippe

[Dom De Lorenzo]

Hi all,

I've been thinking about this a fair bit over the weekend:

For most developers (and businesses) 'multiplatform' is probably not the first hook. They will evaluate/select Haxe based on relative efficiency and expressiveness on their existing platform. If/once that step is made, then multiplatform is often a natural progression. Our strategy needs to encompass the value of using Haxe for 'any platform' rather than just the value of 'many platforms'.

Multiplatform is also the hardest sell on the business side. With virtually every potential customer I've talked to about multiplatform, the number one question is always around the assumption of bloat/innefficiency. Our strategy needs to tackle the ingrained stereotype that generated code is always inefficient code. 

Multi-platform/platform agnostic code is core to Haxe's value proposition and also its key point of difference. I don't think our goal needs for us to be more like language X or language Y, but rather the best option for developing X or Y or both.  

Our strategy should consider that users should be able to leverage the value of multiplatform in innovative, strategic and pragmatic ways (reusing/sharing parts of code where appropriate, rather than just a blanket 'write once...'  ).

So far my best attempt to distill this down is something along the lines of - "The best/most expressive way to target any native platform"

The two key elements being:

-  'any' implying both singular or multiple, and

- 'native' implying like-for-like performance as well as seamless interoperability with existing native content 

This kind of goal can be applied to immediate tasks (like improve the quality/accessibility of Haxe for specific platforms - e.g. better targeting native JS developers) as well as the longer term positioning/aspiration of the platform.

Cheers, 

Dom

P.S. Robert - I love the rosetta stone analogy.

Sent from my iPhone - apologies for any tpyos!  

[Cauê Waneck]

Hi Dom!

So far my best attempt to distill this down is something along the lines of - "The best/most expressive way to target any native platform"

I like the way you are thinking, and I really like how this catch phrase is turning out!

This kind of goal can be applied to immediate tasks (like improve the quality/accessibility of Haxe for specific platforms - e.g. better targeting native JS developers) as well as the longer term positioning/aspiration of the platform.

Agreed! :) I'm open to suggestions on how to proceed with the Java and C# ones. I'm thinking about having a flag, like -native which will disable inlining, add -rtti-docs and add the docs to the output as well, generate the code with proper access control (protected), without any added generated code (for fast reflection), etc. - so the generated code can be used along with native code.

Cheers!

Cauê

[Nicolas Cannasse]

> So far my best attempt to distill this down is something along the lines

> of - "The best/most expressive way to target *any native platform*"

>
> The two key elements being:

> - '*any*' implying both singular or multiple, and
> - '*native*' implying like-for-like performance as well as seamless

> interoperability with existing native content

Could also be "target *any* platform *natively*"

I understand your point of view, but I think trying to explain how Haxe
is better for any platform will be hard.

I was also thinking quite often about the discussions we're having
there. Haxe can do so many things already, and keep improving by adding
new platforms/features. I think it is then very hard to know what are
the expectations of someone who land on haxe.org (for instance).

Maybe we should divide the whole communication/website into several
sections, each would be finely tuned to sell Haxe to a target group of
users.

For example, you go on haxe.org and you see :

Haxe : target any platform natively
(that's our motto, our mission)

Then we can have some menu on the homepage so the user can make a choice
between one of these four :

- How to create crossplatform games with Haxe/NME
focused on game developers to develop mobile games

- Web development in the large with Haxe/JS
focused on people which want to write scalable JS apps

- Deploying Haxe in your Company
focused on decision makers in companies

- Everything you can do with Haxe
for the rest of the people, a set of Q&A / items which
will redirect to the different other Haxe usages / site content

What do you think ?

Best,
Nicolas

[Joshua Granick]

Perhaps the BlackBerry Developer site is a good example:


http://developer.blackberry.com



They are able to split their development into separate communities, with
unique messaging. Of course, we use the same programming language for
every type of development, but I still think the same principle (like you
are talking about) could be useful.

There are (in my mind) at least three demographics:


- Flash developers who want to write native games, or play with HTML5.
Similarity with AS3 and the Flash API is a huge benefit. These are the
developers who will (or should) love NME.

- Javascript developers who want the language features we have to offer.
It has no connection with the Flash API, and is not intended to function
cross-platform. The point is that it makes you more productive, helps you
create large projects, and just makes web development better.

- Server-side development, either sharing logic with the front-end, or
leveraging Haxe as a "better" way to manage databases, or to write for PHP
or Node.js



This does not cover all of the community, as there is still more you can
do with the language, but I think these are distinct communities that need
very different messaging to grow excited about what they can do using the
Haxe language.

I am not as familiar with the server-side crowd, but the game and
application development group is looking for a solid baseline (like NME),
a small number of familiar libraries (like Actuate or Box2D) and sometimes
a framework (like Flixel, awe6, or if we had an app/GUI framework)

The JS crowd seems to be interested in small, disconnected libraries.
Sometimes it seems hard to convince these developers that a compiled
language like Haxe (that is not utterly untyped) will make them more
productive. I used to think that way before I settled into AS3
development, largely with the help of FlashDevelop. The Flash IDE never
really showed you that classes and strong types were better :)


So this comes back to documentation, library support and more mature IDE
choices. I'm not sure if this is better served as separate sites
(haxenme.org, haxejs.org, haxenode.org, haxe.org) or in one place. I can
say, however, that as haxe.org has communicated "you can make
cross-platform games and apps!" some have gotten confused, how Haxe and
NME are different if they "both do the same thing."

JS developers are probably turned off by talk of Flash and other things
that don't relate to their type of development. As one person has told me,
"the nose and the foot are part of the same body, but they aren't next to
each other for a reason." To get developers excited, we may need distinct
messaging or communities, even, to allow them to flourish in their own
separate ways :)

[Philippe Elsass]

Joshua you're mostly right, but I think a majority of Flash devs aren't looking for something like NME: Adobe thinks now Flash should be used for games, but the most desperate Flash devs are the one doing marketing websites and who are told to do the same in "HTML5", asap. 

So that may be Jeash, but if we clearly make it easy to optimize the output (hard to do with NME BTW) and if we look into a few performance issues (esp. iOS). Or it can be externs some other existing well optimized JS library. This is a "big market" for haxe I think and it needs some good docs to get started efficiently.

I wanted to add that:

- newcomers should NOT have to write externs. It's the best way to stop all motivation to look into haxe.

- externs, like libraries, need a maintainer or they become quickly irrelevant and a source of confusion.

--
Philippe

[Joshua Granick]

I am hoping that we will be able to optimize the output for Jeash. The
file size is just too large.

With the command-line tools, it should be simple for us to wire up any
extra steps if they bring the right results.

I definitely agree about newcomers writing externs. I am hoping that the
"buildhx" project will help make things simpler to create and keep
up-to-date. Although externs are not difficult to write, an XML file
probably feels less daunting.

Even better is if they can be generated automatically from whatever JS
documentation tool is being used. JSDuck for Sencha Touch and Ext.js is
working, and Fintan Boyle seems to have almost implemented support for
YUIDoc for EaselJS

I hope to be able to use this tool to work out the relationship between
Haxe and C++ in order to wrap native libraries, like Box2D, or native UI
on the iOS or BlackBerry platforms.

On Mon, 14 May 2012 13:50:34 -0700, Philippe Elsass
<philipp...@gmail.com> wrote:

> Joshua you're mostly right, but I think a majority of Flash devs aren't
> looking for something like NME: Adobe thinks now Flash should be used for
> games, but the most desperate Flash devs are the one doing marketing
> websites and who are told to do the same in "HTML5", asap.
>
> So that may be Jeash, but if we clearly make it easy to optimize the
> output
> (hard to do with NME BTW) and if we look into a few performance issues
> (esp. iOS). Or it can be externs some other existing well optimized JS
> library. This is a "big market" for haxe I think and it needs some good
> docs to get started efficiently.
>
> I wanted to add that:
> - newcomers should NOT have to write externs. It's the best way to stop
> all
> motivation to look into haxe.
> - externs, like libraries, need a maintainer or they become quickly
> irrelevant and a source of confusion.
>
> On Mon, May 14, 2012 at 10:37 PM, Joshua Granick
> <bulk...@joshuagranick.com
>> wrote:
>
>> Perhaps the BlackBerry Developer site is a good example:
>>
>>

>> http://developer.blackberry.**com <http://developer.blackberry.com>

[Dominic De Lorenzo]

Nicholas - I was thinking about cutting the 'best…' out immediately after I sent my last email. You are right - 'target any platform natively' is much more succinct, accurate to what we have, and where we want to be.

Segmented audiences/sections on the main site is essential and I think the four categories you’ve listed are a good breakdown.

I also agree with Joshua that a 'server side' category is missing from that list - perhaps something along the lines of 'How to leverage common code across both client/server'. Its a compelling set of case studies/scenarios that illustrate the possibilities of Haxe (even though it's not as core a sub group as the NME and JS ones)

Finally – Philippe – you are right that externs are probably the biggest hurdle for javascript developers right now (especially since 2.09's -js–modern generated output is so much more comparable to native js). A JavaScript developer forced to write an extern for an existing library can have the negative repercussion of implying that their existing JS libraries are subpar because they aren't 'properly' typed. Not a great way to start a new relationship :)

Automating/generating externs (and potentially printing warnings over errors) would help reduce that barrier significantly.

Cheers,

Dom