RE: it's not just the box dummy - it's just a house of cards.

Attempt to emulate how human brain works is quite exciting. The only
problem is - do you REALLY want computer to behave like human.
Humans are subjected to mistakes, misjudgement etc. Similarly natural
language is subjected to misinterpretation.
It's a long story, so I would not go deeper.
The only question I would like to ask - do you want your intelligent
computer to wipe out your savings account just because it "thinks" it's
worth doing.

Let alone the issue of maintenance of "integrated data and rules"
database! Since it will evolve with time, very soon nobody will be able
to understand what's in it. We regularly complain about difficulties of
fixing large undocumented programs. These will be dwarfed by a task of
finding a flaw in a terabyte data-and-rules database.
And what about recovery if smth goes wrong?

I've seen a lot of ideas in my life which were beautiful while in a lab,
but turned horrible when applied to smth more practical.
This made me somewhat cautious.


    Best regards,

          Alexei Pytel



> -----Original Message-----
> From: James W. Kilgore [SMTP:qappdsn@ibm.net]
> Sent: Thursday, July 16, 1998 8:03 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: it's not just the box dummy - it's just a house of
> cards.
> 
> 
> 
> Rob Dixon wrote:
> 
> > <<snip>>
> >
> > These are my personal views.
> >
> > The real problem?
> >
> > At present, we separate rules from data and encapsulate them in
> programs
> > (and so set them in concrete) and we put the data in a database.  I
> call
> > this artificial split Separatism. This, in my view, is not the way
> the
> > brain works, and it is the fundamental problem behind all our
> efforts.
> 
> <<really big snip>>
> 
> Rob,
> 
> Back in the early 70's I was a cofounder in a company based in NYC and
> we were
> developing a systems design tool/code generator.
> 
> Just for the heck of it, another partner and I took a night course in
> AI at
> Columbia and walked away from that with the idea that as long as we do
> not know
> how the human brain works we can never artifically emulate the
> process.  Hence
> rule based "expert" systems, on VERY fast computers, is as good as it
> gets.
> 
> Well, a long time later the S/38 was announced and by then I'd moved
> to Seattle
> and started my own company.  But I revisited the "rules" we had been
> developing
> software under.  Since my company was a S/34 provider we sure as heck
> didn't want
> to port that code to the S/38!  But, we had to stay in business and
> kept on
> rolling, but my "hobby" project was to separate the application from
> the language
> from the OS from the machine.  IBM already had done a lot of that with
> CPF/MI
> layer.
> 
> Well, I don't want to get too winded here, but the concept was to
> allow a
> company's "Policy and Procedures" manual to be entered into a system
> which would
> drive the computer application.  Just as the current design methods
> are too
> combersome, as you mentioned, we tried to break apart every entity of
> information
> and assign rules to it.  Entities would be assembled into forms and
> forms would
> be shuffled through the corporate mill based upon your job description
> and the
> forms requirements/routing.
> 
> The human mind does not work like a computer and applications do not
> work like
> the flow of information through a company.  We wanted to create
> something on a
> higher plane than even the 4GL we have today.  IMHO, they are not much
> more than
> integrity checking code generators.
> 
> When I would discuss the idea with peers 15 years ago I would receive
> that "Earth
> to James" look but I still believe it's viable.
> The foundation for the concept was after reading "Principles of
> Systems" by Jay
> W. Forrester (more than once till I finally "got" it).
> 
> In the big picture, the purpose is to emulate information flow.  The
> "manual"
> could be updated real-time and the application driver would react
> accordingly.
> Unfortuantely, up until variable length fields and date/time data
> types were
> intoduced, the DBMS was and to a lesser degress still is the big
> stumbling
> block.  The other was speed.  But that is becomming a moot point.
> 
> The other big stumbling block is getting a company to actually define
> their
> policies and procedures! ;-)
> I'm still trying to incorporate the "it depends" answer I keep
> getting.
> 
> Just a minor digression: If I recall, it was also in the early 80's
> that "natural
> language" query front ends were developed.  The flaw: People just
> don't know
> English well enough to ask a question properly.  The example given was
> that a
> user would type: "Give me a list of all of the registers voters in New
> Hamphire
> and Vermont."  The computer came back with nothing.  Why? You can't be
> registered
> in New Hamphire AND Vermont.  Interpreting intent vs strict language
> construct is
> a biggie!
> 
> But anyway, since you seem to be hot-n-heavy into viewing design under
> a new
> light, maybe you can point me in the direction of others that would
> like to kick
> around the choices.  Maybe we can even start a thread that can compete
> with the
> number of posts involving the "good ol' days" or CA/400 bashing. <bg>
> 
> 
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---