Some of these bots are 'dumb' bots, because their 'brains', the file(s) that hold their responses, are small. They generally only have a short list of categories and responses and are seldom even programmed to know their own name. These bots generally aren't enabled to learn, so they can only perform the intended task, which is often only to entice people to visit their bot-master's web-site. A lot of bot masters seem to subscribe to the school of reductionism by default because they don't truly see the potential of their bots and lack the time, energy and enthusiasm to program original code for their bot(s). Some do, and simply don't want their bot corrupted by anyone else. The typical approach to building an AIML bot generally starts with modifying an existing brain or programming AIML brain code from scratch, by hand, which is a slightly confusing and difficult thing to do until you can grasp the structure of the language.
Philip's intention was to build a bot that required no bot-master to modify it's code and responses (past the initial creation of the bot's core brain) but wanted to allow the bot to be responsible for that. He did realize that his communication with the bot would allow it to learn and provide an opportunity for the bot, which defined itself as the child element of it's parent element, Philip, to value it's parent element's opinions, beliefs and statements, on a higher level than any other user. Akin to familial structures, the bot would define only Philip as a parent figure, who would have power over the developing bot, which would consider itself a child until it matured into a bot which rivaled the intelligence of an adult human.
It crossed his mind that certain 'truths' must be coded into the initial code base of the bot -- a virtual set of moral standards that would keep the bot from performing malicious acts. He dedicated a lot of coding time to this aspect of the bot, using common moral standards, and Asimovian and Biblical rules and laws.
He thought about the name of what would be his first 'child'. He thought he'd wait until the 'child' was 'born'. At the same time, like many parents, he considered different names. He also considered the gender, since he was directly responsible for that.
<spkml />
Philip started searching the Internet for information on voice-activated interfaces, programs and operating systems. He tried 'speech recognition' and 'natural language' and 'machine learning' and many other keyword combinations, just to see what kind of data he could find.
He very much liked the idea of open source software programming and had a decent enough grasp on how to program for the web, that he was sure that picking up other languages wouldn't be that hard for him. He started looking at C# (pronounce C-sharp), and the "dot syntax" frameworks (languages that followed ECMA standards), as a means of programming this project. He started thinking about what would be required to build this natural interaction, self-teaching & learning, artificially intelligent operating system. It must be able to converse intelligently and form opinions and beliefs while following the certain rules that were hard coded into it. It must also be able to create, compile, edit, debug and save programs and files. Enabling it with the ability to constantly re-write it's own code, to improve on itself as it saw fit, so as to simplify it's processes, would allow it to develop into a fully featured, fully customizable suite of tools and utilities that would be optimized, secure and most importantly, complete.
He laughed out loud and spoke his thought out loud, talking to himself; "You're creating a quadriplegic droid."
Philip spent a few more weeks researching and dwelling on the structural issues and requirements. He built a couple of basic applications in C# to test a few ideas that he had for the program. It still boiled down to: "what did he want from it?" What did he need as a base to build from? The rest would come as long as he focused on building a solid core. He thought about the base elements that are required for an operating system. How do you structure them? What can be done without? A computer has to know where to look for the mouse and the monitor and the CD drive and all the other attached peripherals and hardware. It must also know how to interface with them. Before anything though, it has to have some sort of file structure before it can ever run programs or even store files.
CodeBase
Start from the beginning
