From: Michael Roy Ames (michaelroyames@yahoo.com)
Date: Sat Jan 25 2003 - 20:26:32 MST
Cliff,
You wrote: "The only way I see of really reducing the overall complexity
of the programming task is if the system has some domain knowledge, some
knowledge of business rules, and the like."
That works... and it is difficult too.
There are tools that provide you with a 'blinkered window' into part of
the code/functionality. That way, you only need to understand the part
that you are working on directly. The rest can be ignored most of the
time (if it is properly modularized). The various UML tools are a step
in the right direction, allowing a 'blinkered window' to enough
contextual information so that a maintenance programmer (one who didn't
originally write the code and so doesn't have it all 'in vis head') can
grasp the workings of part of a system by accessing the highly organized
information about the *sub-problem* being solved, and exactly how the
program solves it. The trouble with this approach right now is, that
the tools take an enormous amount of getting comfortable with before
they become useful... the ramp-up investment is steep. Therefore it is
only worth the learning investment for really large projects.
You are also *spot on* with the 'levels of abstraction' comment IMO.
Especially when applied to the code itself. The main reason so called
'Enterprise Application Integration' software has been a hot topic these
last couple of years is because it provides a level of abstraction that
allows communication between disparate systems - and does so in a
somewhat flexible manner. What ends up happening is: even though a
large company's systems are all intimately connected, a programmer
working on one system doesn't need to know all about the other systems -
only the *interface* definition of the other systems. This cuts down
what you need to know, sometimes by an order of magnitude!
I think this is what Lanier was getting at in his comments: creating
interfaces that are:
a) self configuring and
b) self recognising
So that programs could be assembled like building blocks with generic
interfaces, rather than as gestalt crystals.
Michael Roy Ames
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:41 MDT