Re: it's not just the box dummy - it's just a house of cards. -- MIDRANGE-L

Scott has raised a very serious issue, and he invited responses, so here
goes! 

In advance, I must warn you that this will be on the long side.  But we
cannot solve a really serious problem in just a few lines (nor necessarily
with a large number!).  

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. 
This model, evolved by John von Neumann, was a brilliant solution for the
problems of the Manhattan project.  But he wanted to do complex
calculations on relatively small data sets. He was not trying to store and
retrieve vast quantities of data, nor to do MRP, word processing or run a
business.  50 years later we should have moved on.  

The solution?

Put the rules back where they belong, with the data that they define, and
store them all together in a universal data type in one database so that
they are an integrated whole.  Every piece of data is connected, however
indirectly, in a contextual database to every other bit of data and to
every rule.  The database defines its own structure and so this can be
changed in real time whilst it is in use.  This is called Connectionism, an
idea that evolved shortly after the von Neumann model.  It is very simple,
requires no advanced mathematics, and it allows us to cope with complexity
by only considering a small part at a time.  The database provides the
integration.  I am not talking about Artificial Neural Networks but about
what I have called a Neural Database.  Different connections over the same
data will change the way in which we perceive the data and so change the
way in which it �behaves�.

How do you construct a database defined by itself since you cannot build it
until you have built it?  
In the same way that the earliest compilers were written in machine
language but in due course they became capable of creating better compilers
- a process of evolution. 

Is it just a theory or does it work?

It really does work.

Can it solve all the problems of the world?

As a concept, it might.  But in practice it will depend on the
implementation of the concept. Although, as yet, the answer is no, it is
certainly a quantum leap forward.  

So, what can it do?

It can handle most aspects of commercial computing - the problems we try
and solve on AS/400�s.  No up front detailed spec. is required, most of the
time no new programs need to be coded or generated (therefore no flakey
code), no normalisation or physical database design is required, it
provides excellent security,  stunning productivity for development and
very rapid response times. You can navigate the connections in either
direction at the same speed.  It is scalable (like the brain). It can
provide 1 billion� ways of indexing any record without using AS/400 logical
files and without RDBMS �joins�.  It provides control of an integrated
database without redundant data.  Above all it is very simple - if it were
not, it would not work.  I believe in the KISS principle.   It only
requires a small amount of code for the kernel (about 4.5mb) and this is
used, together with the database, for both the development and operational
environments.  The database itself is the development tool - no separately
developed tool, external to the database, is required.  The users of the
resulting applications will not realise that these are fundamentally
different different underneath.  They will get better, integrated
applications, sooner and cheaper.

What is the Catch?

None as far as the systems are concerned.  Because of the simplicity, there
is no obvious downside.  But we have to be brave enough to decide to change
our ways and no one likes to be the first to stick their toe in the water! 
However, because the concept is very simple, the learning curve is short
and therefore we can try it with minimal risk.  Anyway, carrying on as
before carries a much bigger risk.  

What if I feel more secure with my present methods?

Businesses are getting more and more market driven and markest are changing
at ever increasing speeds.  If we stick with our existing methods, our
companies will not be able to react and we will all be out of a job.  We
may be far too busy fighting our day-to-day battles with our bows and
arrows to look at the new machine gun, but if we don�t, we will lose the
war.  If we lose it, and we are holding a dead straight course to ensure
this at present, it could bring down the whole fabric of our society.  I am
deadly serious. 

We will have only ourselves to blame and only we can solve the problem.  No
one person can solve it on his or her own. We must work together to achieve
this.  Let us prove to the doubters how good the AS/400 is by making sure
that it is the AS/400 world that leads the way!



If you would like to read a paper on connectionism (not a product
description), please ask.  If you want my view of the problems with
existing methods, please read on.



I have to own up to my age and start by saying that I joined IBM in the UK
in 1965 and sold /360 mainframes in the banking and finance area of the
City of London.  This had been my background before I joined IBM.  So I
have been involved in computing from before the birth of many of the people
using this list.  I remember when a 40Mb disk drive was about 8 ft x 6 ft
by 2 ft 6 in (yes Mb not GB) and cost US $200,000.  If you had two or three
of these, you could run the world!

If, in 1965, somebody had predicted the extraordinary change in
price/performance that would occur over the next 33 years, then I am sure
that, if we had believed them, we would have assumed that the computer
industry would have been way ahead of where it actually is today in its
ability to deliver quality, stable solutions to its customers that could be
easily changed to keep up with their ever evolving real world.  I say this
even though there are many very clever things done by today�s computers
that we did not dream of then. 

In the 60�s, we were happily talking about every manager of every company
soon (!) having a terminal on his desk with access to a corporate database.
 We assumed that this would be an integrated database and that the company
would have real control of this.  How many companies can really claim today
that they do have CONTROL of an INTEGRATED CORPORATE DATABASE?  If their
data is spread across many systems, probably with differing OS�s and with
thousands of files on PC�s etc., they can make no such claim.  Even if it
is all on just one box, I doubt that they really have control. Even a one
man business with just one PC has no idea what half the stuff on his PC is
or how it got there, even if he is not connected to the Internet.

I have been involved in development for some long time, both in IBM and
later outside, so I am not just an old salesman without experience of the
subject. In my view, as long as we just tinker with existing development
methods, things will not improve. Despite all the apparent changes that
have occurred, underneath all the gobbledegook (pompous unintelligible
jargon) and hype, nothing of substance has really changed.  But what about
RDBMS�s, O-O, GUI�s, etc., I can hear some saying? Has�nt he noticed? Poor
old fool!

Well I have noticed, and the only thing that has been achieved by all these
things is greater complexity and so greater frailty  At the same time as
companies become totally dependent on their computer systems for their very
survival, these become more and more fragile.  This is a potentially
disastrous situation for which we, the experts, and our beloved AS/400�s
will get blamed (as in the article to which Scott referred). Of course, I
am not referring to the systems in the companies of you guys, just the
companies down the road. 

We will only make real progress by simplifying the whole process.  To do
this, we have to stand back and look at it as a whole.  It has two very
basic flaws that make each resulting system a house of cards.

The first is writing the specification, a flawed process and the foundation
on which the house of cards is constructed.  The second is programming,
surely the most inefficient process ever evolved by man in any field of
human endeavour.  Fine for masochists, and I may be one, but productive it
is not!

But, you may be thinking, these are the fundamentals of system creation. 
You cannot change those.  Well, I have explained at the beginning how this
can be done, but I will explain why I think that writing a spec. is beyond
us mere mortals.  The problem is that even if any one person does
understand, in minute detail, every aspect of the task for which the system
is to be built, he cannot conceive of them as an integrated whole at an
instant of time, and that is what the spec. is supposed to represent.  In
practice, the problem is rather more basic than that as users and experts
have communication problems that cannot easily be overcome.  A user will
happily sign off a spec. that, although it meets his problem description,
is flawed because he does not have time to really track every detail
throughout it, he may not understand it and he will make assumptions that
it includes things that are so basic to him yet are not there.  The CEO of
a brewery might not bother to mention that his company brews beer because,
as it is so obvious to him, he will assume that we all know this.  I won�t
bother to cover the problems of keeping the spec up to date, or of
integrating the new system with those that already exist, etc..

I have already given my main view on programming but here are two extra
points.  I do not believe that, when humans learn new skills, someone on
high does physical database design and decides where in our brain the extra
information is to be stored and how to handle new data types and then
reprograms our brain to cope.  So why do we do this on a computer?  There
is a very simple way of ensuring that we do not write any bad code - don�t
write any!  I mean also - don�t generate any!

As long as detailed up front knowledge of our task (i.e. the spec) and
programming are the fundamentals of our development tool kit, the situation
will only deteriorate further.  Another part of that kit is the RDBMS which
has severe functional limitations and which cannot model the complexity of
the real world.  By the way, are your brains normalised, particularly after
a few beers?

Human beings cope with the complexity of their real world by ignoring it. 
They consider only small parts at a time - when you are busy coding, you
are not worrying about how to drive a car, even if you are dreaming of the
Ferrari that you would like (so that�s why some of my code is less than
perfect!).  The brain provides the integration of the whole.  We do not
know how this works exactly, although we are learning.  We have no picture
of the structure of our brains, and we don�t miss it - we get by, more or
less, very happily.  Yet we do try to draw pictures of our information
systems, even though, in two dimensions, you can represent only a tiny part
of the very large, complex, multi-dimensional whole.

We can build much better systems, much more quickly, but not with our
present methods.  Does that mean we will all be out of a job?  Only if you
believe that mankind has nearly reached the limits of sophistication.  I
believe, that in technology, the people of 200 years� time will consider
that, in 1998, we were still in the stone age.  If we could deliver
economic robust systems that could keep up to date, the wants lists from
our users would grow dramatically.  Our application backlogs would be
longer, not shorter.  The problems that we would have to solve would be
more challenging, and we would be more concerned with the bigger picture
and less with minutiae.  

Rob Dixon
Erros plc

----------
> From: Scott Cornell <CORNELLS@mercyhealth.com>
> To: MIDRANGE-L@midrange.com
> Subject: Computerworld article - it's not just the box dummy!
> Date: 15 July 1998 16:24
> 
> Having read the very positive front page article on the AS/400 in this
> week's Computerworld, I like many others on this list was feeling
> pretty pleased.  However, if you dig a little deeper, in the
> Corporate Stratagies section (p35 in the hard copy), there's an
> article about a construction firm replacing their legacy computer
> system with a whiz bang NT/Oracle/packaged business management
> software solution.  The old system was described as "storing
> information in unconnected files rather than a database," "taking too
> much spit and gum to paste together results," and having "sci-fi-like
> character commands."  The old system was run on, you guessed it, an
> AS/400.
> 
> Now, you, me, & everybody else on the list knows that the problems
> mentioned probably had more to do with the software package
> (described as 10-15 years old, possibly making it a RPGII port from a
> s36, thus pre-relational DB technology??)  But, probably nobody
> outside our cozy little world knows or cares about that.  All this
> construction company VIPs knew is it took too long to get answers out
> of it's AS/400.  
> 
> I wonder how much of the image problem our favorite box suffers
> from stems from a relative lack of quality software solutions (and I
> mean real quality, not just the lack of a GUI)?  I know there's
> gazillions of apps available for the 400, but how much is garbage
> code holding the box back?  God knows I've seen enough junk RPG
> programs (from big name vendors even) to last me a life time - and
> I've still got quite a bit of life time to live yet (assuming any of us
> survive the Y2K disaster :))
> 
> Just a thought - what's the list's perception?
> 
> Scott Cornell
> Mercy Information Systems
> +---
> | 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
+---