Scripting Language for Vassal

Hi Joel,
Tim and I where discussing scripting languages for Vassal 4, plus what is going into Vassal 3.2. I had planned to introduce scripting into v3.2 using beanshell (i.e. Java) , but it will be incredibly confusing to have 2 different scripting languages in the two versions.

If we can come to a decision on the V4 scripting language, I think I should change over and use it as the v3.2 scripting laguange also. This will provide consistency accros the versions and allow module developers to start ‘training up’ prior to V4.

Tim mentioned that Python and Lua seem to be the front runners. Both have Java interfaces that I can use to build them into v3.2.

So what is it to be? I have no preference, not having used either.

Regards,
Brent.

Thus spake swampwallaby:

Hi Joel,
Tim and I where discussing scripting languages for Vassal 4, plus what
is going into Vassal 3.2. I had planned to introduce scripting into v3.2
using beanshell (i.e. Java) , but it will be incredibly confusing to
have 2 different scripting languages in the two versions.

If we can come to a decision on the V4 scripting language, I think I
should change over and use it as the v3.2 scripting laguange also. This
will provide consistency accros the versions and allow module developers
to start ‘training up’ prior to V4.

Tim mentioned that Python and Lua seem to be the front runners. Both
have Java interfaces that I can use to build them into v3.2.

So what is it to be? I have no preference, not having used either.

Unfortunately, I think we won’t be able to get a good idea of which
will be more appropriate until the C++ API that they’ll have access
to is defined, so we can see what default scrips for existing traits
would be like in each language.

Instead of immediately turning to 3.2 work next week, I could try
to write down a design description for all of this that we could
pick at.

I’m a bit dubious on the point about getting module developers familiar
with a scripting language for 3.2—one one hand, I get your point about
synatx familiarity, but on the other hand, the tasks to carry out in
the scripts will be quite different between versions…

I did some reading about Lua and Pythjon this morning:

lua-users.org/wiki/LuaVersusPython
stackoverflow.com/questions/3561 … -or-python
thinkbeforetype.com/2010/09/12/l … -language/
forums.xkcd.com/viewtopic.php?f= … w=previous

Two things I picked up on which I see as warts in Lua are the 1-based
arrays and default global scoping. (That second I think will mess up
novices; the first will mess up everyone.)

I came across this, which was also interesting, and would seem to be
applicable regardless of which scripting language we choose, even though
the author is speaking about Python only:

twistedmatrix.com/users/glyp … endit.html

I’m don’t have a clear opinion on this last one. Food for thought.


J.

I’m a bit dubious on the point about getting module developers familiar
with a scripting language for 3.2—one one hand, I get your point about
synatx familiarity, but on the other hand, the tasks to carry out in
the scripts will be quite different between versions…

Scripting for 3.2 seems like it would be a waste of time for everyone. I
wouldn’t be prepared to make difficult decisions this early–ones that will
be written in stone for 4.

Two things I picked up on which I see as warts in Lua are the 1-based
arrays

You mean like most languages before C? If you’re not a programmer, 1-based
arrays are far more intuitive. C uses 0-based arrays because it’s a very
low level language (and because arrays are actually pointers).

and default global scoping. (That second I think will mess up
novices; the first will mess up everyone.)

For a non-programmer, global scoping is more intuitive.

I came across this, which was also interesting, and would seem to be
applicable regardless of which scripting language we choose, even though
the author is speaking about Python only:

twistedmatrix.com/users/glyp … endit.html

It’s a cute idea. Not sure if it’s a good one or not. I’ve never seen it
done.

  • M.

Thus spake Michael Kiefte:

Two things I picked up on which I see as warts in Lua are the 1-based
arrays

You mean like most languages before C? If you’re not a programmer, 1-based
arrays are far more intuitive. C uses 0-based arrays because it’s a very
low level language (and because arrays are actually pointers).

I find 0-based arrays more intiutive. I always found it weird how in
North America, arrays of floors (a.k.a. buildings) are numbered from
1 instead of 0.

More seriously, virtually every other modern programming language has
0-based arrays.

and default global scoping. (That second I think will mess up
novices; the first will mess up everyone.)

For a non-programmer, global scoping is more intuitive.

What should this program do?

x = 1

function foo() {
x = 3
}

foo()
print x

If you think the right thing is to print 3, then this means that you
have to make sure that you never reuse variable names on pain of
catastrophe. This becomes harder for programs which aren’t eight lines
long. The other language which is like this is JavaScript; I found
dealing with this to be painful almost right away.

I came across this, which was also interesting, and would seem to be
applicable regardless of which scripting language we choose, even though
the author is speaking about Python only:

twistedmatrix.com/users/glyp … endit.html

It’s a cute idea. Not sure if it’s a good one or not. I’ve never seen it
done.

I haven’t wrapped my head around what this would look like, yet.


J.

ROTL

Reading this was like seeing a flashback of my entire career as a software developer. I have seen every mistake he describes over my career as a developer, and have unfortunately worked on projects that made several of them together (Those ones were, fortunately, short-lived.)

imho:
If event/action scripts are divided into separate segments, than “global” scope within that segment makes a lot more sense. Accessing global or dynamic properties is then always done through API calls, so there is no mix between local variables and truly global properties. Scope is not really something to worry about then and, if done right IDE wise, would be easier for novices I think. REAL Studio is an example of where you get a separate coding window for each method, function and event (it still has variables at different levels and different scopes, but I’m just using the idea of IDE splitting up the code in different segments for you).

If all custom script code is done in one huge block, like how Visual Studio shows all code in one long file for example, then scope of variable becomes very important, and the scope of variables should not be always global.

Thus spake bdgza:

imho:
If event/action scripts are divided into separate segments, than
“global” scope within that segment makes a lot more sense. Accessing
global or dynamic properties is then always done through API calls, so
there is no mix between local variables and truly global properties.
Scope is not really something to worry about then and, if done right IDE
wise, would be easier for novices I think. REAL Studio is an example of
where you get a separate coding window for each method, function and
event (it still has variables at different levels and different scopes,
but I’m just using the idea of IDE splitting up the code in different
segments for you).

If all custom script code is done in one huge block, like how Visual
Studio shows all code in one long file for example, then scope of
variable becomes very important, and the scope of variables should not
be always global.

I think there are independent reasons for wanting to avoid having all
script code in one monolithic block.

However, there will likely be some scripts which define their own
functions, do recursion, etc., and for those, having variables be block
local by default is a natural thing to want.

As global variables are generally cause a mess anyway, I’m inclined to
say that it’s just the wrong default.


J.

Hi all. I’m starting to program a Vassal module. Should I hold out for Beanshell/Python instead?

As far as “training module makers” goes, I’d say let them (me too) have Beanshell first. Why? Because those of us who bother to code complex logic will also be organized enough to document our logic. We write pseudo codes as “logic documentation”, rather than rely on Vassal’s Traits presentation to remind us what logic we coded.

Our pseudo codes can easily be ported over to Python when Python gets used eventually.

Also, +1 for Python. I’m having enough trouble coding for Vassal when every property is global or “almost private but not quite” (no re-entrant function reuse possible). Plugging in Lua will only present us an old enemy in new fashion.