About Programming Languages and Runtimes, and the Design Philosophy behind Redtamarin

Let’s start with JavaScript (ECMAScript) as an example.

For many years, ES was slow to evolve, so superset of the language appeared
things like CoffeeScript, NodeScript, RedScript, etc.

and then it went even further with statically typed languages not necessarilly related
to JavaScript but that compile to JavaScript, things like Dart, TypeScript, etc.

In those cases the programming language (PL) JavaScript is good but for some people not good enough and they extend it somehow, but at the end they are still targeting their output to something
that is compatible with the browser, let’s say ES3, ES5.1, etc.

There, the browser is the runtime, and its main and only PL JavaScript is more seen
as the “bytecode” to make it work inside that runtime.

Not saying that JS is not important, but obviously when you write your main application
in Dart or any other PL that compile to JS, you do not really care about JavaScript the language itself.

And even when things evolved a bit faster, from ES3, to ES5.1, to ES6, etc.
and the browser vendors are updating more, it is still not enough and so you will see
JavaScript developers who decide they want to code using ES7 and use tools like babel
to target a lesser version of ES so it can work within the browser (while waiting for the browser to catch up).

In fact, this has become so huge that almost anyone want to compile to JavaScript, so it can work in the browser (the runtime).

Here a huge List of languages that compile to JS.


Yes, ActionScript is also one of those.

First, ActionScript 3 itself is a superset of ECMAScript based on ES4.

Long time ago you had Jangaroo, basically something that cross-compile your AS3 to JS.

And nowadays you have Apache Royale, evolved from Flex and FlexJS, that also cross-compile AS3 to JS, and even some experiment where it can compile to WASM (WebAssembly), but in the end the goal is the same targeting the browser runtime.

What is interesting here is that it can work both ways, you can target the browser as your runtime by compiling to JS, but you can also re-use JS code and compile to ActionScript ByteCode (ABC) to work in another runtime: the AVM2 (or AVMplus).

The same way you can reuse JavaScript alongside your TypeScript class, as you don’t have to rewrite the JS to work with TS, you can do the same and use JS code alongside your AS3 code (see The case when you don’t want Node.js for an example of it).

The distinction between programming languages and runtimes is important, and yeah the line can be blurry sometimes, but reflecting on what is what, what a dev can do with what and where, can open your eyes to some new perspective.


We are all dev here, our jobs, most of the time, is to solve problem with code, by learning about code, reading about code, writing code.

If you have few years under your belt, you probably did not stick to only one programming language, and you probably compared PL to other PL and seen what is alike, what is different, what feels more stable, liked new way of doing and missed other way of doing things.

Personally I have worked with around 15 programming languages, it is mostly the same thing: pros and cons. But beyond that, there is also the culture (way of doing things), the community kind of or more like the type of dev the PL can attract, and what you can target with it, eg. the runtime.

Pros and cons is not really a big issue, oh you don’t have a switch statement in Python, you can work around it, oh you don’t have abstract class there, same not a big deal; it will mainly depends on your tolerance to the cons, a bit too much and maybe in the futur you will simply just avoid using that particular PL.

Take PHP for ex, a lot of people hate on that programming language, but considering its lenghtly history and yeah even if you can find a lot of “cons”, even if I understand that someone would not particular enjoy it, I think you can definitively work with it and get the job done.

My issues with PHP would be more in the runtime part, if you work a lot with PHP you will mainly do server-side work, and the general quality of the libraries you can find for it, case where you definitely earn time by building the lib yourself instead of reusing one of the 50 laying around on composer because most were “inexperienced dev experiment”.

Mainly I think it is useless to hate on programming language, at best it will just show how immature you are, in fact at the second you’re trash talking about a programming language it puts you on the top of “mount stupid” on the Dunning–Kruger Effect curve.

svg

Not always but yeah 99% of the time.

Maybe for dev it is a bit more like that

and a bit of the three stages of expertise


So why is it happening?

Mostly because it is terribly frustrating to learn programming, for the first few years people struggle, think they are “dumb”, etc…, so as soon as they know stuff oh yeah they gonna show it, and in itself not a huge issue, on forums and stuff that give the effects of some devs helping other devs, that “sef-help” effect which quite nice.

But the Dunning–Kruger effect still applies, you still see dev with maybe 4 or 5 years of experience, knowing maybe 2 or 3 languages thinking they are on the top of the world and that they just know everything there is to know, and so they decide that this or that is obsolete or deprecated, they must be right, right ?

Nope.

See, we are in an industry that cultivate a lot of bullshit, and that industry feed itself with that very same bullshit: like “Learn C++ in 21 days”, like “Go a to a bootcamp for 3 months and land a developer job”, like “some developers are 10x developers”, etc.

So when you’re on the top of that “mount stupid” and you feel so confident about your programming skills, you just don’t know how much you don’t know, and some people in those circumstances can say pretty enormous stupid thing.

Like “ActionScript is dead”, like “ActionScript is obsolete”, like “ActionScript is deprecated”, and on and on …

They don’t fell like searching to learn more like reading Teach Yourself Programming in Ten Years from Peter Norvig.

They just think they are “real” programmers opposed to all those fakey programmers


And that’s why you see on a regular basis, this language sucks, this other language is better, why we moved from A to B and why our life is so much better now, why if you learn this new programming language you will be able to walk on water, and other bullshit like that.

Some example, PHP Sucks, But It Doesn’t Matter, and Why We Don’t Hate PHP,
and in some case some people even cultivate whole pages against a PL: Go is not good eg. “A curated list of articles complaining that go (golang) isn’t good enough”.

Ok, a bit more: 10 Reasons Why Visual Basic is Better Than C# and the counter rant I don’t want to trash-talk anyone’s favorite programming language - after all, I get quite pissed if anyone rants about ….

Sometimes you will see people ranting about PL they simply don’t know (off course they don’t use them)

And remember those articles about the best programming languages to learn?
well … there is also the opposite: Worst Programming Languages to Learn in 2018 with ranking and everything

So let’s repeat it again: every single programming language is worth learning, and yeah it will have pros and cons, because no PL is perfect, some can be highly popular, but popularity can vary over time (ActionScript is a perfect proof of that), some less popular but that does not make them non-existing.

The important part for a dev is to learn more than one, see for ex:

Bjarne Stroustrup: The 5 Programming Languages You Need to Know


you do know who is Bjarne Stroustrup right ?

see also Tour de Babel from Steve Yegge, which link to a pretty other famous rant java sucks from Jamie Zawinski.


What mainly motives those guys on the top of mount stupid to claim that “ActionScript is dead” is the death by association with the Flash EOL, OMGWTFBBQ if Flash is dead then its main language ActionScript must be dead too, right?

They see only the runtime part and the programming language part goes completely over their head.

The runtime, aka the browser, sure will not go anywhere as we all know internet is highly popular, and in this runtime there is only one programming language supported and that’s JavaScript, it is monoglot (it speaks only one language).

But despite what JavaScript’s cargo-culted Ayatollahs may think, you can build programs in other places than the browser, and in all those other places there are many many many languages, it is polyglot.

Also let me point out that opposing JavaScript to ActionScript is utterly stupid as they are siblings, and as such they share a lot in common.

see: Wat, A lightning talk by Gary Bernhardt from CodeMash 2012

WAT

the JS WAT

are the exact same AS3 WAT
WAT_as3

criticising one you automatically criticise the other

But as mentioned before every PL has its pros and cons, and so if you focus on the pros or all the good parts that are inherent to this particular programming language you can push some limits pretty far.

And here come the many decisions and design philosophy behind Redtamarin.


If at first, Redtamarin was mainly a funny side project as “it would be fun to run AS3 on the command-line”, it quickly turned into “wow I can add all those native stuff to it and it is quite powerful”.

But with power come responsibility (classic :slight_smile:), you can not just add and extend in any directions, you must know why.

Are we changing the VM itself?
no, we do want to stay compatible with the other runtimes like Flash and AIR

Are we building a new programming language?
no no no, ActionScript 3 is more than enough as it is, no need to invent an AS4

So yeah as a runtime Redtamarin is different than Flash which is different than AIR,
but they all share the same base: AVM2 (or AVMplus) and ao the core definitions and behaviours of the ActionScript 3 programming language.

And so on focusing on the pros parts of AS3 we can push some limits and see AS3 as a PL really shine.

First is something very simple: the packages, the ability to isolate source code into packages, something you can find in C++, Java, C#, etc.

Those packages help to isolate and implement numerous API, for example, for everything related to C (the C programming language), we use the C package, and there instead of using “includes” eg. #include <stdlib.h> we use the library name as a package eg. C.stdlib.

If you think of it, those packages are really powerful at organising code in the large.

But if you digg more you can push that limit even further, another feature of AS3 are namespaces, and yeah OK not a lot of dev are using them, but there there and they can be damn useful.

If you use JavaScript in the browser you probably encountered the concept of polyfill

In web development, a polyfill is code that implements a feature on web browsers that do not support the feature. Most often, it refers to a JavaScript library that implements an HTML5 web standard, either an established standard (supported by some browsers) on older browsers, or a proposed standard (not supported by any browsers) on existing browsers. Formally, “a polyfill is a shim for a browser API”.

Polyfills allow web developers to use an API regardless of whether or not it is supported by a browser, and usually with minimal overhead. Typically they first check if a browser supports an API, and use it if available, otherwise using their own implementation. Polyfills themselves use other, more supported features, and thus different polyfills may be needed for different browsers. The term is also used as a verb: polyfilling is providing a polyfill for a feature.

and here a list of HTML5 Cross Browser Polyfills

Can we do that with AS3?
yes we can

So this concern mainly Redtamarin, but technically it could be applied to AIR too
in short, because Redtamarin compile its own runtimes we can then augment builtin types.

Let’s see a short example with the Array class
it already been extended with Flash/AIR 19 adding insertAt() / removeAt()

but what if we wanted to add Array.prototype.flat() ?

we just use a namespace

package
{
    public dynamic class Array
    {
        ES6 function flat( depth:Number = 1 ):Array
        {
            // implementation
        }
    }
}

So it is not AS4 or even AS 3.1, but you can extend the language functionalities with API
simply using packages and namespaces, those 2 features put together are major pros in AS3

In Redtamarin, that’s the main work, defining API or at least know which one to keep embedded or not, C was kind of obvious even if not that obvious, adding the C standard library, and then the C POSIX standard library and almost magically you can use AS3 as C++, eg. you define well organised classes which reuse C functionalities under the hood.

For example, when I was looking around for network API I stumped upon the unreal engine networking API, written in C++, I could port most of the library into AS3 thanks to the C API.

Earlier I mentioned this article PHP Sucks, But It Doesn’t Matter
which from the starts list all function definitions starting with “A”

We could perfectly imagine a PHP package where you define package-level functions
something like

package PHP
{
    public function array_walk( array:Array, callback:Function, userdata:* = null ):Boolean
    {
        // implementation
    }
}

And even if you do think that PHP sucks, according to W3Techs
Usage statistics of server-side programming languages for websites

Yep, PHP seems to be most popular than anything else at 78.9%
so in term of API probably worht it to have a compat API to port from PHP

And you could push that logic to most if not all other programming languages,
sure we can extend the AS3 builtins with new methods and other definitions from ECMAScript,
it is logic they are siblings, the same we can add to Array a flat() method,
we could also define an es6 package where we could define classes like Map, Set, etc.

As long as we don’t change the language keywords. all that work.

But from Java we might want to extend the String class and add for example
a getBytes() method, for example

package
{
    public final class String
    {
        JAVA function getBytes():ByteArray
        {
            // implementation
        }
    }
}

It may seems a bit overkill but with the namespaces and packages it is all neatly organised and isolated, at worst you don’t need it and can ignore it, as long as some namespaces are not opened you will not even see the difference with “normal” AS3 usage.

But it can go even further than that, it is about API, so those can be close to the builtins
or they can be new considered useful API, and one good way to find those kind of API is to look at our siblings on the web.

The MDN Web Docs Web APIs

Let see the URL API for example

The great thing with Web APIs is that they are reviewed by many experienced developers (and usually working for the big FAANG), they have a github repo and am official specification, simply put many many dev scratched their brain to produce a good API, with examples, what is considered valid/invalid, etc.

that save a lot of work, if off course you can consider this API useful

So it might not be as useful as “we HAVE TO embed this API into the runtime”
but it is definitely a good and solid candidate for a “web library”, things I like to name “glues”
as it help glues code from different context/platform into the Redtamarin context.

Embedding or not embedding an API can be a tough choice in Redtamarin sometimes,
as a general rule if it is a C functionality like mkdir(), there we need a native implementation,
because underneath it is a system call, we want to make it work cross-platform so yeah it HAS TO be embedded, eg. you can not rely on loading an external library.

Something as small as mkdir() is what allow to implement other APIs,
for example in the Flash Platform API File.createDirectory()
or in PHP glue library, the mkdir( pathname:String ):Boolean global function
or in a Node.js glue library, fs.mkdirSync( path )
etc.

The Redtamarin Native API use it in FileSystem.createDirectory( filename:String ):Boolean

It is so essential that it HAS TO be embedded.

In other cases it could be other reasons:

  • speed
    even if we implement as a kind of polyfill written in AS3
    we can later re-implement it as native C/C++ to gain speed/performance
  • size
    even if we can embed API, some API can be bigger than others
    do we really need to have the full S/MIME library when then runtime
    only use a couple of MIME types? maybe not
  • should be native
    but we don’t know how to do it yet or other native API are missing to do it
    so we define the functionality (kind of reserving the space, the name, etc.)
  • could be native
    but we need it to be in AS3 first to iterate through the different options and usages faster
    eg. it is much faster to refactor AS3 code than C++ code
  • strict minimum
    we need a specific functionality, ideally it should lead to a full library implementation
    but we prefer to focus on that solo functionality and leave the harder work of a full blown
    library for later, for ex case of zip library, right now we just need to be able to extract from a
    zip, ideally a full zlib in the C API or a full AS3 zip library would be better
  • dependency nightmare
    Let’s say for the sake of the example that Redtamarin could render like Flash or AIR
    a popular library like starling would not be embedded, it would stay as an external library
    because you don’t want the runtime to force you and lock you to a particular version
    of that library

A lot of pros and cons again :slight_smile:

So to summarise a bit, in the same way when a programming language is designed it borrows from previous or pre-existing languages, let’s do Object this particular way, let’s do Array this particular way, oh let’s reuse RegExp, oh lets’ borrow the Date class from Java, etc.

All this mix up of those inner and borrowed features create the pros and cons of that particular language, let’s say it gives you a certain amount of design strength in your code, as “it is easy” to do that, “less easy” to do this.

This design strength can be extended, some big languages come up regularly with new versions:
for ex: Java 6, 7, 8, etc. , some other languages like JavaScript use polyfills (in relation to the browser runtime), and with ActionScript 3, while keeping the original nature of the language, we can extend focusing on the API.

Some people may argue that ActionScript is dead because a new version will probably never see the light of day, but if you can extend the language with new APIs and libraries that’s where you show this language has more than enough room to grow to be modern as any other languages.

And so I will end up with one example: the Date class
it is there in JavaScript and so ActionScript inherited from it

On MDN - Date, you can read

TC39 is working on Temporal, a new Date/Time API.
Read more about it on the Igalia blog and fill out the survey. It needs real-world feedback from web developers, but is not yet ready for production use!

and so on Igalia’s blog you can read Dates and Times in JavaScript

JavaScript Date is broken in ways that cannot be fixed without breaking the web. As the story goes, it was included in the original 10-day JavaScript engine hack and based on java.util.Date, which itself was deprecated in 1997 due to being a terrible API and replaced with a better one. The result has been for all of JavaScript’s history, the built-in Date has remained very hard to work with directly.

All of this apply also to the ActionScript Date class

you can also read

Ideally we should have the same concern about all of this in ActionScript,
to stay relevant and vibrant the AS3 community should work on improving
the language API piggybacking on what is happening in the ECMAScript community.

Redtamarin will try to do that, as providing such API for Redtamarin runtimes/libraries etc.
in a compatible way so it can be used with Flash/AIR “as is”, a temporal.swc if you want.

But ultimately those kind of API should be a community effort because there is so much 1 guy from 1 OSS project can do :smiley:

1 Like