Glitchfinder":1ra7hf0h said:
*truncated*
The problem is that BASIC is, well, basic. It doesn't cover nearly as much as we need to cover. Not only that, but one of the major reasons we decided on Ruby was the familiarity that many people in the market already have with it, due to RMXP and RMVX. If you want to trade power for ease, that's your business. And there's nothing stopping someone from giving the program the ability to use BASIC, if they really wanted to. In fact, I'm sure that would offer a great deal of profit to the first person to find, implement, and upload a solution.
I hope you realize that 'BASIC' really is only derived from its original acronym, Beginners All-purpose Symbolic Instructional Code, the specifics of how complex the underlying model is, is directly dependent upon the needs of the implementation.
VB.NET, for example, can compete with Ruby, Java, or even C#, it's just a matter of having a proper parser and perhaps compiler for the language that's to that level. The thing with Visual Basic.NET, in this case, is it's statically typed, where the first version of BASIC had no concept of types in the first place, it's a language that's basically adapted to the needs of the standard for the day.
I'm guessing you're choosing a dynamically typed language (?) due to your familiarity with such a model, the potential users will have a basis for comparison versus using another language architecture, where they would not have that point of commonality (RGSS vs. RPG Breeze Code).
Edit: Also, it's not as simple as saying they could simply implement a parser and add-in for your system and make a new language work. They would almost have to have a dynamic language to use, and on top of that your system would have to have a way for the two underlying models to communicate. Object 'A' from the core scripting system being used in scripting system 'B', how would you do that off the top of your head? Make sure your systems designer is aware that there's potential for scripting systems integration so the internal object structures can be exported in some manner, the scopes of the two languages just won't magically work, it's not that simple. From my toying with Lua, C# didn't have direct 'a.bla' access to things, there was a special means I had to follow to invoke methods in the Lua script, I had to access the scope of the LUA architecture using the scripting system provider (the LUA object).
Another way to look at it is this:
Inside Lua, when a script calls a Lua method, Lua knows how to handle that call, because it's defined inside itself.
If you mix Lua with say Ruby, and you want Ruby to call the Lua method, you have to have some sort of intermediary that explains to the two how that works, I haven't used Ruby enough to know exactly how, or if it would even be possible, to capture cases where a method call was made that wasn't in scope (because Method 'a' in ruby and method 'b' in lua are distinct, Ruby doesn't know of Lua's 'b', and the opposite also applies).
Edit 2: The main reason why such interoperability would be necessary is: in order for the user of the new language to use the language, you would have to have the ability for the scopes to mesh; otherwise, they would have to recode all of your scripts from scratch.
Edit 3: For clarity (to non programmers): A
scope is a programmer term that explains what's currently available to a script at any give point in its execution. A
global scope means that, regardless of where the code executes (inside a class, or a type-less method), the items in global scope are available.
Local scope refers to the local variables defined within a method, class/type-scope refers to the values or methods defined on a class/type.
To compare
scope to the internet,
true global scope would be the entirety of the internet, the global scope of an instance of Lua or Ruby would be an intranet, they can't communicate with one another because they don't know they exist, worse yet they both use different protocols to define their intranets; that is unless you created a bigger intranet by
connecting the two somehow, and creating a way for the protocols to work together.
