Re: COBOL is Number One


<docdwarf@xxxxxxxxx> wrote in message news:f412j3$p98$1@xxxxxxxxxxxxxxxxxxxx
In article <5ci7kcF30ujccU1@xxxxxxxxxxxxxxxxxx>,
Pete Dashwood <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

[snip]

Within 20 years there won't be programmers (as we understand the term) in
organizations anyway. End users will use natural language and graphical
front ends to do whatever they want done and code will be generated by
software. It will be encapsulated and reused automatically.

Mr Dashwood, this prediction's been around, in one form or another, for a
few decades now... I recall it being made when users began to get access
to QMF. Please pardon me if my reaction is not as... positive and
encouraging as yours.

I thought your reaction was thoughtful and balanced.

It's a good piece and not as negative as I would have expected from you.

My response is therefore not tongue-in-cheek...:-)

You've heard the prediction before. Of course you have, we all have. And
every time, it doesn't happen so we are safe to assume it won't happen this
time either...

But there are subtle factors at work here which are not a part of our
calculation or perception. The "Rate of Change" is accelerating. It may be
doing so exponentially and we may be just rounding the curve where it takes
off... The past dismissals were justified, but this one (or the next one...)
may not be. The world is now a different place than it was the last time you
heard someone predict something.

There is no comparison between what I am suggesting for 20 years hence, and
the introduction of QMF. The only similarity is that they both involve tools
and people... see my response to Michael in this thread.

What you describe may work well with reporting functions - 'tell me what I
want about whom I want' - as long as the Prod system doesn't get tied up
with too many Cartesian joins. Insofar as modifying data in Prod... I've
seen enough systems designed by 'The Professionals' which allow for
incorrect/inappropriate update that I'd be a bit... wary about allowing
each and every 'end user... us(ing) natural language' to, say, change
personnel and claim records.

It is very likely that people will interact with computers in natural
language within 20 years, even though previous attempts to do so have been
less than spectacular. (Things have changed; there is more capability on the
part of the tools and the users now, and in 20 years that trend will be much
further around the curve.)

I take your point regarding professional knowledge, however, we are seeing
computers being used more and more to "dumb down" complex situations by
bringing intelligent agents and expert systems to bear on them. There is no
reason to believe that this will diminish.

Such software could prevent the user making bad choices and very likely will
do.

Not everything is the equivalent of a cash-register or library-book
inventory system... and even *those* 'simple' mechanisms get thrown
out-of-balance by people familiar with their use. I recall posting
something about this before... ahhhhhh, there it is,
<http://groups.google.com/group/comp.lang.cobol/msg/2a6d8995317b7e78?dmode=source>

(moderately lengthy quotation follows)

--begin quoted text:

I don't see immediately how the architecture of a typical COBOL
application
would manage to accomplish this easily. For existing function, it seems
that there is a multi phase approach that is required - the extraction of
business rules that define the operation (what is needed to update a
customer), the extraction of the logic rules (who and how is this allowed)
and the creation of the presentation of the rules.

Let me sing this back to see if I'm learning the song.

1) Initiate customer update request.
A) Does the initiating user have any customer update authority?
i) No - send 'not you, buddy' notice and terminate transaction
ii) Yes - CONTINUE.

2) Prepare to and accept user input to identify customer for update.

3) Validate input
A) is input in valid format (all letters/numbers in the right places)?
i) No - send 'bad format' message and GO TO 2)
ii) Yes - see if customer exists in system
a) No - send 'not here - re-enter or use A)dd function'
and GO TO 2)
b) Yes - does user have auth to update this class of customer?
1) No - send 'lowly peon' msg and GO TO 2
2) Yes - CONTINUE

4) Prepare to and accept user input to modify identified customer.

5) Validate input
A) is input in valid format (codes entered are valid update types)?
i) No - send bad code(s) msg and GO TO 4)
ii) Yes - are codes valid for this kind of customer?
a) No - send 'not for this one, you don't' msg and GO TO 4)
b) Yes - send 'are you sure?' msg and get response
1) is response valid?
A) No - send 'Y/N, please?' msg and GO TO 5.A.ii.b
... etc.

Now... the question of 'the extraction of business rules' and 'the
extraction of logic rules' is where it gets sticky. Take the example of
an insurance-claims system. It seems logical and businesslike to allow
for a claim to be made for the treatment of uterine infections... BUT NOT
if the policy's group doesn't have a rider to cover such treatments...

... then it's OK... BUT NOT IF the claimant is a male...

... BUT IF the claimant is a male who has a female relative who is also
covered by the policy then it's OK...

... BUT NOT IF the claimant is a male who has a female relative who is
also covered who has had a hysterectomy...

... BUT IF the claimant is a male who has a female relative who is also
covered who has had a hysterectomy AND the date of the hysterectomy is
greater than the date of the uterine infection treatment (someone left the
claim in a drawer for six months) then it's OK...

... BUT NOT IF the claimant is a male who has a female relative who is
also covered who has had a hysterectomy AND the date of the hysterectomy
is greater than the date of the uterine infection treatment (someone left
the claim in a drawer for six months) AND the date of the uterine
infection treatment precedes the effective date for policy's rider which
covers such treatments...

... et and cetera. I think I'll stop now.

--end quoted text

All of this 'stuff' - the rules for the adding or updating of a single
transaction against a single account - is the result of a combination of
'complex logic' ('a policy issued to a man can cover someone who is not a
man under certain conditions') to legal fiat ('the Court just decided that
uterine infections in women 18 - 24 years old who live in (area) are the
responsibility of (trash-dumping company)') to an individual corporation's
policies and experiments... and if one expects an 'end user, using natural
language' to be aware of this then one might be disappointed.

I not only expect it, I am seeing it in certain situations, already.
Everything you have described above could be elicited and deduced, even
optimized by a smart system interacting and iterating with a knowledgeable
employee, or a couple of employees with a SME on call or networked into
their session.

Certainly this kind of thing is already happening in the field of
conveyancing where legal titles and local by-laws that once would have been
the province of specialist lawyers and required days of searching and
checking, are now retrieved and checked in seconds by smart systems. (This
has brought a dramatic drop in the price of such services, (this service
cost around $3000 in NZ 15 years ago; today it is around $500) as people can
virtually do it themselves and simply have their final documents checked by
a lawyer for peace of mind.)

At least one insurance company I know is using the same approach (smart
systems and interaction) to formulate special cases on policies for specific
insurance markets. It means they are not tied to templated policies but can
offer customers flexibility and cover for specific conditions that are not
in the 'rules' and know that the system will not allow them to write a
policy that violates corporate or legal directives, but WILL allow certain
employees to use their discretion.

There is nothing in what you have described above that couldn't be
implemented (albeit clumsily) right now, with the right company, and people.
In 20 years, it will be part of normal work.


Where does it come from, then... who relates and co-ordinates all of these
disparate factors into something that Does What The Company Wants?
(notice I say 'The Company' here, not the user... there are user requests
that are at odds with what benefits The Company... but that's another
topic for discussion, entire)

As I understand it, at present the person who takes these various
relatings and co-ordinatings and presents them in a fashion which uses The
Company's current data requirements (what data are available and what
machine resources can be used to manipulate these data) to quickly and
efficiently satisfy and end-user request is 'a programmer'.

Yes, and we still have crap systems... Not necessarily the fault of the
programmer or even the IT department as a whole. The data resource is badly
distributed, there is huge duplication, time frames don't match across
departments, the taxonomy has not been resolved (so when one guy says
"account" another guy says "client"), processes and procedures are not
properly documented, training is poor or non-existent, management is
indecisive or autocratic and non-responsive, morale is bad... an almost
endless list of reasons why things are not as good as they could be. Pretty
chaotic, really. But take one piece of information and organize it, and
order starts coming into that chaos. When information can be accessed
instantly by people authorised to access it, when it is organized and not
duplicated, flows freely throughout the company, then it is possible to
implement smarter systems. By networking people and data the 'relatings and
co-ordinatings' can be seen and used by people knowing that they are
complete, and compliant with company policy.

I wonder how
delighted or disappointed one may get should one expect the end-users to
assume these tasks... good system design will help, up to a point, so
perhaps there'll be less emphasis on programming and more on
architecture...

... but there isn't yet, to my knowledge, an architecture that will
prevent Cartesian joins or flat scans due to a lack of key access or a
provide a mused 'Hmmmmm... you know, given our data structure and the
nature of this request... maybe *this* tool would work better.'


There will be in 20 years ... some of this is just around the corner... :-)


Yes, it might be that some day the architecture will look at usage
statitistics and say 'We need an alternate key here' or 'In this case a
SORT will be more appropriate than an EasyTrieve job'

Sorry about the sentence interruption, but it is a long sentence and this is
an important point...

It won't have anything to do with a key here or a SORT there; these concepts
will be as relevant in 20 years as gas lighting... the whole organisation of
the data across the network will be handled by specialist software that will
simply ensure data is retrieved instantly in whatever order you want it, at
whatever level (summary, detail, time series, etc) you want it.. This can be
established by interaction in natural language... you state what you are
looking for and interact with the system, which shows you examples made with
live data, and suggests additional possibilities. If you are likely to want
that same request as a regular report, then the system saves the interaction
as an object and simply activates it next time you ask, or regularly if you
specified that. (Crystal Reports can do this now...)

Although keys and sorts may be the stuff that dreams are mad eof currently,
they won't be in the future. Molecular storage will enable truly effective
content addressable storage where keys would be irrelevant. Sequence is
already irrelevant; it has nothing to do with how data is stored on RDBMS
and is even less important on CAFS. Bottom line: some of our currently
accepted wisdom will change dramatically. That's why I'm excited about
Lambda functions and deferred execution; the actual storage is irrelevant.
These approaches will work just as well on 3D molecular stores as they do on
ferrite.

(By the way, there are already RDBMS modules that analyse data access
patterns and reorganise the physical structure accordingly.)

Your quote starts with the words:

"I don't see immediately how the architecture of a typical COBOL application
would manage to accomplish this easily."

Correct. It wouldn't. And that is why COBOL probably won't be part of it.
However, the careful delineation of the procedural logic which followed, is
pure COBOL territory. Reading it, it is not hard to see it was written by a
COBOL programmer. It is step-by-step, and logical. Good stuff. But the real
world isn't like that and that is why objects and components will win the
day. It is necessary to dive into that process at almost any point without
prerequisites or sequences, because events happen in the real world in
almost unpredictable ways. Encapsulated components allow "islands of sanity"
to be devised which are unaffected by the chaos outside.They don't require
pre-requisites, can be cobbled together to make sub assemblies and
sequences, then reused in a completely different way somewhere else.

or 'What Department
A is calling an 'organisation code' Department B has stored as an
'internal accounting code''...

Taxonomy is a major concern in many organisations. Software to deal with it
is becoming available.

and the likelihood of such architecture may
be more probable than, say, predictions about personal helicopters and
flying cars and one-piece cellophane jumpsuits, I do not know... after
all, some day there'll be computers small enough for you to carry around,
no?

I shouldn't think so... :-)

Time will tell...

Pete.



.

Relevant Pages

  • Re: SR might be palatable if (part 4, "Multilingual")
    ... that allows the customer to switch to whatever language they prefer. ... For IBM-MAIN subscribe / signoff / archive access instructions, ...
    (bit.listserv.ibm-main)
  • SR might be palatable if (part 4, "Multilingual")
    ... IBM is apparently taking the approach that "multilingual" means to include ... that allows the customer to switch to whatever language they prefer. ...
    (bit.listserv.ibm-main)
  • Re: Program slow. Garbage Collection
    ... I realize that this was not for any particular customer, but this happens even in commercial enterprises, believe it or not. ... And when your application has performance problems, then the common reason is a bad algorithm and not the language that you took. ... You can reduce the risks but there will always be that risk. ... And if there is a real problem, then you have to find a good algorithm to solve it (or better: Check the real problem behind and solve that! ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Design Questions about static factory classes
    ... And my guess is that Tom meant US English. ... French-language JVM, read the Java API in French, and write my system ... local => pick English or local language as you prefer ... specific customer at this time, ...
    (comp.lang.java.programmer)
  • Re: Controlling Javascript from server side
    ... but five different language implementations here. ... 'true' means that the request must be handled asynchronously. ... There is exactly *no* reason for such a thing here. ... | percent-endoded string). ...
    (comp.lang.javascript)