[Foster]

TomLine has had the best set of comments about scripting. In my world I program at five different levels:

Bare metal - This is low level microprocessor code, it's running on the processor there is no OS involved. I program in C so the steps are compile, download, test. But I have a PIC development environment so I can also do some interactive debugging on my desk before I download code to the hardware.

Robot code on the cRio - Low level code, while there is a kernel OS running, the system needs to be restarted to test. So the code cycle is the same as bare metal

Code on an OS that needs to be restarted - Java and C where the application needs to be stopped and restarted. There is a huge selection of tools that can be used to develop with interactive debuggers to make the development process much faster

Code on an OS that does not need to be restarted - The land of scripts. There is a interpreter process that runs all the time processing the script. When there is new production code the interpreter process is directed to the new script and it runs that. I program mostly in TCL for that environment.

Programs that do X out of the box, but I need to extend the functions. In most cases the company has allowed me to call some "scripting language" from points in their product. For example the proxy server I use allows me to call Lua code to do specific processing of a message. The short fragments allow me to have custom code without rewriting the entire product.

Some of the "faster in scripts" has to do with the functions built into the scripting language or libraries, not with the code. Perl and TCL have some great array and string functions built in so there is less code to write. But there are great Java and C libraries that you can use so the code effort is almost the same.

The key difference in my world is that we use a structured methodology to programming. Analysis, design, code, test, implement. Half the time in analysis and design, 1/4 in code, 1/3 in test. Always the same, C, Java, TCL, Lua. Now there are mentions to "hacking away", just jumping in and cutting code. And those people will take more time because they are not doing the analysis and design up front, they do it and re do it as they go. So there is a good deal of rework as they go along.

But because it's ongoing code, test, code, test, they don't see the embedded analysis and design time. (And I'm a big fan of agile methods (I'm a certified Scrum master) but there is analysis and design going on)

Blake makes a good point about "hacking away" and safety. Not on his plane, maybe on the robot if he's out of the way. Nothing to do with the "language" in use. I can write equally good code in C or TCL, the testing process is what makes the difference.

Greg McKaskle makes a good point to start with the core C calls. If I was going to do your project I would pick a scripting language that can be embedded in a C program (like TCL) or Java (like Lua). I'd build the core infrastructure (API calls) that runs the motors and IO ports and let them be called by the scripting language. Make a way to stop and restart the core program externally so the script can be changed.

My big points are:
* Planned code development isn't that much different from language to language.
* Ad hoc development (hacking) is fine if you don't need to depend on the results.
* Scripting is attractive to our robot worlds IF it would end the long compile / reboot cycles.
* There is no silver bullet. (The Lone Ranger is an actor with a mask)

Keep us posted on how your scripting kernel works out.