[gosh] Goshhawk language choices and more [Was: Adobe / Apache / Spoon Flex Tour]

[David Arno <da...@davidarno.org>]

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.

Re: [gosh] Goshhawk language choices and more [Was: Adobe / Apache / Spoon Flex Tour]

[Jarosław Szczepankiewicz <js...@gmail.com>]

Svg rendering is probably used for vector drawing.
19-02-2012 23:35 użytkownik "Justin Mclean" <ju...@classsoftware.com>
napisał:

> Hi,
>
> > Therefore I think with Flex our only choice is to do the complete
> > opposite of haXe and to write JavaScript-specific renderers to replace
> > all the skin classes in Flex. That is the only way we can hope to get
> > good performance.
> Does anyone know what approach FalconJS is taking? Would be useful to know.
>
> Justin
>

Re: [gosh] Goshhawk language choices and more [Was: Adobe / Apache / Spoon Flex Tour]

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Therefore I think with Flex our only choice is to do the complete
> opposite of haXe and to write JavaScript-specific renderers to replace
> all the skin classes in Flex. That is the only way we can hope to get
> good performance.
Does anyone know what approach FalconJS is taking? Would be useful to know.

Justin

Re: [gosh] Goshhawk language choices and more [Was: Adobe / Apache / Spoon Flex Tour]

[Niel Drummond <ni...@grumpytoad.org>]

On Sun, Feb 19, 2012 at 11:27 PM, David Arno <da...@davidarno.org> wrote:

> When I looked into the idea of us simply porting Flex to haXe to solve
> the JavaScript-target issues, what you describe was one of the killer
> issues that made haXe a no-go.
>
> haXe doesn't do anything clever to target the DOM and
> JavaScript-specific component libraries, thus if we followed the haXe
> approach, we'd end up with Flex trying to render via canvas elements.
> The canvas is far too slow in all browsers at present for this to be an
> option.
>
> Therefore I think with Flex our only choice is to do the complete
> opposite of haXe and to write JavaScript-specific renderers to replace
> all the skin classes in Flex. That is the only way we can hope to get
> good performance.
>

That's a bit quick and blunt as an assumption - canvas is pretty fast in
modern desktop browsers (I should know, as I maintain a canvas-based flash
api for haxe), by the time you have a _stable_ javascript backend for flex,
this won't just be for desktops but pretty much standard for mobile
hardware.

Though, in all honesty, I think it's best to rely on standard HTML and CSS
markup for layout, that's what it was designed for. I don't see how having
"javascript specific renderers" is any different from writing it in another
language that is compiled down to the host language - how these are to
provide better performance eludes me.

- Niel


> David.
>
>
>

Re: [gosh] Goshhawk language choices and more [Was: Adobe / Apache / Spoon Flex Tour]

[Left Right <ol...@gmail.com>]

C++ has a sore taste of many completely different people trying to cook one
dish, so one thought it was soup, another thought it was a pancake, yet
another one thought it was meant to poison the dictator of her country...

Oh, some times it's good to look into the Wiki before you post stuff, yeah,
that's feng-shui :P

Re: [gosh] Goshhawk language choices and more [Was: Adobe / Apache / Spoon Flex Tour]

[almansour belleh blanco <za...@gmail.com>]

2012/2/20 Left Right <ol...@gmail.com>
> Following the series of successful personal insults...
> I kind of like your reaction to the language choice... sort of Homer
> Simpson answer, sorry :)
> There is no correspondence between the time the language was invented, and
> how wisely it was designed. COBOL and Java are examples of human stupidity
> propagated to the extent of absurdity... While C is a nice small language,
> which actually is very much consistent with itself and logical (unlike the
> bigger brother - C++).


C++ can be logical as well, never blame the tools. The JVM is written
in C++ btw. As a matter of fact, C++ adds many things that were not
available in C.

> After all, don't you have a soul, an actual programming soul that demands a
> fang-shui,

Isn't it feng-shu? ;)


-- 
Mansour Blanco
Software engineer
Stackoverflow: http://stackoverflow.com/users/612920/mansuro
Blog: zuro.blogspot.com
github: https://github.com/Mansuro

Re: [gosh] Goshhawk language choices and more [Was: Adobe / Apache / Spoon Flex Tour]

[David Arno <da...@davidarno.org>]

On Mon, 2012-02-20 at 01:35 +0200, Left Right wrote:
> David, I used Metaas, and I know that grammar file... it's well, it's
> wrong, and it doesn't reflect many things that happened since FP10 (Metaas
> project was abandoned before FP10 was released, so, no handling for
> vectors, for example, but not only that, it really is an oversimplification
> of AS3 syntax), some particular evil things like metadata haven't been
> handled there... neither conditional compilation was. It might sound like a
> 1%, but it may be a dealbreaker as well... you really never know. You must
> have a solid proof, not an assumption that "it will probably work".
It will probably work is good enough for me at the moment to warrant
giving it a try. If it doesn't work out in the end, then I was wrong and
we'd all have learnt from it. 

> 
> And, yeah, you are wrong about SWC, it's just a zip archive - I used it to
> just save JPEGs for simpler project management.
Please don't play Mr Pedantic. A SWC to most Flex devs is a zip file
with a SWF file inside it. Regardless of file extension, if it lacks a
SWF, it's just a zip with a different name.

> There is no correspondence between the time the language was invented, and
> how wisely it was designed. COBOL and Java are examples of human stupidity
> propagated to the extent of absurdity... While C is a nice small language,
> which actually is very much consistent with itself and logical (unlike the
> bigger brother - C++).
That's the thing about programming languages: one man's marmite sandwich
is another's inedible muck on a plate. I hate C. It's overly complex,
uses a nasty syntax etc. I can live with Java though as it's OK. Not
great, but way better than C in my opinion. You clearly have a different
opinion...

> I feel silly having to defend Common Lisp...
Well we agree on that at least ;)

> 
> Have you considered that your point of view may be what it is because
> everyone does Java these days, so I'm doing it too - why be different, if I
> wanted to be different, I'd buy an Apple computer? :)
No, because I don't actually use Java very much. I just see it as the
best choice in this case. Oh and I don't own any Apple products either.
Not a fan as it happens. I gave up trying to be different years ago with
computing. It just makes life hard.

> After all, don't you have a soul, an actual programming soul that demands a
> fang-shui, a perfection at the smallest detail - a tool crafted precisely
> to do exactly what you need?
Um, no, not really. The art to being a good developer is nothing to do
with having fancy tools; it's in knowing how to craft well with any
tool.

David.

Re: [gosh] Goshhawk language choices and more [Was: Adobe / Apache / Spoon Flex Tour]

[Left Right <ol...@gmail.com>]

David, I used Metaas, and I know that grammar file... it's well, it's
wrong, and it doesn't reflect many things that happened since FP10 (Metaas
project was abandoned before FP10 was released, so, no handling for
vectors, for example, but not only that, it really is an oversimplification
of AS3 syntax), some particular evil things like metadata haven't been
handled there... neither conditional compilation was. It might sound like a
1%, but it may be a dealbreaker as well... you really never know. You must
have a solid proof, not an assumption that "it will probably work".

And, yeah, you are wrong about SWC, it's just a zip archive - I used it to
just save JPEGs for simpler project management.

Following the series of successful personal insults...
I kind of like your reaction to the language choice... sort of Homer
Simpson answer, sorry :)
There is no correspondence between the time the language was invented, and
how wisely it was designed. COBOL and Java are examples of human stupidity
propagated to the extent of absurdity... While C is a nice small language,
which actually is very much consistent with itself and logical (unlike the
bigger brother - C++).
Go has little to do with Google, it wasn't designed by Google, it was
"adopted", it was designed by Rob Pike, the author of Inferno / Plan 9.
It's a language that makes a lot of sense as a language, regardless of it's
compiler being in it's infancy.
I feel silly having to defend Common Lisp, especially because if that was
the language of choice, I'd of course write in it :) Sorry, you don't seem
to know the subject in detail, really, just for the record - you can
completely alter Lisp syntax to, be, for example, exactly the same as AS3,
lispers don't do that, because the way Lisp is makes sense, and the way AS3
is makes little.

Have you considered that your point of view may be what it is because
everyone does Java these days, so I'm doing it too - why be different, if I
wanted to be different, I'd buy an Apple computer? :) Have you considered
that Apple used Objective-C, regardless of it being a not so popular
language, and, whoa, suddenly it started to make sense? Have you considered
that you might be having preoccupation because you are not very much
familiar with the subject? What if if you base your decision on the
preposition that if I do whatever everyone else does, then I have a
tremendously high chance to end up with the worlds majority, which has been
proven to be of no significant thinking abilities? (hey, that includes me
too! :)

After all, don't you have a soul, an actual programming soul that demands a
fang-shui, a perfection at the smallest detail - a tool crafted precisely
to do exactly what you need? What about the ambition of writing a better
program? You cannot seriously achieve good results without these thing.
Writing compiler is an art of programming, you cannot just throw in stuff
and hope it'll work. You cannot proceed w/o good mathematical knowledge,
because if you don't have it, the optimization will turn out to be a pain
:( You should like it, no, you should breath it, to make it good... I'm
saying this not because I have it, but I saw people who have, and I adore
them :)

What I was meaning by Unix-like approach is that compiler needs not be a
single program (thus, it may be, as you call it, a framework compiler if
used with the framework stuff, and non-framework otherwise, or maybe used
with multiple frameworks? - who knows). So, I don't think that targeting
some processor-agnostic assembly language would be a bad thing for
compiler, in fact, I still think that deciding on LLVM as the compiler
intermediate language is still very much plausible. It wasn't far from that
in the original compiler design, albeit it got screwed along the way. ASC
would be the ActionScript compiler proper and MXMLC would be a framework
compiler - something to handle stuff for Flex Framework and it's _amazing_
templates :) But, in the end ASC didn't get a good front end, and all
compilations went through MXMLC, which, instead of calling ASC, embedded
it... (Java kind of understanding of modularity zomg!) Ideally though, I'd
like it to be in the way, when there is ASC - a language compiler proper
and some templating program _which does not compile anything_, simply
processes the templates and calls the ASC with the output it produces. That
would be truly modular! Instead of suffering SystemManager hardcoded into
compiler, you would write your very own one, with whatever data added at
compile time as you need, with as many frames created, mixins, preloaders -
go crazy and do whatever you want, the compiler would be still able to
support that!

Please, I didn't really mean you are like Homer Simpson, but that only
answer was very much his style, so I couldn't resist!

Re: [gosh] Goshhawk language choices and more [Was: Adobe / Apache / Spoon Flex Tour]

[David Arno <da...@davidarno.org>]

On Sun, 2012-02-19 at 23:19 +0100, Niel Drummond wrote:
> I don't recommend the approach of writing a separate javascript layer -
> haxe has the concept of "untyped" code blocks, and a special Dynamic type,
> which is extremely useful at getting around browser incompatibilities (I
> think GWT has something similar). I don't think it makes sense to create a
> javascript backend without this feature.
When I looked into the idea of us simply porting Flex to haXe to solve
the JavaScript-target issues, what you describe was one of the killer
issues that made haXe a no-go.

haXe doesn't do anything clever to target the DOM and
JavaScript-specific component libraries, thus if we followed the haXe
approach, we'd end up with Flex trying to render via canvas elements.
The canvas is far too slow in all browsers at present for this to be an
option.

Therefore I think with Flex our only choice is to do the complete
opposite of haXe and to write JavaScript-specific renderers to replace
all the skin classes in Flex. That is the only way we can hope to get
good performance.

David. 

Re: [gosh] Goshhawk language choices and more [Was: Adobe / Apache / Spoon Flex Tour]

[Niel Drummond <ni...@grumpytoad.org>]

On Sun, Feb 19, 2012 at 10:46 PM, David Arno <da...@davidarno.org> wrote:

> 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.
>
>
I don't recommend the approach of writing a separate javascript layer -
haxe has the concept of "untyped" code blocks, and a special Dynamic type,
which is extremely useful at getting around browser incompatibilities (I
think GWT has something similar). I don't think it makes sense to create a
javascript backend without this feature.

- Niel