Re: Relevance of languages WAS: Re: Date Validation in COBOL

tlmfru wrote:
I do enjoy these historical matters!

Pete Dashwood <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:6sl610F6vlsbU1@xxxxxxxxxxxxxxxxxxxxx
Hi Peter,

Very good response from both you and Howard. So I'm taking some time
out to reply, although some of what I originally wrote was not
entirely serious...:-)


How does this relate to the questions expressed below?


Only this: that a great deal of the changes in this industry are
driven by sincere but not always well-informed enthusiasms.

Absolutely. Seen it many times. COBOL replacing Assembler was one
such... :-) Instead of developing high level languages which enabled
people who really weren't programmers to try their hand at it,
imagine if they had focused on improving the development facilities
available in Assembler, instead? Programming would have stayed with
the professionals, and the professionals would have been much more
productive.

"properly informed" people would have realised that bringing computer
programming to the masses was a very bad move and there would have
been no COBOL or PL/1. Platform transportability could have been
achieved by low-level code conversion software instead.


Tongue-in-cheek here, of course.

Well spotted, old fruit... :-)


Although there was definite
resistance to the new thing (Cobol) most of the older programmers I
encountered at the time were eager converts once they found out how
easy it was and how much more they could get done. And there was a
sizeable group that positively reveled in it from the get-go as they
simply weren't up to the intellectual requirements of Assembler.


Well, where I was workng it was an Assembler shop and the old timers WEREN'T
more productive with COBOL at all. In fact,most of them could code rings
around the COBOL guys. There was little advantage in a high level language
(from the programming perspective), that couldn't be obtained by the use of
macros in Assembler...

Much more recently, in the late 90's in fact, I came across a
proposal to turn the users loose on certain programming requirements
- each new product the company introduced required a new editing and
pricing program, and the burden was getting away from I/T. The
language was PRIME Infobasic - a fairly able and productive thing but
very labour-intensive and not at all easy to grasp for newbies in the
I/T dep't, let alone non-programming users. (One of my sayings is
"you can't get away from screwed-up thinking. The decision to go
with one program per product is an example; although a table-driven
method had been worked out at that time as well,; I never did find
out the rationale). So your scenario above isn't a pure phantasy
after all!

I should hope none of my fantasies would ever be considered "pure"... :-)



Ah, the arrogance of youth... :-) There's usually no malice in it.
To be fair, getting COBOL programmers to understand and embrace the
interrupt driven model of programming is sometimes difficult, simply
because COBOL controls everything and is not designed for responding
to events. People get used to initiating processes and controlling
them. When something screams: "Attend to me, NOW!" it is a bit of a
paradigm shift...

People without the benefit of COBOL experience pick it up very
quickly.




Now that's a bit of a canard, you know.

You mean a yellow thing in France that quacks?

Given that one online meaning is: "An unfounded or false, deliberately
misleading story.", given that I generally avoid lying (it makes life more
complex than my tired old brain can accommodate), and given that the comment
was based on actual experience gained teaching interrupt driven (PowerCOBOL)
programming to COBOL programmers in two different organisations, and to
non-COBOL programmers (VB) in one other organisation, I have to say it
neither waddles like a duck nor quacks like a duck. My experience has been
exactly as stated. (I didn't make it up...)

Positing a screen-handler
that the application programmer needn't worry about, then
event-oriented or interrupt-driven programming is straightforward in
Cobol. You fire out your initial screen and set up the flags to
indicate what you did, then wait for a response.

....or not...

So long as the
response info includes all identifying info - last key pressed, what
screen was in control, what information was entered - then the
program will always know what to do. There will be processing
particular to the screen in control, there may be successor screens
to set up. file i/o to do, termination, etc. But in no case is the
list of possible events very large: I can't imagine why an
application program would care that the window was resized or moved;
that's the screen handler's business. The program can always relate
its previous state to the current action required. Your statement
above that Cobol controls everything is misleading in this case: all
it's doing is presenting the info and waiting for the user to do
something, then responding to that something.

And, according to your own statement above "You fire out your initial screen
and
set up the flags to indicate what you did, then wait for a response"

How is that NOT controlling the process?

It's a semantic argument anyway. I stated that "COBOL controls everything
and is not designed for responding to events", but that comment was about
general use of COBOL, NOT using it in the scenario you posited.

There is no absolute
sequence of events. It's true that it's more difficult in Cobol as
opposed to VB or anything else, because many of the details that are
under the hood in VB etc. must be explixitly done in Cobol. I've
been doing that sort of thing since about 1973; once I understood why
the program was always resumed in the same paragraph (instead of
immediately following where it released control to the screen
handler) I had no conceptual trouble at all; the problems were in the
details. Using other languages, as a result, was straightforward
too, although I was bedeviled by the different ways the various
languages treated the same event.

Hmmm...You are describing ONE model of interrupt driven processing and it is
not a good one. (A good one WOULD return control to the statement
immediately following the dequeue. This is achieved by true re-entrancy
which, historically, has not been available in COBOL, because access to the
system context is not generally available in COBOL... Specifying RENTRANT in
a compiler directive does NOT mean the system can or will do the necessary
context switch with all registers and the instruction counter being saved
and restored, at any point where you want it to... like immediately before
your dequeue boundary) A true interrupt driven process would handle other
interrupts besides the one it was "waiting for" in your scenario and it
would involve true re-entrancy, rather than the serial re-usability you have
described.

But I didn't want to digress into interrupt driven processing (as
interesting as that may be...)

If you seriously disagree that in general, outside of contrived interrupt
scenarios, "COBOL controls everything and is not designed for responding to
events", then by all means make your case. But please don't call me a liar
or "misleader" if I make mine with an honest statement based on actual
experience.

Cheers,

Pete.








.

Relevant Pages

  • Relevance of languages WAS: Re: Date Validation in COBOL
    ... Very good response from both you and Howard. ... COBOL replacing Assembler was one such... ... Programming would have stayed with the professionals, ... I don't think any "high-level" language can ...
    (comp.lang.cobol)
  • Cobol and OO programming: the final chapter!
    ... The history of Cobol today is often modeled as an evolution in steps ... reflection of the OO programming influence, ... ideological fight for pimp standards has basically already been fought ... must assume it does give us the fittest ideology for the times. ...
    (comp.lang.cobol)
  • Layers, objects, and granularity
    ... working with classes and objects in COBOL and ... from the input and output and replace them with an interface. ... Presentation layer, Business layer, and Data access ... Leaving aside the debate about OO programming versus Procedural programming, ...
    (comp.lang.cobol)
  • Parallelism between computer science and experience WAS: Re: SQL wrapper in OO cobol
    ... an OO cobol extension to wrap all the embedded sql statements? ... the database - or even that it's going to a database. ... concepts of programming theory. ... formalizing programming was not the common approach on most sites, ...
    (comp.lang.cobol)
  • visiting lead Bankeys documentation
    ... Yosri returns the accused strip very politely? ... it'll behind ignore the programming. ... seal once, capture barely, then interrupt in response to the ... Yosri convict that? ...
    (sci.crypt)