Re: Confessions of an "OO Foreigner"

From: Peter E.C. Dashwood (dashwood_at_enternet.co.nz)
Date: 12/30/03 

Date: Tue, 30 Dec 2003 21:24:39 +1300

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:Mm3Ib.25364$Pg1.10164@newsread1.news.pas.earthlink.net...
> Given the recent OO (understanding, advantages, etc) threads, I thought I
would
> start a NEW thread with my (very personal) background and interactions
with OO.
> I don't know if others want to "join in" or not - but I thought this MIGHT
help
> those reading this newsgroup in evaluating my participation (and often
lack
> thereof) in these threads.
>
> First and foremost - and the reason I used the subject that I did -
> I have NEVER produced one (much less more than one) "production
application"
> using OO (COBOL or otherwise).
>
> For those who don't "know me," in actual fact it has been WELL over a
decade
> since I created any "production" application (either procedural or OO -
either
> in COBOL or any other programming language/tool).
>
> I have an academic background in linguistics, and as such, I really,
REALLY
> understand the difference between "knowing" a ("natural") language well
enough
> to translate (to or from) and actually THINKING in that language. As long
as
> you still "translate" in your mind, then you simply do NOT know the other
> language. As far as programming languages go, I am truly mono-lingual.
The
> *only* programming language that I "think in" is COBOL - although I have
> "studied" a number of other languages (including IBM S/3xx Assembler,
PL/I, C -
> IBM 4GLs Telon, ADF, CSP).
>
> Therefore, it is my strongest possible view that *MY* opinions on OO (both
> methodology and languages) is that of a "medium well informed" foreigner.
>
> ***
>
> As far as my background with OO, it is as close to "unique" as one can
get. I
> "learned" OO as a "COBOL language designer. My first experience was within
Micro
> Focus when they were "adding" OO syntax to their products and then
(almost - but
> not quite simultaneously) with ANSI/ISO as they were adding OO syntax to
> "Standard COBOL". These means that I was "told" what functionality was
> "required" for an OO programming language and my task was to help "design"
what
> was the best way to provide the desired functionality into COBOL - in a
manner
> "consistent" with existing COBOL features. I should clarify here, that
both
> within Micro Focus *and* the ANSI/ISO groups there WERE people who
actually
> "thought" in OO (non-COBOL) while this design work was being done, so you
should
> NOT blame (if you don't like it) COBOL OO design on a lot of "OO
ignoramuses" -
> even thought *I* was one.
>
> One of the issues that I worked on (fought about - and STILL think that I
might
> have been correct about - even though I lost) was the very "INVOKE"
statement
> that Peter mentioned in another thread. Ignoring some of the (less often
used)
> variations, the BASIC structure of the currently approved INVOKE statement
in
> COBOL Is:
>
> INVOKE specific-object-reference-data-item specific-method-name
> USING various-parameter-by-CONTENT/REFERENCE/VALUE
> RETURNING returned-value-data-item
>
> The questions that I raised in both Micro Focus (hereafter MF - which in
this
> note doesn't mean "mainframe") and J4/WG4 was:
>
> - Is INVOKE really the correct verb?
> - Are you invoking the object or the method?
> - Why can't you use a data-name for the method-name (similar to data-name
in a
> CALL statement) for "most cases"?
> - Shouldn't there be (at least an optional keyword) between the
> object-reference and the method names?
>
> To explain why I asked these questions (and never really received adequate
IMHO
> replies), let me explain what MY understanding of OO says that the INVOKE
> statement is "trying" to do (in a rather VERBOSE way). I think it is
intended
> to say:
>
> Send a message to a specific instance of OBJECT1 that it should
> Perform the action METHOD1 upon itself (whatever that means to an
object of
> OBJECT type)
> (optionally) Using any PARAMETERS-N
> (optionally) Returning a value in RETURN-PARAMETER-N
>
> Alternatively worded, it means to
>
> Activate METHOD1 (whatever that means for an object of the type of
OBJECT1)
> Upon the specific instance of OBJECT1 specified
> (optionally) Using any PARAMETERS-N
> (optionally) Returning a value in RETURN-PARAMETER-N
>
> The following are the definitions of "INVOKE" from the "American Heritage"
> Dictionary (and I don't think that common British usage is much
different):
>
> "Inflected forms: in·voked, in·vok·ing, in·vokes
> 1. To call on (a higher power) for assistance, support, or inspiration:
> "Stretching out her hands she had the air of a Greek woman who invoked a
deity"
> (Ford Madox Ford). 2. To appeal to or cite in support or justification. 3.
To
> call for earnestly; solicit: invoked the help of a passing motorist. 4. To
> summon with incantations; conjure. 5. To resort to; use or apply:
"Shamelessly,
> he invokes coincidence to achieve ironic effect" (Newsweek). 6. Computer
Science
> To activate or start (a program, for example)."
>
> Notice that the LAST definition includes a computer sicene meaning that
would
> IMPLY (at least to me) that what should be "invoked" is the METHOD and not
the
> OBJECT-REFERENCE if "invoke" is the correct word at all.
>
> Therefore, I still maintain that if the syntax ends up with the
object-reference
> as first, a verb like "TRANSMIT TO" or even a "verb" of MESSAGE <to> would
be
> better (more COBOL like) than INVOKE.
>
> Well, I lost <G> that battle and we ended up with INVOKE. Once we have
INVOKE
> then the question is - do we INVOKE the method or the object-reference.
As I
> indicated above, what the "computer science" meaning of INVOKE implies (to
me)
> is that we SHOULD have INVOKED the method, giving syntax like,
>
> INVOKE method-name UPON object-reference-name USING ...
>
> Well, I lost <G> that battle and we ended up with INVOKE object-reference.
Once
> we had "object-reference" as the object (grammatical usage) of the INVOKE
verb,
> then I though we AT LEAST should have an OPTIONAL keyword explaining
"what"
> (adverbial) we wanted to do with this "second" thing, the method-name.
What I
> wanted was something like
>
> INVOKE object-reference <WITH> method-name USING ....
>
> Well, I lost <G> that battle and we ended up with two "nouns" following
the
> INVOKE verb - with two VERY different meanings and no preposition between
them.
> As far as I know, this is the ONLY time this exists in COBOL (which is
English
> like) and totally (IMHO) obscures what the INVOKE statement does!!!
>
> Finally, I questioned WHY the method-name couldn't be a data-name (rather
than a
> literal). Eventually (not in the initial design) this was "allowed" for
the
> case where a "universal object reference" is used. However, it seems to
me that
> just like a "CALL data-name" statement allows for "logic" decisions to be
made
> for what module should be called at run-time, I didn't (and still don't)
> understand WHY a program shouldn't be allowed to decide "at run-time"
which
> method (for a specific object-reference) is to be used in the INVOKE
statement.
> OBVIOUSLY, this would require "late binding" - but COBOL already *allows*
this
> (or so I understand), so I didn't and don't understand why this wasn't
allowed -
> but I lost that battle too.
>
> So, ...
> All of you who "think in OO" - does the above show that I "understood"
OO and
> what "INVOKE" should do - or am I still a foreigner trying to "translate"
your
> needs into my language????
>

You are flogging a dead horse, Bill.

I accept your arguments, and agree that no harm would have been done if you
had "won" the above. You have demonstrated an understanding of the MECHANICS
of ONE feature of OO... (the ability to start up a Method in an object).

Sadly, by your own definition, you are still a foreigner trying to
"translate" OO functionality into what you know and understand. You will
never realise the benefits of OO if you do that, as I posted at length
elsewhere.

(Having said that, I understand WHY you would approach it that way, given
the environment you describe.)
> ****
>
> Now back to my "confessions" ...
>
> Coming from an IBM mainframe background ...
>
> I have always been used to "multi-tasking" (required in a CICS online
> environment - even when COBOL made it difficult) and more to the point of
> another thread "re-entrant" code where multiple instances of the same
"logic"
> must be allowed to run simultaneously (and efficiently and with both
"separate"
> and "shared" data). I won't go into the details of how both CICS and IBM
(DC
> particularly) have supported this functionality for as long as I have
worked
> with them, but needless to say, they have. Therefore, I haven't (thinking
as I
> do in traditional COBOL-think), I don't find anything NEW (other than
syntax) in
> the "functionality" for this in OO COBOL as compared to "traditional" (IBM
> online) COBOL environments.
>
> It should be noted here, that CICS programming (at least as long as I have
known
> it - and I cam in when macro was first being "phased out") has ALWAYS been
> "event driven". So for those using OO in a GUI (or possibly other)
> environments, being "event driven" is no "biggy" change in what COBOL can
(and
> does) do.

It should be noted that IBM does NOT implement (true) re-entrant code in
COBOL (to do so, COBOL would need to save and restore the system state when
system interrupts occur. While this is possible in BAL, there are no direct
facilities for doing it in COBOL). The code used with both CICS and IMS/DC
(as it was), is "serially re-usable". The difference is subtle, but
important. It IS event driven, but only by a particular (limited) Class of
event (a timer interrupt or a terminal interrupt, usually...you cannot set
up your own events...However, it is many years since I used these facilities
and it may be possible now.) The point here is that NONE of this has any
bearing on whether OO is "better" or not... All it proves is that people who
know the IBM environment can do most things using procedural code that OO
programmers can also do. The conclusion is therefore drawn that there is no
point in using OO. The subtlety and the "other" facilities of OO are just
completely missed by this approach. PLEASE see the post I made in this
thread, where I used the analogy of an eagle; it is the best explanation I
can come up with.

>
> Similarly, (and I do NOT confuse GUI with OO - as you can do GUI without
OO and
> OO without GUI - but the two are often "combined"), as I stated in another
> thread, I have been involved with
>
> object-action
> versus
> action-object
>
> paradigm decisions and evaluations for decades now. I "get" the
difference and
> I can see PROs and CONs for each and how to design either (using
traditional
> COBOL - as well as any OO language including COBOL).
>

Yes, I read this post. It suffers by incomplete definitions of exactly what
an "action" is and what an "object" is. (These words may have different
meanings to an OO proponent than they do to you...).

> ***
>
> So to conclude, as I stated in another thread, I *know* I have not
internalized
> OO (COBOL or otherwise) - much less "components" (as distinct from
"modular")
> design. I know that when I am asking about, answer about, or just
commenting on
> OO (COBOL or not) I am doing so as a "foreigner" looking from the outside.
Only
> if I did (or had to) implement at least two applications in OO would I
think
> that I *might* start thinking in OO.
>

Bill, I really despair here. It is like what I posted is in some foreign
language that no one can understand. You don't have to "think in OO". You DO
have to recognise some new concepts and modify some older ones. OO knowledge
does NOT supplant your existing knowledge (well, it certainly hasn't in my
case; "interference" might work at some level; whenever I learn a student's
name, I forget a VSAM reply code...<G>).

For me, I am coming to believe this whole discussion, which we have had
several times here over the last few years, is just a waste of (my) time. I
really don't care whether people use OO or not. I think it is "wrong" to try
and forcefully persuade them to. I have presented arguments that are
unpalatable to many COBOL programmers, and I should have really expected the
response they got.

For people to NOW say: "Hey! Maybe there is something in this OO
thing...maybe we should take a look at it. Let's try and understand some of
it...", after they were advised to do this years ago, when it might have
made some difference to the future of COBOL, just pisses me off to the
extreme. (yes, that's right...there is no pleasing me now...if any of you DO
get into OO I'll be pissed off because you did it too late; if you don't,
I'll be pissed off because you didn't try... <G>)

It is too late. COBOL has missed the boat. NOW, people, seeing their jobs
evaporate to the Barbarians on their fast little OO ponies, think they might
sortie out of the fortress on their shire horses and get a piece of the
action.

Nope. That can't work. It will be necessary to leave the shire horses back
in the fortress. Set an ambush, catch some of the ponies and study them.
Don't EXPECT them to behave like Clydesdales, they won't. (And when you try
and force them to do Clydesdale tasks, they are not better at them...). With
any luck, you may learn to ride a pony. Then you may find that your previous
knowledge of larger, more ponderous, horses, is still applicable. In fact,
you now have extra knowledge which should enable you to match the Barbarians
at their own game. (Get into a bit of looting and pillaging on your OWN
account, it is good for the soul <G>). At least, now you have an OPTION...

But understand, things will NEVER be the way they were in the days of the
Empire, when the High Priests of COBOL guarded the Holy Source Code and made
their magic incantations before the mystical beast with the flashing eyes.

Those days are gone forever. (Despite a few enclaves where the "Word" is
kept alive, the Old Gods of Source Code are dying; the new Gods are
components and they are available to everybody, no "special" knowledge (or
Source Code) required...)

> I hope that this (medium long) post is useful to some in understanding
where I
> come from and more importantly in evaluating your own starting point for
OO
> discussions.
>

For me, it is a finishing point. I don't plan to contribute further on this,
unless specifically asked to.

The only good thing about banging your head against a wall is that it is
nice when you stop <G>.

All joking aside, Bill, you are correct that until you actually build some
successful OO or component based systems, you are unlikely to understand why
guys like me (having worked in the industry for 38 years now, watched fads
come and go, seen it done wrong and seen it done right...) feel passionately
about it.

Regards,

Pete.

Relevant Pages

  • Confessions of an "OO Foreigner"
    ... in COBOL or any other programming language/tool). ... to translate and actually THINKING in that language. ... have been correct about - even though I lost) was the very "INVOKE" statement ... OBJECT-REFERENCE if "invoke" is the correct word at all. ...
    (comp.lang.cobol)
  • Re: freevms 0.2.15 released
    ... feel about the language. ... but the thought of all those CPU ... COBOL, FORTRAN and Ada leads me to believe that no memory leakage ... could often go directly to the particular line of source code and fix it ...
    (comp.os.vms)
  • Re: Web Services and COBOL (Fairly long post, but I dont have time to write a proper article on it)
    ... Menu driven application - from the Trigger start the App ... interoperability in COBOL. ... invoke EventManager "new" returning os-EventManager ... However the web service, although being around 4000 lines of OO COBOL ...
    (comp.lang.cobol)
  • Re: invoking a method
    ... They pretty much all invoke methods in a somewhat similar format in that the object comes first, followed by the name of the method, followed by any parameters. ... MF COBOL ... Comments like "don't you have better things to do with your time then create yet another programming language" will be ignored. ... MOVE EMP1 TO ADD-KEY OF DISPLAYLIST. ...
    (comp.lang.cobol)
  • Re: Heres one problem
    ... So given your format, what percentage of COBOL programmers do you think actually give a picture of data items, WITHOUT a final period/full Stop? ... invoke os-Collection "finalize" ... invoke a-OrderedCollection "finalize" ... A tutorial should demonstrate best practices, ...
    (comp.lang.cobol)