I've read this not so positive review of the Galaxy scripting language (
http://www.sc2mapster.com/wiki/galax...uage-overview/).
That page is not finished. I was in the process of rewriting it but was told to stop because they were doing stuff with their Wiki (removing it, moving it, something like that) which they never finished doing. As such pretty much only the introduction was done. It was not even meant to be a review but more a technical manual.
I wonder how much of that is actually true.
Technically a lot of it is true. But that does not make it a bad language.
My question is--is there any major differences between how one writes the map script in JASS versus Galaxy. I don't mean differences between the language, but the style of them (e.g. functional vs imperative programming or a 2 stack push down automaton versus a single tape turing machine). If so, what are these?
Fundamentally both are the same. The only difference is the API you use, the availability of features and the limitations.
One thing I know is true is that a lot of stuff done in JASS can now be pushed to SC2's very powerful Data Editor.
Mostly regarding abilities. This is also sort of required since you no longer have the ability to abuse parallel dynamic arrays for storage like you could in JASS. You can use some form of global hashtable with a naming convention for data storage (Blizzard even recommends it) but this has performance implications which is why it is best avoided when possible (or for performance critical code).
In addition, are there any vJASS equivalents for Galaxy, 'vGalaxy', that provide ways to write more OO code?
There are, but unfortunately they have very bad/non-existent support. Additionally they did not work as well as vJASS.
The main difference is due to the lack of abusable dynamic arrays for bulk data storage. vJASS implemented each object type as parallel arrays for each member. This technically meant that each object had its own unique allocation heap which was dynamic in size (up to ~8192 object instances at once). Galaxy lacks dynamic arrays and due to its memory limit it is impossible to allocate impossibly large fixed arrays for more than a few types. As such objects have to be implemented by storing all data in a single massive general purpose hashtable with a certain naming scheme (similar to how Python does it, but that uses nested hashtables to simplify naming scheme). This means that objects have very poor performance as member lookups are not trivial operations anymore as they involve the generation of at least 1 fairly long string.
As such one is generally recommended to stay away from object orientated programming with Galaxy, at least until more language features are added.
That said many of the features added by JNGP are part of the Galaxy language. For example you can declare global variables anywhere and also declare functions before defining them. You can also use function references to pass around code dynamically (a feature vJASS implemented using more complex Trigger wrappers).
Galaxy also includes a lot of operators missing in JASS. For example bitwise operators and variable modifiers (eg +=, -=).
Generally when scripting in Galaxy one has to think about data management much more than in JASS and vJASS. If you want dynamic objects you need to put a limit on how many can exist. You will also find yourself using singleton patterns more often (a single global instance of an object). You can also find yourself using thread stacks for data management of short lived objects (eg an object only needed during the function call).
Hopefully we will eventually get the ability to use reference types for global variables or return types but until then object orientated programming is quite limited.
