KGJV wrote:QUOTE (KGJV @ Jul 17 2011, 07:22 PM) "non-programmers" is a very vague notion.
There is a huge step between programming in C++ within Allegiance code and writing scripts. That's the whole point here.
A lot of so called 'non-programmers' with enough brain can do nice things with a scripting system whatever the language.
These same persons will refuse to invest time in C++ because of the complexity and burden.
I'm not talking about C++ as a language alone but about a complex C++ project like Allegiance with all the libraries, SDKs, tools and knowledge required.
I think we're thinking along similar lines, a reasonably smart person or at least someone motivated enough to learn, who isn't a programmer (in the sense they could get a job as one / write a decent sized application). I think you're thinking of someone who maybe has done maybe a beginner course of java / python, where as I'm thinking of someone with no real language experience (but has done stuff with say AHK).
Anyway I think we're thinking on similar enough tracks about this aspect that it doesn't need any more discussion.
QUOTE What matters is the global environment.[/quote]
Agreed.
QUOTE I don't see the point designing a brand new language because I want to leverage existing stuff.
Adding scripting to an application can be complex. Using existing parsers and error handling modules of an existing language is the way to go.
Using existing language(s) allows to reuse code too. Either by direct import (with 'modules') or by copy/pasting. Python and JS have a big advantage here, there are tons of existing modules out there for all sort of things.
I might even go for multi-language scripting, leaving the choice to the users. Something like
Active Scripting might be the way to go.
Actually it has already been done in Allegiance. The Pigs system uses it. I might reuse this. Take a look at the original
Pigletsfor instance. You'll see the language is a parameter of the 'pigs'.
The '
scout2' piglet is a nice example of why using a widely used scripting language is interesting. by using JavaScript, they were able to quickly adapt/reuse
Dijkstra's shortest path algorithm in a module and then use it in the piglet (see
include/dijkstra.js). Try doing this with your own language, you'll have to reinvent the wheel.[/quote]
Your point about code reuse is a good one, but I disagree about some points.
I would take argument against you example of the scripter (our novice/non-programmer) re-using Dijkstra's algorithm however, and here's why:
I think the person writing the script (who doesn't necessarily have much programming experience) should only have to worry about
what they what to happen not
how to do it.
I think our script writer should just say something like "GoTo <target> SHORTEST" instead of having to import an implementation of Dijkstra's algorithm to generate a route, then have to create event handlers to handle the change of destinations to proceed along the route and other stuff too. Assuming the script is interpreted (unless you get fancy with JIT compiling and stick a compiler in allegiance.exe) then it could be quite easy to import some processing heavy algorithm that will be interpreted quite slowly (ok, this argument on performance is a bit weak, but it's more a side note).
My point is that our non-expert programmers should be focused on what should be happening in the mission, not how to implement the technical details. I'm not saying they shouldn't worry about any 'how's - in my example language I as the programmer had to think of
how to advance mission objectives using the variables. I didn't however have to program
how to detect if the player was within 1000m of some coordinates (yes, it's easy to program that but it's likely a common requirement so should be a quick executing easy to call function). Our novice programmers most likely haven't even heard of Dijkstra's algorithm anyway.
QUOTE A GUI system is way too soon to even think of it. It could be added later by someone else as it doesn't need Allegiance code to work. That's the advantage of this approach too.[/quote]I actually designed my example language to be simple to generate using a GUI (or perhaps simple to make a GUI for?)
Anyway, this is your project it's up to you what you do. My thoughts are that the mission writers should only have to worry about what happens in the mission and how to make what they want happen, but not how to implement the low level details (like plotting a course in your example*, determining the range between coordinates in my example, calculating the correct turn rate to make the ship lead it's guns on a target for another example). I think that writing a simple language bespoke for this specific task with compiled functions to hide the details of how things are achieved is a good idea. That said I do tend to do things my self when I should use what other people have done (like the time people started talking in morse code on the forums, my first thought was to write my own morse code encoder/decoder, and only after finishing it did I think to google online morse code translators).
*Why did the implementers of pigs need to import an external shortest course algorithm anyway, allegiance already has one in the autopilot code (one which knows about allegiance specific things like teleport receivers and stuff), shouldn't they have been calling that instead if they wanted a shortest course?
) as the cavaet to the next bit
