incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Left Right <>
Subject Re: Adobe / Apache / Spoon Flex Tour
Date Sat, 18 Feb 2012 19:48:28 GMT
Sorry, I wasn't registered when this thread started, so if my message
didn't end up in the proper thread, I hope the moderators will move it.

Basically, this thread has helped me to make up my mind and register :)
Some of you may know me as a loudmouth annoying debaucher person, and this
post has a tendency to end up as such, but I'm begging you to treat it with
a bit of irony. Well, consider yourself warned! :)

So, there's not much yet to discuss in the new compiler architecture,
however, there are certain things I'd like to bring up as a potential user.
I was actually waiting for Adobe Falcon compiler to get into any shape, so
I would start working on my "dream project" - an AS3 mode for Emacs :)
Seeing how the future of AS3 compiler is now in question, I'd like to chime

First of all. Why Java (JVM)? Why use this piece of corporative neo-COBOL
invented for the sole purpose of allowing cheap labor force to further
bloat the bloatware? For once you have the full carte blanche to start
anew, and you choose nearest to worst option? Compiler is unlikely to drive
a lot of attention of the programmers typically writing in Java. On the
other hand, programmers who are interested in language design are very much
unlikely to be attracted by Java. I'd look into the following options,
which are all viable, in my opinion:

Go - the Fortran-like (or, if you prefer, C-like) language. A kind of an
effort to fix long-standing Java problems. It is not an ideal language, but
it is a good replacement for Java for people who grew on Java.
Haskell - a beautiful language! Bonus points, it has developed tools for
parsing code using formal grammar.
C - no-bullcrap, plain old C if you want to squeeze the last bit of
Common Lisp - a very versatile, in fact, much more modern in certain
aspects then Java, language. Extremely well suited for building
intermediate code, manipulating (optimizing) parse trees. The perfect tool
for code generation. Writing the tools for AS3 in lisp will very much
broaden the horizons of AS3 programmers, let them be exposed to more
programming concepts (this, of course applies to other options too, to a
variable degree).
Any variant of ML/Miranda-like language (be it CaML or Erlang, I've
mentioned Haskell already) simply because you have a very good compiler
implemented in CaML (HaXe, which is very similar to AS), and you could've
borrowed certain ideas from it.

* * *

ANTLR - is the tool for automatic parser generation. It may or may not _at
all_ apply to ActionScript. I would be rather surprised if it did, since
AS3 has extremely convoluted grammar (feels like it might be too ambiguous
for this kind of parser), especially due to E4X, but the metadata is
another weird subject. The rules pertaining to semicolon aren't helping as
well. Lastly, there were many arbitrary decisions made by the MXMLC
authors, which, de facto become AS3 standards, but need not to be such.
Examples: there may only be one public definition per file - this is kind
of random, and is this way solely due to the way MXMLC caches the
definitions it finds. It's not even a technical limitation, it's something
done long ago in order to speed up the compilation process, some very early
versions of MXMLC allowed more then one public definition per file.

AS3 per se has no formal grammar definition, and, in certain cases you
would be either forced to follow the existing implementation, or make an
arbitrary choice based on "what feels right". This is especially so because
on different stages of MXMLC development different features have been
dropped or altered. For example, once it was possible to provide a complex
expression in place of the type specifiers. Example: var
foo:(getTypeOfFoo()) = functionThatReturnsFoos(); would've compiled. I.e.
compiler could do some sort of type inference / something similar to "auto"
from C++, but never more.

* * *

Old compiler was essentially dumb, when enforcing certain AVM specific
policies, thus allowing essentially wrong code to compile. For example, in
constructor if (1 == 2) super(); would generate the code, that never calls
the super constructor... This is only an example, there's a lot of this
kind of surprises. You would need to treat that somehow, decide what to
keep and what not to keep, when should you issue warnings etc...

MXML is an extremely unthoughtful template language, it is in many aspects
very evil. I cannot imagine anyone who used it for a real world project and
never wished this thing just vanished as a nightmare. It is so wrong in so
many ways... inability to set properties to constant values / expressions.
It is forcing you to copy-and-paste approach, it is sometimes more wordy,
then the similar AS3 code! Example:
<fx:DataGrid ...>
<fs:DataGridColumn label="{Foo.BAR}" labelFunction="{labelFunction"}/>
<fs:DataGridColumn label="{Foo.BAZ}" labelFunction="{labelFunction"}/>
<fs:DataGridColumn label="{Foo.BOOZ}" labelFunction="{labelFunction"}/>
. . .
<fs:DataGridColumn label="{Foo.CHAMPAIGN}" labelFunction="{labelFunction"}/>

You copied words "DataGridColumn", "label", "Foo", "labelFunction",
"labelFunction" how many times? Whereas you could do:

var dataGrid:DataGrid = new DataGrid();
for (var p:String in Foo) dataGrid.columns.push(makeColumn(p));
function makeColumn(label:String):DataGridColumn { return ...; }

Almost no editor today provides any good tools for working with MXML -
yeah, I tried Intellij and FDT - it just doesn't work properly, since no
sane spec of MXML had ever existed, certain implementation treated it as
they thought it would function or just didn't give it a second thought, so
it functions essentially wrong.

I don't believe anyone really wishes to keep this thing, if only, for
retrospection and maintaining old projects. Seeing how many mistakes in
design were made in this particular place, I'd say that if you want good
code, backwards compatibility will likely became a major obstacle. Adobe
may have certain obligations in this regard, but, seriously, I don't see
why would any of you feel obligated to keep this dark legacy alive :)

This all was written as an attempt to convince you to write your own w/o
considering the heritage, since the heritage may be at the same time bad
and unwelcome to the end users.

* * *

FXG - important! This was generated by MXMLC too! Don't forget it :) The
way it was generated, however, was not good - for some obscure reasons,
whoever wrote this part of the compiler decided to force the use of some
Spark containers as base class - this needs not be such! This essentially
killed the feature. This and the whole linker-related issues - totally
useless Flex***Asset classes, the [Embed] tag - obscure and promoting bad
practices... how are you going to support that? [Bindable] - another very
controversial feature - it is essentially evil, since you can't force it to
use your own template for code generation. But probably you need a whole
more generic solution for code generation based on metadata?

How about providing a better interface to linker - not anything you'd need
to write a Java module for, but just use output from Imagemagic / DevIL /
GD etc?

* * *

JavaScript related stuff - first of all why bother? :) Alright, that's just
my opinion. But wouldn't it be better to generate some common intermediate
language, like LLVM and let whoever wants it to use tools that can
translate LLVM to JavaScript, something like JSC? I mean, after all this is
an ActionScript compiler for Flash - JavaScript is a separate community,
with their own stuff, leaders and blah :) - why not let them use their
Closure and be proud of themselves? Anyway... just saying.

* * *

SWC - is not only a code repository, it's essentially a way to store
whatever you might have in the project. I think it would be wise to reuse
this idea. Probably limit oneself to the versions and the content of the
SWC one will understand, but I don't see how it makes sense to discard the
entire feature, or to rename the file. You can already stuff it with
JavaScript files, if you want to, no changes to the format are needed.

* * *

Static analysis - will the new compiler be an optimizing compiler? (A short
question, but this is essentially would be the biggest part of the
compiler, if it will ever be).

* * *

Conditional compilation... is... well, dramatically bad in MXMLC. It's not
a standard of any ECMA-whatever, are you going to keep it at that, or just
redo the whole thing? I'm so for redoing it...

Sincerely yours.

Do I have to remind you about taking the above with a bit of irony? Alright


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