Purpose - KidneyThief/TinScript1.0 GitHub Wiki

So with the plethora of scripting solutions available, why create TinScript?

• I've been a software engineer for 20+ years, and have experienced what seems like the entire spectrum of "scripting is evil" to "the entire world should be scripted".
• I've also experienced the range of involvement from simply being a client, to being both the person integrating the language, and (perhaps more relevant) being the key person responsible for supporting the dozen non-technical designers using the language.

I have integrated multiple scripting language into half a dozen projects - in several cases I transitioned between different languages, which allowed for side-by-side comparisons of functionality, ease of use, and profiling.

What I had not done up to this point, is actually implement a language, so I wanted to "put my money where my mouth is".

I wrote Tinscript to focus on 3x aspects of development, theoretically to improve on each:

• Debuggable
  • When an implementation doesn't execute as expected, figuring out where the assumptions are incorrect are relative to how easy the system is to figure out. In the case of a "black box" solution that is outside the normal C++ environment, it is even more critical that the system be transparent.
  • TinScript uses a very straightforward interface with no unnecessary complications, in everything from its integration and binding, it's parsing, and the execution of its virtual machine.
  • At each step, there is also debug support from displaying the parse tree, to tracing through the VM, to a complete display of an object's hierarchy of members, methods, and group organization.
• Iterative
  • The ability to pause the system, implement methods and/or modify a script, unpause and see your changes happen live - without having to shut down, recompile, re-execute and reproduce the symptoms that prompted the change in the first place - iteration speed has a huge impact not only on quality, but on enjoyment as well.
  • It's a step forward to being able to reload scripts - but it's a big leap forward if you can do this *without* destroying or restarting the objects depending on them.
• Effective
  • A fairly broad and ambiguous term - but ultimately is a measurement of the ability to get the job done with a solution that is solid, quickly implemented, and developed naturally without the feeling of excessive jumping through hoops, or red tape.
  • The paradigm of class hierarchies from C++ is already a powerful standard - TinScript was built, not to provide an alternative, but to support this by extending the hierarchies at runtime.
  • The use of a scheduler allows for less "manager" implementation, allowing objects to update themselves, or to cause an "event" to happen at a later time without needing a system to babysit the request.
  • The support of object groups and sets also generalizes the "manager" concept of maintaining a specific collection that is updated/queried/processed in some specific way.
  • And finally, the provision of n-dimensional associative arrays is a convenient way to organize data and data relationships. It's a useful tool for configuring an environment, setting up sets of tunable parameters, initializing objects, etc...