Frogboy Frogboy

Lua vs. Python

Lua vs. Python

In previous journals we’ve discussed the intention to create a modding layer that would use Python as its scripting language.  Python is slower than Lua in terms of interpreted languages but there’s nothing stopping us from having C++ source that people could use to in addition or instead of a scripting language for performance sensitive elements of a game.

With that said, let’s hear from those familiar with both on what they think of either one and why.

405,595 views 157 replies
Reply #76 Top

Kael, could FFH have happened without C++ modding?

Reply #77 Top

Quoting Gwenio1, reply 64


The point is invalid (or undefined) operations will fail. And I am sure player will be pleased when the amount of gold they have is a bunch of emotes.
End of Gwenio1's quote

It's just a different method to coding. Having to check for types isn't worse than having to convert between types.

Typeless variables aren't necessarily better but they're not necessarily worse either. You can mess them up with bad code just as you can strict types.

Reply #78 Top

I have experience with all mentioned technologies. My vote for Python.


Lua is not bad, but it have clumsy Pascal-like syntax and have relatively poor support.
C++/AngelScript is good choice, actually, but it is still C++ ;)
And at last, Python is rapidly developing and has tons of features. And have new-gen syntax style which is light and pretty easy to learn. And it is much easier to learn then C++ and Lua

Reply #79 Top

Always gets me to smile when the newness of of style and syntax troupe gets a walk around the block.

Technically true since 1966 is a whole eight years after 1958.

Reply #80 Top

All the arguments I'm seeing in favor of C++/Angelscript appear to be oriented toward making things easier on proficient programmers rather than making it reasonably easy for a non-programmer to pick up.  Not liking those arguments.

Reply #81 Top

And at last, Python is rapidly developing and has tons of features. And have new-gen syntax style which is light and pretty easy to learn. And it is much easier to learn then C++ and Lua
End of quote

Couldn't disagree more.. i found python more confusing than C++ in attempting to learn them. (not that i'm very fluent in either)

This is what really annoys me in this whole discussion. How in the world did python get the reputation of being so much easier to learn than any other language? I found it horribly complex in comparison to other languages i've learned and gave up on it. Whats the criteria for an "easy to learn" scripting language? Cause i Personally don't see it in python.

TBH i'm not worried about what language they choose.. if its something i'm comfortable with i'll mod if not.. i won't. I just want to know where all the python is easy to learn rhetoric came from.

Reply #82 Top

If you really want good mods, you will need a C++ DLL.

If you also want to integrate scripting I prefer Lua over Python. C# friggin rocks as a language but I've never seen it integrated into a game. In my Civ mapping, I made PerfectWorld2 with Python for Civ4 and PerfectWorld3 with Lua for Civ5. These two scripts use many of the same algorithms, and Lua is many, many times faster. You can't ignore speed when your making games. The transition from Python to Lua was pretty easy, I downloaded an easy OOP scheme for lua on the internet that works fine. Indexes starting at 1 are a non-issue, I ignored this issue with no ill effects and started my arrays at zero. You just have to adjust if you want to use the built in list sorting and what not.

The advantage of Python is that for almost anything you want to do, there's a free library for it. This advantage does not really apply to games however. That you can write a web server with 3 lines of code doesn't help you as a modder. 

Reply #83 Top

Quoting Heavenfall, reply 77

It's just a different method to coding. Having to check for types isn't worse than having to convert between types.

Typeless variables aren't necessarily better but they're not necessarily worse either. You can mess them up with bad code just as you can strict types.
End of Heavenfall's quote

In the case of preforming an undefined operation, it is big. Having it not fail would be like accepting XML with a tag that does not exist (likely misspelled) and then not preforming as intended. In such a case it would be better for the loading of the XML to fail right then and tell you where the failure occured. While it is not perfect protection it can save lots of bother when it does catch a mistake.

Reply #84 Top

Likewise, having to convert different types can be annoying too. There are upsides and downsides to both, as I was explaining. =)

Reply #85 Top

Quoting eteq, reply 70
One other thing:  there has been a fair amount of discussion about multithreading... First of all, I found it doubtful most modders will be inclined to use any extensive multithreading given how buggy it is if you're not very careful (as Frogboy's AI posts have frequently noted!).  So I think overall it's a fairly moot point.  But even so, depending on how the scripting is written, it is most likely straightforward to get around Python's GIL limitations by just running another process, either by designing the bindings to the Kumquat engine that way, or using the multiprocessing module directly. In my experience, this is actually much *easier* to write than multithreaded code, because you don't have to worry as much about locking access to various objects (processes generally have to share via messages or pipes instead of actual objects).
End of eteq's quote

Even if they do not, Elemental does use multi-threading and may (will) call multiple scripts at once. In this case the scripting engine must be able to deal with it without too much overhead.

And there is no reason for a script that just preforms calculations based on data passed* to it should require a second process or not be able to run at the same time as other such scripts.

* As in it gets data in away that will not let it change anything. Changes will be done elsewhere based on the result.

Reply #86 Top

Quoting SirBedwyr, reply 80
All the arguments I'm seeing in favor of C++/Angelscript appear to be oriented toward making things easier on proficient programmers rather than making it reasonably easy for a non-programmer to pick up.  Not liking those arguments.
End of SirBedwyr's quote

It would also make the transition from scripting to programming easier if a modder determines thay need more control. There would be somethings that need to be relearned but most of the transistion would be learing the new features that make the change worthwhile.

Whatever scripting langauge is chosen there will be about the same amount to learn, but some people will find one more intuitive than the others.

Reply #87 Top

Quoting Prime9, reply 71

And to the people requesting that C++ is used, do you *really* want to be in a situation where a rogue/malicious mod has the full privileges of the game to do things to your system? It's very hard to properly sandbox native code - possible, but hard, and is it really worth Stardock spending time on that for this game, rather than spending time on the game itself? Whether intentionally or accidentally mods written than way would be far more likely to corrupt/crash the game, or play merry hell with your system - I'd much prefer a nice isolated scripting language that has absolutely no way of calling outside it's well defined API, and doesn't have opportunities for all the funky pointer math that could screw up said sandbox.
End of Prime9's quote

Doesn't Python have similar sandboxing issues? I don't know the specific, but I seem to remember that Wesnoth moved away from Python due to the problem of untrusted code. For example, is it possible to prevent code from calling "import" and the like without directly hacking the interpreter?

As for Lua, it is possible to have it call untrusted code while only giving the functions that you want. I have seen a situation where Lua code was called with zero functions (not even print), which is obviously what you want to do if the file is supposed to be pure data and is not trusted at all.

Reply #88 Top

Quoting Ephafn, reply 87

Doesn't Python have similar sandboxing issues? I don't know the specific, but I seem to remember that Wesnoth moved away from Python due to the problem of untrusted code. For example, is it possible to prevent code from calling "import" and the like without directly hacking the interpreter?

As for Lua, it is possible to have it call untrusted code while only giving the functions that you want. I have seen a situation where Lua code was called with zero functions (not even print), which is obviously what you want to do if the file is supposed to be pure data and is not trusted at all.
End of Ephafn's quote

In other words to sandbox the mods we would have to go with AngelScript or Lua (with out the standard library) and have no DLLs. This would make complex mods much harder so it is unlikely that it will be the route taken.

Reply #89 Top

Quoting Heavenfall, reply 84
Likewise, having to convert different types can be annoying too. There are upsides and downsides to both, as I was explaining.
End of Heavenfall's quote

There's a big, big difference between being annoying for a minute while you get your types straightened out, and being annoying for months and months because you accidently misspelled something and put a garbage value deep in your code that causes it to fail one in twenty times! Strong typing goes a long way to eliminate some of the most insidious errors by catching it in the compiler.

Reply #90 Top

Sandboxing is not an issue for me. I download and run anything I find on the internet that seems fun or useful to me. I rarely investigate who made it or why, I always take their word for it that it does what they say it does. I may have gotten some malware one or two times but no big deal.

Reply #91 Top

None of the languages discussed have especially strong typing (they have far from weak systems but there has been much more research done). Catching errors in compilation in languages without much of type inference doesn't catch any noticable percentage of insidious errors.

Reply #92 Top

Quoting cephalo, reply 89

Quoting Heavenfall, reply 84Likewise, having to convert different types can be annoying too. There are upsides and downsides to both, as I was explaining.


There's a big, big difference between being annoying for a minute while you get your types straightened out, and being annoying for months and months because you accidently misspelled something and put a garbage value deep in your code that causes it to fail one in twenty times! Strong typing goes a long way to eliminate some of the most insidious errors by catching it in the compiler.
End of cephalo's quote

I'm not disputing that. But if you're comfortable with typeless, mistakes like that happen very rarely. I'm not saying either is better, I'm just saying they're different and neither should be considered "pros" for their languages.

Anyway, python variables are typeless and so are LUA so we're not really talking about a tradeoff here. It's either of those, and maybe C++ on top (technically in the bottom).

Reply #93 Top

Quoting SirBedwyr, reply 80
All the arguments I'm seeing in favor of C++/Angelscript appear to be oriented toward making things easier on proficient programmers rather than making it reasonably easy for a non-programmer to pick up.  Not liking those arguments.
End of SirBedwyr's quote

The non-programmers will still have access to the XML modifications. I think that this level needs to be for modders who are beyond the beginner level as far as programming is concerned.

Reply #94 Top

Quoting Heavenfall, reply 92
I'm not disputing that. But if you're comfortable with typeless, mistakes like that happen very rarely. I'm not saying either is better, I'm just saying they're different and neither should be considered "pros" for their languages.

Anyway, python variables are typeless and so are LUA so we're not really talking about a tradeoff here. It's either of those, and maybe C++ on top (technically in the bottom).
End of Heavenfall's quote

Given that the scripting is provided for a simple way for the inexperience to mod the game's functionallity, anything that prevents them from having errors that are hard to track down is a big plus.

--------

http://www2.research.att.com/~bs/C++0xFAQ.html#auto

Reply #95 Top

Quoting Anangara, reply 91
None of the languages discussed have especially strong typing (they have far from weak systems but there has been much more research done). Catching errors in compilation in languages without much of type inference doesn't catch any noticable percentage of insidious errors.
End of Anangara's quote

Just to check, by type inference do you mean it as defined at http://en.wikipedia.org/wiki/Type_inference?

Reply #96 Top

Quoting Gwenio1, reply 94

Quoting Heavenfall, reply 92I'm not disputing that. But if you're comfortable with typeless, mistakes like that happen very rarely. I'm not saying either is better, I'm just saying they're different and neither should be considered "pros" for their languages.

Anyway, python variables are typeless and so are LUA so we're not really talking about a tradeoff here. It's either of those, and maybe C++ on top (technically in the bottom).


Given that the scripting is provided for a simple way for the inexperience to mod the game's functionallity, anything that prevents them from having errors that are hard to track down is a big plus.

--------

http://www2.research.att.com/~bs/C++0xFAQ.html#auto
End of Gwenio1's quote

Similarly, if you're an inexperienced coder you want to avoid taking extra steps to reach the same result.

Reply #97 Top

Quoting Gwenio1, reply 95



Quoting Anangara,
reply 91
None of the languages discussed have especially strong typing (they have far from weak systems but there has been much more research done). Catching errors in compilation in languages without much of type inference doesn't catch any noticable percentage of insidious errors.



Just to check, by type inference do you mean it as defined at http://en.wikipedia.org/wiki/Type_inference?
End of Gwenio1's quote

 More or less yes. Haskell witch I regularly use goes beyond H-M type inference to Lambda Cube and System F territory. One of many fun things possible in second order type systems are tools that given a function signature gives a suggested function implementation for that signature.

Reply #98 Top

Quoting Heavenfall, reply 96

Similarly, if you're an inexperienced coder you want to avoid taking extra steps to reach the same result.
End of Heavenfall's quote

Generally you never use casting until you reach more advanced things, and by then the complexity is great enough that can go wrong without having to keep track of types as well.

The one exception is integer division, where you need to turn it into a type that can hold decimals so you do not lose them.

(The following code is AngelScript, though it can be done in C++; however there it is not good form)

Code: c++
  1. int a = 5;
  2. float b = float(a) / 2; // The result will be 2.5
  3. float c = a / 2; // The result will be 2

Other then this you do not really need type conversions till working with polymorphism and pointer arithmatic.

Hopefully all values that are intended to be used for calculations will already be of a type that can hold decimals so that not even this will be needed by beginners.

Reply #99 Top

I'd go with whatever language would offer the most power and ease of access to a hypothetical Elemental fan with little to no coding experience and offer C++ (or whatever) to the experienced scripters. The reason being is that the easier it is for Average Joe Gamer to mess with stuff, the easier it is for the Average Joe community to get excited about any and everything. Few things are more powerful than word-of-mouth advertisement combined with people being able to pimp out their own stuff.

 

I'd rather see 10,000 would-be designers getting excited over a bunch of rocks and leaving the headaches to the 100 experienced scripters who have the knowledge to handle problems over 10,000 would be designers getting frustrated and waiting for the 100 to do something slightly faster/better in 10 days instead of 14. The 100 experienced scripters can handle themselves and will figure things out on their own. The others, not so much.

Reply #100 Top

I would pick Python.

For those that are adding in a pick of C++ . . . remember that C++ is NOT a scripting language. Lua and Python are, which is why they were chosen. Also C++ libraries can be easily ported into the two scripting languages so really no matter which one is picked you C++ buffs will still be able to work with it. You might just require a few extra steps to import your functions.