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

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

    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

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

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