Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 david@davidarno.org does not designate 74.125.82.41 as permitted sender)
Received-SPF: pass (google.com: domain of david@davidarno.org designates
 10.180.78.98 as permitted sender) client-ip=10.180.78.98;
Message-ID: <1329687982.3272.39.camel@lapsang>
Subject: [gosh] Goshhawk language choices and more [Was: Adobe / Apache /
 Spoon Flex Tour]
From: David Arno <david@davidarno.org>
To: flex-dev@incubator.apache.org
Date: Sun, 19 Feb 2012 21:46:22 +0000
In-Reply-To: 
 <CAJQBtgneq2UkgmJk2Wv2HMg13kYB9=8o2ubAeH+xX_w4vbcJBw@mail.gmail.com>
References: 
 <CAJQBtgneq2UkgmJk2Wv2HMg13kYB9=8o2ubAeH+xX_w4vbcJBw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0

On Sat, 2012-02-18 at 21:48 +0200, Left Right wrote:
> First of all. Why Java (JVM)?
The JVM gives us many advantages:
1. Java - which whilst long in the tooth is well known and well
supported and - a point that is difficult to overstate - its the
language that Flash Builder and FDT and IntelliJ are all written in.
Dismissing Java as "corporative neo-COBOL" is a little silly.
2. It offers easy-cross platform support. Making something that runs on
Windows and Linux and OS X, without caring about the target OS, is very
easy with JVM-targeted languages.
3. It's a fast, universally available, well supported, will understood
managed memory environment.

Sure it has disadvantages (the seriously crap need to tell the
application how much maximum memory its allowed to use via obscure
command line options being the worst in my view,) but I'd contend that
the benefits outweigh those disadvantages.

However, if you think that people with no interest in Flex will come
flooding on to this project to help write a compiler if we propose
writing it in in a technology that doesn't target the JVM, then I'm more
than happy to go with a different language.

> 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.
What benefits exactly would Go offer? How many compilers have been
written in Go? Surely Go is just one of Google's many many projects that
they frequently throw at the wall to see which stick. Go didn't stick as
far as I know.

> Haskell - a beautiful language! Bonus points, it has developed tools for
> parsing code using formal grammar.
It might be beautiful if you have a degree in maths. To most
programmers, it's incomprehensible gibberish :p

By all means feel free to write a Haskell-based compiler, but count me
out if you do. Life is too short for me to waste it on a language so
complex, no one seems to be able to explain what a monad is in less than
a one hour talk...

> C - no-bullcrap, plain old C if you want to squeeze the last bit of
> performance.
Ha ha. This made me laugh. You call Java a Cobol-like language, then
drag up a language I used to have to write on VT100's some 25 years
ago! :) Seriously, C should be a language of last-resort. It's really
not very nice.

> Common Lisp
(One (day (we (may (all (have (to (learn (to (use (Lisp (but (until
(then (I'd (prefer (to (pretend (it (died (40 (years (ago, (buried
(under (its (own (insane (syntax)))))))))))))))))))))))))))))

> 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.
haXe is written in OCaML. As a result, one person maintains the
compiler, because no one else knows it...


> AS3 per se has no formal grammar definition,...
I reckon
http://svn.badgers-in-foil.co.uk/metaas/trunk/src/main/antlr/org/asdt/core/internal/antlr/AS3.g would form at least a good starting point for this non-existent formal grammar.


> JavaScript related stuff - first of all why bother? :)
Because we don't have any choice. Whilst it is a huge pile of steaming
shit, and I'd love to punch Brendan Eich in the face for being so proud
of inflicting such an awful mess upon humanity, it's here to stay and is
the future of programming for the foreseeable future.

>  Alright, that's just
> my opinion. But wouldn't it be better to generate some common intermediate
> language,
Yes, that's why I suggested the front-end and back-end separation of
Goshawk. The front-end will be written using something like ANTLR and so
will be programming-language agnostic. It will save its results as lib
files, which will be target-agnostic. The back-ends then can take that
common form and turn it into target-specific output.

We can't use something like LLVM though as we are not simply creating a
language compiler: we are creating a framework compiler. We can't just
compiler AS3 code to JavaScript, for we need to handle rendering in a
language-specific fashion. JavaScript for example will likely need skin
"classes" written directly in JavaScript that need to be stitched in to
the output by the JavaScript back-end.

> 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.
I think you are wrong. SWC's are just SWF's wrapped up in a ZIP file.
They are target-specific and thus next-to useless to a multi-target
compiler solution. If people really want Goshawk to output SWC's, then
it will happen. I just think it's a short-sighted idea.

> Static analysis - will the new compiler be an optimizing compiler?
That will depend on the back-end. Each target will likely want
optimising in different ways, so it will be up to each target-specific
back-end to optimise as required. The front-end of course will do no
optimisation at all.

David.