Semantic analysis of one response (was Re: Autocoding project proposal.)

[Peter Hansen]

Let's try a little semantic analysis in the hopes it can shed some light
on what is being discussed here, if anything.  I'm making allowances for
the incredibly bad grammar but I'm trying to capture the intended meaning,
then to reduce it to its essence.  I did this not to deride the writer, but
in an honest attempt to figure out what the hell this is all about.

Timothy Rue wrote:
> Because of the nature of the project, it's not something that will evolve
> off the target that is identified. Any changes will only be to better
> integrate the commands in order to handle any exceptions that are found to
> not work.

Translation: The project is well-defined.

> Understand, it's not an idea, it's not patentable. It's an identification
> of the nine these we do in anything we do, and then defined in terms of
> computer functionality to the best possible versatility to be had on a
> given system. There are some inherent constraint within the hardware of
> computers that cannot be avoided.

Translation: It's software.

> It is a core configuration of functionality to be accessable to the
> typical computer end user. And done so in a manner that allows those who
> use it to automate things already existing, in a dynamic manner.

Translation: It has a user interface.

> The general descripting of the nine actions is not going to change. and
> the logic of how the functionality is configured and carried out to it's
> logical conclusion is what it is.

Translation: [semantically null?]

> I suppose this is what makes it so different and in turn, hard to
> understand by the typical programmer mindset.

Translation: Programmers have difficulty understanding unusual things.

> There is the problem of communicating it to others. But it's an unusual
> problem. Non-programmers can grasp the nine actions far easier then the
> programmer mind set, yet the programmer mindset tends to preceive it in
> terms of the programming languages that most currently is on their minds.

Translation: [same as previous]

> There seems to be some problems along the lines of deprogramming. As old
> style auto manufacture employees were harder and more expensive to retrain
> than train totally new workers.

Translation: [null]

> Another example that is relative to computer is the conversion of using
> Roman Numerals to the hindu-arabic decimal system. Of which the hardest
> part to grasp was the symbol '0' meaning nothing but having a value. It
> seemed so contridictary and silly to have such a symbol by those who were
> long skilled in using the roman numerals. I think it took something like
> 300 years or so before the general population was using the decimal
> system, mostly it was business that caused the decimal system to be
> adopted due to the need to be able to better deal with inventories and
> other numerical informaation in business like counting money.
> But without the symbol of nothing as a place holder, we wouldn't have
> computers, seriously.

Translation: [example, non-essential to discussion]  

> And just as roman numerals greatly limited the advancement of mathmatics,
> so does the current methodologies of programming limit the advancement of
> software engineering.

Translation: Programmers don't adjust to new methodologies.

> The fundamently logic is simple: Programming is the act of automating
> complexity that is made up of simpler things. The software industry has
> been able to automate most any other field, from mathmatics in science and
> space exploration to robotics for manufacturing, even the field of human
> balance and movement (segway). But for some odd reason it can't seem to
> automate itself even in the most fundamental basic ways of being available
> in a general manner.

Translation: Software doesn't generally automate software.

> One of the things needed in a computer environment is the three primary
> user interfaces of the command line, the graphical user interface and the
> side door port to applications and other functionality. The port that
> allows the user to communicate to the application or functionality in the
> scriptable vocabulary of the given functionality/application.

Translation: Software needs two users interfaces and one software interface.

> where the VIC comes in is in handeling the dictionaries of the various
> applications/functionality and acting as a central control point that can
> spawn off instances of itself in order to handel greater levels of
> complexity in a parrallel manner.

Translation: VIC controls data flow between applications.

> Here is an example of using the VIC in voice/speech controlled...
> http://groups.google.com/groups?selm=13506.301T771T10734137%40mindspring.com
> perhaps this is the sort of example people are looking for.

Translation: Link to example involving speech [?]

> Still there seems to be a general problem in communicating the VIC
> to others.

Hmmm... I wonder why?

Let's see what the meaningful comments look like grouped together
(with those that actually say anything in the context marked with a *)

Translation: The project is well-defined.
Translation: It's software. *
Translation: It has a user interface.
Translation: Programmers have difficulty understanding unusual things. *
Translation: Programmers don't adjust to new methodologies.
Translation: Software doesn't generally automate software. *
Translation: Software needs two users interfaces and one software interface.
Translation: VIC controls data flow between applications. *

The net effect of your above comments seems to be this:

 "VIC is unique software which manages interfaces between applications. 
  But pretty much all of you are incapable of understanding it."

My response is therefore:

 "Thanks for the insult, and I'm not interested, but couldn't 
  you have said it more concisely?"

-Peter