The VIC is NOT a Scripting or Programming Language! It contains no vocabulary but vocabularies may be built and/or used thru it.
The VIC is a small shell and command set that allows one to combine and control the vocabulary usage of programs, devices, function libraries, etc. that have the interface for automated control. It may be seen as a common point of direction control in the operation objective(s) given to the computer system(s).
* From a developer standpoint: It allows freedom to produce such work that may be accessed thru the vocabularity the developer creates and makes available. The developer has the freedom to make the vocabularity as simple or as complex, or combination of, as they may decide. But the advantages is in any VICabularies that may be included and/or made available separate from the developers work.
Note: VICabularities may include such documentation, examples, usage in action and/or other info/data/action, but in a form accessable to the customer in the easy to access and use form of what may be considered a dictionary(s).
* From an end user standpoint: The user may easily integrate various developers products thru a universal control mechanism into a personally and/or professionally customized system of streamed-lined user directed operation.
* From between the developer and end user standpoint: It allows one to create new, interesting and productive VICabularies on a level above any single or mulitple products developers create. This may include adding in natural language processing, translation, automated programming or such other VICabularies that help streamline user directed objectives.
Basic stuff of the VIC Nine commands: AI (Activate Interface) You gotta be able to start or begin stuff and stop or end stuff. PK (Place Keeper) You gotta know where you are in doing stuff, keep track of stuff, especially if you need to set stuff aside to do other stuff before you can go back to stuff and continue. OI (Obtain Input) You gotta be able to get stuff to pass to other stuff (variables). IP (InPut from) You gotta know where your getting stuff from and what stuff to get when you get stuff. OP (OutPut to) You gotta know where your sending stuff to and what stuff to send when you send stuff. SF (doing StufF) You gotta do stuff a step at a time, even when your doing more than one stuff at a time, each stuff is a step at a time. And the stuff you do can be or include doing the nine commands stuff. IQ (Index Queue) You gotta look up stuff, unless you know all the stuff but you still have to access (look up) the stuff and use the stuff by (SF) "doing StufF". ID (IDentify stuff) Sometimes you gotta know what stuff is before you know what to do with the stuff. So you look up or test the stuff and once you know what the stuff is, you can use the stuff by (SF) "doing StufF" KE (Knowledge Enable) When looking up stuff (IQ and ID) to do, you may only want a certain part of the stuff. This "KE" helps you narrow down what stuff you want IQ or ID to look up. There is more stuff to the VIC commands and operation but done so that there is ultimate versatility and inherent organization in doing stuff. But the above is the basic stuff. More details can be found on my web pages. The data/process/vicabulary format of the stuff done in and thru the VIC is text based (but not limited to) and in a format that is easy to follow and understand. For the most part (but not limited to) in the general form of a dictionary or any reference manual, code function chunk, etc. There are other formats (all text based) used by the commands but this is what would be used most. Comparing csh to the VIC: ========================= To start, consider how you can start up csh in different ways. Consider the start up options in csh. This is along the line of the VIC first command AI (for starting up a VIC). Keep in mind using csh as an example to describe the VIC has it limitations. The VIC has a versatility beyond csh and csh has many more commands than the VIC. This posting is just a place for us to start. If you are familure with shells I'm going to assume you understand redirection and tee. Well in the VIC, IP and OP are set to where you want to receive and send data. OI is along the lines of the csh "input" command and IP is where OI will get input from (IP is only used by OI). To get an idea of SF, start up csh with it's debugging on and watch as it processes your input or a script. But in the VIC you have the ability to control this processing in more ways and in a more direct way you can change where it is in any file(s) it is processing. SF output is to the OP setting. Now if you understand the csh "man" command, how it works, you have a very basic idea as to how the VIC IQ command works. The comparision here is that the "man" command is a search and output, but it outputs more than a search, it outputs a definition (read the csh docs to see how you can add your own definitions). Like I said, this is a very basic understanding of the VIC IQ command. In the VIC the IQ search can go into sub definitions and other files. Additionally the output of IQ can be processed by/thru SF and output directed by OP. ID in the VIC, doesn't have anything easy to compare with in csh, but the "class" and "action" can be used in a limited way to get the idea. ID can do more than check if it's arguement is a file of a given type. Checking for it's arguement being a file can be one of the things it checks for but in determining what all it's arguement is, it can cause action to be taken. Again this is a very basic start of what ID is. KE has no comparision in csh, but it allows one to apply additional constraints on IQ and ID searches. PK also has no comparision in csh, but you might see it as the command that changes the contents the PK file as well as the PK file used. The PK file contains all relative information to the current state of a VIC, includes the names of all files the other commands make use of. -- The Virtual Interaction Configuration will: 1) Allow automated programming to evolve, regardless of language used in code. Give developers plenty to do profitable. 2) Allow the end user more control in optimizing their use of computers. and done in a way that the end user can learn from doing a little at a time. And be very intuitive to use. 3) Allow the evolution of such systems that have a by product illusion of having artificial intelligence, Easily beating the Turing Test and any other current test or challenge. 4) Require open team work to generate an increasing value and benefit. 5) Solve the software crisis that was identified in the 1960s and has been growing since. It requires open team work (4). 6) Must be freeware w/source. Think about why. Credit must be given where credit is due for this to work as a show of teamwork. ------ The creation/evolution/process of doing stuff (six steps): ========================================================== Computers are a tool of thought. It takes thought to build the hardware, thought to write the software and thought to make use of all of this. Thought is a quality we as the human race share. And computers are a tool for the human race created by the human race. Computers can do anything within their inherent logic and physical constraints that they are first told how to do. Humans can be and often are illogical and also contridictary to physical realty in their thoughts. Who is it that is telling computers and people what computers can and cannot do? Whether you set out to produce something,a part of something,a tool to help you do something or a phase of doing something, these steps apply. Nothing created need be difficult to create if broken down into, simple to do, parts. STEP 1) Imagination/conception of general picture, objective, goal. Use step 2 to fill in general details STEP 2) Breakdown into individual parts. Use step 1 if needed to define the general picture, objective, goal of a part. Use step 3 to determine if any individual parts can be further broken down. STEP 3) Fill in the details of parts. Keep the general picture, objective, goal in mind of step 1 and use step 2 if needed. Also, refer to step 4 to determine if you might change some detail(s) of any part to make step 4 easier to do. STEP 4) Integrate parts to construct larger parts and eventually the whole to achieve the picture, objective, goal of step 1. Use step 3 and 2 to help in the integration or correction of parts. STEP 5) Feedback. Test the product of your construction. Does it accomplish the picture, objective, goal of step 1? If not, determine which previous step to return to for corrections, by going to each previous step in turn. See if there is something you can change that will allow you to reach the target of step 1. If needed, return to step 1, using what you have learned and start over to redefine the general picture, objective, goal. If the test does accomplish the picture, objective, goal of step 1 then go to step 6. STEP 6) Move the product of your efforts into application use. Use previous steps to correct/change and/or refine or fine-tune the product of your efforts for integration into the selected use environment, if needed. Given this creation/evolution/process and the sfuff of the VIC, it doesn't matter how simple of complex the stuff anyone does is. It always comes down to always doing simple to do things somewhere within what you do. ============================= The Hacker Ethic: ------------------- Access to computers - and anything which might teach you something about the way the world works - should be unlimited and total. Always yield to the Hands-On Imperative. All information should be free. Mistrust Authority - Promote Decentralization. Hackers should be judged by their hacking, not bogus criteria, such as degrees, age, race, or position. You can create art and beauty on a computer. Computers can change your life for the better. ------------------- Before going off with a possible wrong perspective of the above, one needs to take a look at the original hackers. The list is very impressive and can be found in the book "HACKERS" by Steven Levy. Sub-titled "Heros of the computer revolution". ------------------- The Virtual Interaction Configuration is to be freeware w/source code. The VIC is to be developed out in the open. Credit is to be given where credit is due. ------------------- The Virtual Interaction Configuration is not an invention, but an identification of that which must exist in doing anything. And then converted into terms of shell application functionality. With an ease of use being quite intuitive once the simple basics are recognized and understood. The VIC is for everyone, not to be constrained by developers for developers only. The only way for it to properly, safely and fairly evolve is out in the open. Otherwise end-users will not be allowed to properly understand it well enough to make optium use of it. And likewise, developers will not be able to evolve the data base "vicabularies" no where near as quickly and correctly in the constraints of exclusion of others. The work force or man power of the end users is far greater than any developer or group of developers can ever hope for within the constraints of the developer community. This can be seen in the evolution of the Linux system where even non-developers contribute where they can and often in areas developers are weak, don't have the time or just out of ideas, such as documentation, field specific research, creativity. User input and control are obiviously required of this tool called a computer, for it to be a tool end users can use. Automated Programming: By applying genuine software engineering to create the data/process/ vicabularies it easily becomes possible to evolve an automated programming environment. The dos and don't in code writing can easily be automated as well as the automation of many other facets of code writing, leaving it up to the programmer/user to fill in the specific details or simply go with the default. And this all can happen in such a manner that inherently makes sure the programmer/user does not forget something or loses focus on the big picture objective. Even the language(s) the code is written in can be a choice of the programmer/user so long as the programmer/user has an interface(s) for directing the code generation and specifics that they understand. And such interfaces can be of any design that may be made so long as they communicate to and receive from the VIC. After all psuedo software engineering is the act of reinventing the wheel over and over again, so we all know these acts can be automated. :) But the VIC can be used many other ways as well. Ways that make things much easier for the end user to do in doing simple things. But most important it allows the end user to learn and make productive use of a little at a time.
Copyright © 1975, 1988, 1994, 1996, 1997 Timothy V. Rue