Re: Application design & architecture

Rob,

The alley is a major highway. Your blindness does not make it an alley.

We need a new group called Midrange-20th-century.

Trevor

Subject: Re: Application design & architecture

We got hijacked and taken down a blind alley.

Let's try and get back on track.

I asked - it seems eons ago -

"Can we design an architecture that will make us more efficient?"

I don't think that many people will regard present methods as efficient
- just the best that they know.

There are many reasons for this, but I would like to concentrate here on
just one of these - programming.

Whatever the language or the architecture, programming is a most
inefficient process, as I said  earlier, "the most inefficient process
ever devised by mankind in any field of human endeavour".

In order to explain how we might create a better moustrap, a little
computing history is relevant.  I have tried to keep this as short as
possible.

The first computers were conceived and constructed to do high speed
calculations - they were built solely for computation. John von Neumann
and his colleagues, working in 1944 on the Manhattan project to build
the first atomic bomb, wanted a much quicker way of solving complex
mathematical equations.  Storing, manipulating and constantly updating
vast quantities of data was not the problem that von Neumann was trying
to solve.

Von Neumann, who first conceived the required logical structure of the
computer, realised that his mathematical problems could be closely
defined but needed to be run repeatedly on many sets of data. He further
conceived the concept of the stored program as a convenient way of
defining each separate problem to the computer and allowing his
colleagues to switch quickly between the different problems they were
trying to solve. It is unlikely that von Neumann considered that his
"model" would be used for all computing work for the next 60 years
without any real change.

The separation of the rules from the data may be appropriate for
mathematical and scientific problems but has added dramatically to the
complexity of creating and maintaining business computer systems.  At
the same time, we may have ensured that we can never create a machine
with an ability that might be called "intelligent", whether or not that
is similar to the intelligence of the brain. We may call the present
artificial split of rules and data in computer systems "*Separatism*".

It is clear that human intelligence is very dependent on our ability to
store, dynamically update, and navigate large numbers of connections
between the items of data in our brain.  This ability, which may be
considered to be non-computational, can conveniently be described as
"*Connectionism*".

If we are to move forward, the rules and processes must be defined, not
in the separatist manner using programs and files, but in association
with the data to which they apply, using connections.  This means that,
like the brain, our computer database must be able to determine where
and how information is stored without outside help (from program
changes). In other words, it must be capable of defining its own
structure and allow continual changing of the connections as it acquires
new data.  All of this is way beyond the capability of RDMBSs but not so
difficult to implement if we create a universal data structure.

Applying the principle of connectionism to the building of computer
systems can allow us to build systems with a speed and ease that is
beyond the wildest dreams of those using separatism as their model.
Connectionist systems can be changed dynamically whilst they are in use
and so continually be kept up to date with the world of their users.
Since connectionist systems are defined using the language and
terminology of their users, the process is one to which users are
already accustomed. Typing their business descriptions, definitions and
rules into a connectionist system will be dramatically simpler to learn
than the present separatist processes of system design and programming.
As with the information stored in their brain, users will not need to
understand the complexity of the structure of their world, since they
can study and define it incrementally in small pieces and use the
connections to move from one part of the definitions to another. Months
of detailed planning and specifying become a thing of the past.

Separatist methods produce static rigid solutions whilst the
unstructured real-world problems of their users change dynamically.
Static solutions are totally inappropriate for any business that is
trying to get ahead or even to stay put. The effect of separatism is
"*isolationism*". As John Donne (1571? - 1631) wrote in his ~Devotions~,
"No man is an island, entire of it self".

I wrote the above many years ago in isolation (!!) in order to try and
explain the connectionist system that I had built and then found that
the concept of connectionism had been invented by Dr. Vannevar Bush in
1945. It may all seem very removed from the present day world of
computing but it is an extremely simple concept.  It can be implemented
in about 6Mb of RPG code (any flavour will do) and the same code is used
for both development and also for operation.  One of the additional
benefits of connectionism is that it ticks many important boxes - e.g.
security, performance, scaleability, documentation, standards, object
oriented, automatic re-use of definitions and code, contextual help,
multi-lingual, etc. - and it allows sharing of definitions on different
systems so that developers don't need to spend their time reinventing
the wheel.  Rather than having open source programs, we can have an open
business model to which multiple users can contribute and which they can
use.

Connectionism actually achieves much of what SOA attempts to do,
because, unlike SOA, connectionism is a technology that can be
implemented. If we.are to progress, we must stop using von Neumann's
model for a purpose for which it was not invented - running a business.

Of course, my implementation of connectionism has not solved all the
problems of the world.  I have done it as a one man band, in isolation
and I trained at IBM as a salesman, not as a techie.  Anyone else might
be able to do a better implementation of the concept of connectionism.

Rob Dixon
www.erros.co.uk