flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niel Drummond <niel.drumm...@grumpytoad.org>
Subject Re: [gosh] Compiler choice [was Goshhawk language choices and more]
Date Mon, 20 Feb 2012 18:28:03 GMT
On Mon, Feb 20, 2012 at 4:07 PM, David Arno <david@davidarno.org> wrote:

> > From: niel.drummond@googlemail.com [mailto:niel.drummond@googlemail.com]
> On Behalf Of Niel Drummond

Thank you.

> > Sent: 20 February 2012 07:45
> >
> > 1) Wait for falcon, projected stable release late 2012, early 2013.
> This to my mind is the most risky of your three options. We wait a year,
> then maybe get a compiler, which will be of unknown quality and usability.
> Then we'd have to start work on getting it to support MXML properly.

I agree.

> > 2) Write a cross-compiler for flex from scratch.
> This is, IMO at least, the best of your three options. It will be tough,
> but
> if enough people get involved then I see no reason why we couldn't achieve
> it.

Maybe. The idea might be appealing, since it's always nicer to start with a
clean house. However, I think it will also take the longest time to
accomplish, and much of it is re-inventing the wheel. It takes time to
develop a stable compiler, it takes time to get cross-platform language
features ironed out in a conform way, it takes even more time to get all
the GUI features working in a stable way across runtimes.

Many of these stumbling blocks were dealt with by the haxe compiler, and
what I personally feel the haxe community can bring to the flex community,
is a general experience in making libraries work on other runtimes.

> > 3) Port the SDK to haxe (or build a converter)
> Tried that and gave it up as a bad idea. There are numerous problems with
> this approach:
> 1. haXe doesn't support numerous aspects of AS3, such as custom namespaces,
> E4X, global functions and internal and private namespaces.  Porting Flex to
> haXe would be a non-trivial task.

Writing a compiler is even less trivial.

For the 95 percentile, porting AS3 to haxe is trivial. I have ported large
and complex AS3 libraries (25-30K LOC) to haxe in a matter of weeks, other
haxe community members have too.

Some of those exclusive AS3 features you mention could be
emulated/implemented using haxe's macro feature. I would be surprised if
you said not having global functions is a blocker.

The biggest problem mentioned is e4X. Though, if you were to write your own
compiler and insist upon e4X, you would need to implement e4X in javascript
for non-mozilla browsers, which I think is quite a bit harder to get right
in a performant way than to take a step back, and think about a more
cross-target solution.

2. haXe compiles everything from source files. It has no support for
> partially compiled library files. Whilst it is fast for small numbers of
> files, this really doesn't scale well for larger applications, such as
> those
> using the Flex SDK. From the tests I did, I estimated that needing to
> recompile the SDK source files every time one did an application build
> would
> add 1 - 2 minutes to the build.

haxe supports swc files, there are a number of projects that can combine
these (hxswfml, samhaxe, swfmill) which in my mind is what is meant by
flash modularity (though, I admit, I only use flash to port it to

If you use your own compiler or falconjs, you would still need to implement
your own javascript modularity functionality. In comparison, some recent
haxe code can read swf files to pull assets out, I'm not sure what could be
done about code.

Regarding compile speed, the compiler is fast, if you are invoking the
compiler more than once, then there is something wrong your project setup.
The exception to this is macro heavy code, which invokes the neko
interpreter during a compile phase and is noticeably slower.

3. The SDK wouldn't just need porting to haXe, it would need rewriting to
> add lots of conditional compilation directives to it to control how it
> built
> to SWFs and to JavaScript.

Code conditionals are generally used at a package level, you can avoid it
altogether by simply redirecting a package subtree to another one at
compile time, depending on the target (this is what jeash does).

> haXe is a great little hacking language (though don't call it that or
> indeed
> a toy language in front of Nicolas Cannasse, as he took offense when I -in
> my subtle-as-a-brick fashion - referred to it as the latter,) with a great
> community around it. It just isn't the sort of thing I like to offer up to
> an enterprise-type customer who'd normally consider Flex solutions.
Of course, but that's all very political, and IMHO ignores proven technical
advantages, time-to-market considerations, and the fact that you still have
to convince your clients that your new compiler is better than adobe's one

- Niel

> Of course it's worth wondering why no one except Michael Labriola is
> considering the fourth option in all of this: stick with the existing mxmlc
> and compc compilers. They may be slow, but they work and in theory we are
> supposed to be getting the source for them straight away, not in a year's
> time. Perhaps we should be putting more effort into investigating modifying
> them to output JavaScript, Android and IoS native etc?

> David.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message