For once, if there is one thing that has been done correctly with the Redtamarin project
is right from the start to clearly declare a Mission Statement and stick to it
To support the use of the AS3 language for cross-platform command-line executable,
as single exe either for the desktop or the server, as scripts for automation,
as tools for the Flash Platform community.
and btw little rant
the name of the project is Redtamarin or redtamarin,
one word, no spaces, can use a uppercase letter at the beginning of phrases etc.
it is not “Red Tamarin” or “Red tamarin” or “ReDtaMarIn” or whatever the fuck
careless inbred assholes who can not read to save their lives misspell it.
Let’s Talk about Platforms
For example, look at the .NET Core documentation
and if you follow the link to " Get started with .NET Core", towards the end you can find a video under “Tutorials”
Indeed that is a very good example of introducing and presenting a platform.
In the tittle I mentioned “the ActionScript Platform”, in the mission statement above you can read “the Flash Platform”, and that is basically our problem.
With the backslash on Flash and the Flash EOL, we simply can not use the word “Flash” to promote a platform, at the very best it would be fighting an endless battle of explaining “why it is not dead”, and at the very least it would be just bad marketing.
So here the situation, with Adobe distancing themselves from Flash, and AIR, and almost everything related to those, we are in a situation where a platform do exist but without a big mogul to back it up.
At the Redtamarin level, yes it is open source, yes it is about ActionScript (and AVM2, and cross-platform etc.) but the Redtamarin project can not claim of being the ActionScript platform, hence why the mission statement is so important.
The ActionScript platform is something much bigger than just Redtamarin, at best redtamarin is just one part of it, focused on the command-line.
The other parts are listed there in Why ActionScript is not a dead language and include among others: AIR SDK by Harman, Apache Flex, Animate CC by Adobe, Apache Royale, etc.
Any of those parts alone can not claim to be the ActionScript platform,
but all those parts put together constitute that ActionScript platform.
I would argue that the name “ActionScript platform” is maybe not illustrating well what the platform is, I kind of use it as default for now, but in the larger crowd it would be any projects related to the ActionScript programming language, or related to ActionScript compilers, or related to producing runtimes using AVM2 (avmplus) at their core, etc.
My point is we need to call that platform something, like Microsoft use the word “dotnet” for their .Net platform, so all the lost children of the Flash Platform can gather around and appear stronger under one same banner.
What is Tooling and Why do we need it?
Tooling is what developers use to setup, configure, prepare, organise, automate, etc. their projects,
and in general it starts at the command-line.
The ActionScript community is a bit resistant to that kind of tooling,
they use it without knowing it, sometimes they know it exists, but there is a loooong history of favouring tools with a face, eg. GUI tools, and being oblivious (or simply ignoring) the command-line.
Look at Animate CC, and before that Flash builder, even if those software reuse command-line compilers and other SDK, they are “hidden” behind visual interfaces.
And it’s kind of natural, from the very first steps where they used Flash and ActionScript, they never seen a command-line, but instead a “debug output” in a “debug panel” or a “debug view” inside an IDE.
Yep, Flash/ActionScript never gave the option to run on the command-line, the output was always visual: a SWF running in a standalone flash player or in a browser window.
Those command-line tools are as important, and I would say as vital, as the open source projects.
It goes like that “oh that task I need to build this project is long and cumbersome to do by hand, if only I had a little tool that could do it for me”, and then someone build that tool, distribute it, and however how small problem it is solving, if it make dev earn precious time then this tool is adopted, and on, and on, etc.
Historically with Flash/AIR we did not really miss that kind of tools because most of those cumbersome stuff were done for us, look at AIR: let’s define some
.png at some specific sizes in an app xml, and when we compile it the compiler take care of generating the correct icons for Windows, macOS, Android, iOS, etc.
At best you could automate a little the generation of those few different
.png files from one
.png, but that was about it.
Now if I was telling you that there is a small command-line tool that exists, and if you pass it a single
.png file, it will generate everything you need for Android and other iOS dashboard, or patch your macOS AIR app to include the right
.icons files etc., you would certainly be interested by it, simply because it would save you time.
As a community we need open source libraries as much as we need those command-line tools (open source or not, but in general open source).
Why Redtamarin vs Something else?
You can build command-line tools with pretty much anything, but if you look closely you can see a general pattern: dev working on a specific platform reuse the programming language of this platform to build their tools.
It is just easier to write your tools reusing the language of the platform you are building that tool for.
With Flash/AIR, well… we didn’t had a hard need for such tools because what was distributed really?
.swc files for libraries/frameworks, maybe single
.as files (eg. mrdoob/Hi-ReS-Stats), and before
.mxp files via the Adobe Extension Manager.
In this post, where the tool is described (what problem it would solve, how it should work, etc.), came off course the question: but what programming language to use to build this tool ?
Redtamarin is mentioned because it focus on ActionScript for the command-line but people are “not sure” and other mention Java because the main ActionScript compilers are written in Java.
So not wanting to be too much on the defensive but some people really don’t get it.
If your community wrote their GUI programs using mainly ActionScript as their main programming language, right there if you pick anything else than ActionScript you cut off a good part of your community being able to create and contribute to the whole tools ecosystem for that platform.
A package manager is not just one tool, maybe it is 2, 3, 4, more tools
if @marchbold talk about apm because he identifies some needs and problems around ANE,
few years ago I talked about distro (see there, and Distro the AS3 package manager, and About distro and learning from npm)
Do we need one tool that deal with everything?
Do we need many tools with each one their own scope?
And honestly, I had other priorities so yeah I let that particular tool slide and many of what I wrote about it is either outdated (eg. Adobe Extension Manager), and on many things my view evolved on “I don’t need that, I need this instead”, so quite glad I did not invest time into it.
So that apm tool, should it be written in ActionScript? in Java? other programming language?
My guess is if Java is used, less people will contribute to it with the logic: hey if those dev already do not compile Java to build their own ANE, what are the chances they gonna write Java code to help build this tool?
With ActionScript the logic would be more: “hey I already write my app in ActionScript, this tool could be useful to me and hu ho it is just ActionScript, it would not be too hard to contribute”, even if they need to learn a bit of Redtamarin that for some can be seen as something foreign.
Thing is, whatever is used: AS3, Java, anything else, it would not save dev from solving the hard problems related to such tools, what problems? oh … here a little sample
you need an installer, package, something to distribute the tools
one little advantage of Redtamarin is that you can end up with a single binary
eg. no dependencies, no need to install a JDK or other stuff to make it work
no matter what you will have to detect that stuff are at the right place
things like environment variables, filesystem paths/files, config files, etc.
that’s the platform part, is it a tool only for AIR? or does it deal with AS3 in the large?
does it only distribute ANE / config for ANE ? or can it distribute SWC libraries too?
where does it install stuff? in the current folder? in a global path?
can it deal with multiple versions of the same library/package?
where does it fetch the version? the updates?
the web / the store
it need to list those libraries/packages/stuff somewhere, usually a web site
so those are 1. discoverable, 2. searchable and 3. updatable
it’s not just a command-line tool, it is also a site
hey what programming language do we use to build the site? Java?
But here the main problem, the elephant in the room to say the least.
Building this tool solo gonna get old pretty fast, even if someone could use “shortcuts” like hosting only on Github and reuse Github API to fetch/update/etc. those libraries (and so not have to host the site on their own server), I still say this need a team of dev.
And I’m not even trying to defend the use of Redtamarin, “as is” what people can see of redtamarin is 4+ years old, it has been heavily updated just not public yet and so if you would need to use it now to start a project I would advise “wait a little bit, not ready yet” (ideally soft release around October, and big release January 2021 but technically it will be ready when it is ready).
But in term of tooling, the Redtamarin SDK will distribute about a dozen command-line tools, some easier than other, for ex:
projectormake are simple and others like
asc.jar ported to AS3) much more complicated (and will not be part yet of that next release), some not written in AS3 like the runtimes
redshell, and other doubling down on AS3 like
And here what I can say about tooling and using AS3 (and Redtamarin) to build command-line tools, and yeah perfectly admitting I could be completely biased and not objective here, but still …
the experience is fucking great, beats hand down anything else I know
my only problem is I can not show it now because it is not ready as it should be ready
But I can talk about the experience
A tool is about saving time, you want it small and nimble, focused on the task at hand and you want it fast and now
That’s why you would build it on the CLI first, it is just faster there
One could imagine “hey I can build my tools with AIR”, oh yeah you can
but for the 1 week you would build this tool with AIR I can build mine in 1h with Redtamarin
just because of the CLI vs GUI
If later I absolutely need a GUI, yeah sure I can then build a wrapper in AIR that reuse the CLI tool functionalities, or reuse the AS3 sources directly in AIR
There I’m talking also about the granularity of the tool itself
if what you need can be quickly written in 1h and be good enough for your need, you want that
but what you also want is to be able to evolve the tool to more complicated tasks
without having to restart the tool from scratch
as3shebang you can start to write the tool right away as a small script file,
not even need to compile it, just run it
Later on, maybe you update this script so much that now you need a reusable library for specific tasks, then you can transform this script into an
.swc, and your other tools that want to reuse those functionalities can then just dynamically load that lib
And then later, this tool has become bigger where you need a program “that contains everything”, something that can act as a reusable binary, just take that
.swc etc. and merge it with a runtime like
redshell and voila you got a projector, and you can just distribute it “as is” no need to be sure that a SDK is installed or that some dependencies are installed at the right place on the system, etc.
You can easily iterate steps by steps building this tool at your own pace, making it bigger and stronger over time
Let me give a little example:
When working on an AIR app for the desktop I needed icons for some buttons
something very basic grab a
.svg from FontAwesome something and use
[embed] and bahboom I got a nice icon in my app
It was fun doing that for a couple of icons but I needed more than 2 or 3 of them
so I fire up a little tool just using
as3shebang where I can pass as an option the name of the SVG icon and the tool go and download it from Github and place it in the right folder
Ok nice … save some time
So I keep it up, hey I added a template with few tokens, and now the tool not only download the SVG icon, put it in the right folder and generate an AS3 class based on the template where everything is setup automatically, now the time to get a new icon into my app is literally few seconds
Later, I needed the same thing but from another library, I tin it was ioicons or something,
just took the same tool, added few options, few more code, etc. and now I can get “instant icon” almost from 2 different open source lib, and then 3, and then 4 etc. icon libraries
I probably spent 2h working on the tool, I use it all the time and I gain a lot of time not doing that kind of stuff by hand
I got tons of little tools like that
all written in AS3, all running with Redtamarin