Thread: UBotScript?
View Single Post
Re: UBotScript?
Old
  (#20)
botman
Super Moderator
 
Status: Offline
Posts: 280
Join Date: Jan 2004
Location: Plano, TX
Default Re: UBotScript? - 03-06-2004

"botman, you have voted "no", you must have good reasons, would you mind telling us your opinion ?"

Sure. Scripting languages are usually created to give non-programmers a way to create code. Scripting languages are usually fairly simple syntax and have fewer command words in the language that need to be learned by the user. Scripting languages usually prevent "dangerous" coding concepts (like pointers, memory allocation/deallocation, array indexes out of bounds, etc.) so that non-programmers creating script code don't shoot themselves in the foot.

I think the main question to ask is "Why do you want to create (or use) a scripting language (who do you expect to use it)?" If you are creating a scripting language to allow non-programmers to modify the bot code, you will find VERY few non-programmers who are able to understand the complexities of the bot's code and be able to modify it to create new behaviour without breaking the existing behaviour.

If the only people you expect to be modifying the bot code are programmers (i.e. understand C/C++ well), then the language should be something that allows them to create behaviour in the most efficient way possible and scripting languages are NOT efficient. They are slow, they are limited and they are difficult to debug.

As for the argument that a scripting language would make the bot platform independent, I'd say that's not true. Compiled script code (byte-code or p-code or whatever you want to call it), still must be interpreted by native code on that operating system. The script code itself may be platform independent, but the native code that understands the compiled script code is not platform independent.

I think all the United Bot discussions so far are starting out WAY to complicated and grandiose. You're trying to make it everything to everybody, instead of focusing on making it as minimal as possible and getting it running first. Once you have a minimal system working properly, then worry about adding on all the bells and whistles and kitchen sinks. Start with a simple small design and implement it (in working code, not on paper) to prove that it works. Then modify that design and implement whatever new feature you want to support.

If you start out today trying to design it so complex that nobody can agree on what it should be, you'll never get anything done.

botman

Last edited by botman; 03-06-2004 at 17:00..
  
Reply With Quote