Re: Making money from Java

"Chuck Stevens" <charles.stevens@xxxxxxxxxx> wrote:
> "Judson McClendon" <judmc@xxxxxxxxxxxxx> wrote:
>>
>> The issue is too vital to simply take someone elses word about what the
>> Bible says. :-)
>
> Saying "The Bible clearly and definitely states ..." is a FAR CRY from
> "What I read in the Bible leads me to believe ... ".

Yes it is. In order to say it honestly you have to be that convinced. Does
it offend you that I am that convinced? You may be completely happy
believing that everything is relative, but there are absolutes.

> Behavior reflecting humility I find more convincing of a Christian life
> than behavior reflecting hubris.

Ha! You find *nothing* convincing of a Christian life, as you have
repeatedly pointed out in great detail. You simply want Christians to be as
uncertain as yourself. Sorry. :-) The fact is, when a person is willing to
submit their will, their very life, to God, that is a very clear indication
of humility, at least in that respect. Being certain about God has no
relationship whatever to hubris. But taking upon yourself the decision to
reject your Creator from your life, *that* is hubris. :-)

>> All that any of us say here simply reflects (hopefully) the best that we
>> know. None of us have perfect knowledge, and none of us are without flaw.
>
> I agree. If you believe that, then what you write ought to reflect it
> consistently. It hasn't, at least to me.

Sorry, I can't help that.

>> From direct and personal experience, I can assure you, this is quite true
>> with respect to myself. :-)
>
> Show me, don't tell me!

Sorry. If you don't believe the evidence Creation, if you don't believe the
evidence of the Bible, and you don't believe the witness of millions who
have met Jesus, then there's nothing I can do for you, except pray for you.
I've been doing that. :-)

>> However, that being said, when someone has devoted a lot of effort and
>> time into studying an issue, they have a right to speak with confidence
>> about the accuracy of what they say. Don't all of use do that on a fairly
>> regular basis? I know Chuck does. :-)
>
> I speak with confidence on issues with respect to the COBOL standard, at
> least in part because I have played an active role in its development over
> the last five years, and have been actively involved in ensuring that
> three different COBOL implementations were in conformance with their
> respective standards for over twenty years. I also have access to the
> standards themselves and am reasonably facile in ferretting out answers to
> questions of what the standard states and what it does not. But when I
> speak clearly on behalf of the standard it is because the standard, having
> been written in English in the first place, is incontrovertibly explicit
> on the particular subject. E.g., it's not a leap to describe the behavior
> of MOVE statements in which the operands overlap as undefined in ANSI-85
> implementations given ANSI X3.23-1985 page VI-69, 6.4.5, Overlapping
> Operands: "When a sending and a receiving item in any statement share a
> part or all of their storage areas, yet are not defined by the same data
> description entry, the result of the execution of such a statement is
> undefined." I don't think there's much wiggle room on that one. If an
> implementor defines the behavior, well, that's up to the implementor, but
> there's no guarantee that any other implementation will be the same. In
> a few cases in '02 COBOL and more in the upcoming draft, I've actually
> written some of the features specified in the standard.
>
> I speak with authority on the Unisys MCP COBOL implementations because I'm
> looking at the Original Text and can tell (in most instances) *exactly*
> what they do. I also have full access to the change history over the last
> twenty years for these products and am therefore able to track exactly
> what each *used* to do. And in the particular case of the COBOL74
> compiler in that environment, I've personally revised around a third of
> the compiler either to improve its maintainability and eliminate
> ambiguities at the source level, or (in the most obvious example of MOVE
> statements involving group items and the PICTURE processor) rewritten all
> of the logic associated with the feature. I have confidence in my
> understanding of the rules for PICTURE because I've written *three
> different* parsers for the PICTURE character-string in my time, each time
> with careful study of the standard, and each time painfully aware of the
> pitfalls therein.
>
> Put a different way, I speak from authority on the subject of Unisys MCP
> COBOL precisely because I am an architect for the products, and it's my
> job to define as well as state what they do.
>
> I speak from a position of authority on the subject of *standard* COBOL
> based on two decades' experience and involvement in defending and/or
> correcting the behavior of the Unisys MCP compilers relative to their
> respective standards for over two decades, which means that I have
> considerable experience finding my way around the documents.
>
> I also speak from a position of authority as that I have been serving as
> the Unisys representative on INCITS/J4, the committee that writes,
> modifies and amends the COBOL standard for the last five years, and as
> part of those duties, served as a part of the US delegation to ISO/IEC
> JTC1/SC22/WG4, the international committee chartered with the overall
> direction and technical content of the COBOL standard. I've also been
> appointed convener (chair) of the latter committee for a three-year term,
> which gives my opinions *some* credibility as to what conforms to the
> standard and what does not!
>
> Despite all that, if you notice, my opinions usually begin with the likes
> of "My reading of <relevant standard>, in particular
> <page-chapter-and-verse citation>, leads me to believe ... that " and
> similar.

I suggest that the question of where your soul will spend eternity is one in
which you should have more certainty than you express by that language.
Would you think it preferable if I were to be a bit more uncertain about my
own destiny? If I expressed lack of certainty in the things in which I place
my faith, you would simply criticize that as lack of faith in what I
believe. You have constructed, by your choice of attitude, a situation in
which you would feel justified in attacking my position either way. Sorry.
:-)
--
Judson McClendon judmc@xxxxxxxxxxxxx (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."


.

Relevant Pages

  • Re: Method to force keeping of source
    ... It appears to me that your wish is that the COBOL standard should prevent ... environment for the compiler or in the execution environment. ... > implementor defined is one of the problems as I look at the situation as ...
    (comp.lang.cobol)
  • Re: Program templates as Object Classes
    ... Here's the problem with OO COBOL - it is still very incomplete.. ... realized that OO was incomplete without support ... It's about two years ago a former, retired M/F Manager, (not Bill Klein ... Micro Focus above - but he was referring to the fact that Standard ...
    (comp.lang.cobol)
  • Re: Program templates as Object Classes
    ... There are users of OO COBOL; they are just far fewer than either the vendors ... whether from the same vendor or not. ... disagreed with you that XML should be supported *first* by the OO features ... > being spent by J4 to provide these facilities through a standard that will ...
    (comp.lang.cobol)
  • Re: Making money from Java
    ... I speak with confidence on issues with respect to the COBOL standard, ... in which the operands overlap as undefined in ANSI-85 implementations given ...
    (comp.lang.cobol)
  • Re: Program templates as Object Classes
    ... some aspects of OO COBOL have grown and evolved since then. ... Classes from ANY vendor on ANY platform can be "wrapped" (provided the ... 2002 standard implemented. ... I really don't care what J4 or WG4 or SG-1 ...
    (comp.lang.cobol)