Re: J4 - presentation/discussion on "Future of the COBOL Standard"

"Robert" <no@[EMAIL PROTECTED]
> wrote in message 
news:2eojt39d64fen4a9oemc1aorp500lfh92t@[EMAIL PROTECTED]
> On Fri, 14 Mar 2008 01:54:46 +1300, "Pete Dashwood" 
> <dashwood@[EMAIL PROTECTED]
>
> wrote:
>
>>
>>
>>"Robert" <no@[EMAIL PROTECTED]
> wrote in message
>>news:cm4ht3t7o5mpec667tfe24geucbtor16ut@[EMAIL PROTECTED]
>>> On Thu, 13 Mar 2008 02:12:39 +1300, "Pete Dashwood"
>>> <dashwood@[EMAIL PROTECTED]
>
>>> wrote:
>
>>> I said Micro Focus was wrong in the Myth Busters thread, six months
ago. 
>>> I
>>> substantiated
>>> each point with the evidence of at least one timing test.
>>>
>>Fair enough. So you are saying that, based on tests you did, you believe
>>their manual is wrong.
>>
>>No cause for despondency there... :-)
>
> The manual is not wrong about EVERYthing, nor even most things. It is 
> wrong on the points
> I posted. In a few cases where I thought it was wrong and tests showed
it 
> wasn't, I posted
> those results too.

Good. Thanks for clearing that up.
>
>>> Belief trumps evidence in the land of Cobol. I mentioned it now not to
>>> retread the same
>>> ground but to use those faith-based rebuttals as evidence that some
>>> (most?) Cobol
>>> programmers are opposed to dynamic structures.
>>>
>>Belief trumps evidence in many walks of life; COBOL people are not
unique 
>>in
>>this regard. In fact they are just...people.
>
> Present company excepted, of course. :)

:-)

>
>>Personally, I'm not opposed to dynamic structures (I use them all the
time
>>in C#), I'm just opposed to ODO, for the reasons I outlined.
>
> You disliked it 40 years ago and haven't reevaluated that opinion.

Hey! That's not true OR fair... I have evaluated it quite a bit during
this 
thread (apart from anywhere else...). Just because I'm not persuaded
doesn't 
mean I haven't looked.
>
>>Sometimes, I think the problem is that you are thinking in only blacks
and
>>whites, Robert... I say this without malice, and based on the evidence
of:
>>"Belief trumps evidence in the land of Cobol.", "Cobol programmers are
>>opposed to dynamic structures."
>
>>I know there was a time when you ONLY posted such sweeping statements
and
>>you have come a long way since then, but, apart from such statements 
>>causing
>>hackles to rise, they are simply logically untrue, by virtue of their
>>sweeping nature. (If there is one case where Belief DOESN'T trump
evidence
>>in COBOL land then your premise fails, similarly with the second 
>>statement.)
>
> They're leaky abstractions, not syllogistic proofs.
>
> "In an epistemological sense, the human concept of any abstraction is 
> always an
> implementation of deeper abstractions, represented in mental concepts
and 
> verbal
> statements used to convey them. There is no generally agreed-upon
deepest 
> layer of
> abstraction. Much (if not most) of the field of philosophy is predicated

> upon searching
> for such a layer.
>
> The idea that all sufficiently interesting abstractions are leaky thus
has 
> profound
> philosophical ramifications.
>
> Consider the field of physics. A proton is an abstraction which is 
> implemented, on a
> deeper level, by a set of quarks. The extent to which the nature of the 
> quarks "leaks"
> through to the nature of the proton appears to depend largely on context

> such as
> temperature. However, there's no doubt that the quark implementation
leaks 
> through;
> otherwise, it would not be possible to know about quarks. Humans only
know 
> they exist
> based on the extent to which they leak through higher-level
abstractions.

Heavy...:-)

I think I need to take a leak...

>
> In this way, the Law of Leaky Abstractions is a tautology. Any
abstraction 
> that isn't
> leaky cannot be distinguished from a fundamental truth. A fundamental 
> truth is not
> properly an abstraction. Therefore, no abstractions are not leaky."
> http://en.wikipedia.org/wiki/Leaky_abstraction#Philosophical_sense
>
>>I found your post on ODO interesting and it made me think. I expressed 
>>where
>>and why I disagreed, but I don't doubt your sincerity and I don't even 
>>think
>>you are necessarily "wrong", I disagree on aesthetic grounds more than
>>anything... :-)
>
> I LIKE ODO on aesthetic grounds. If a string is 8 bytes long, I find it 
> more pleasing to
> SAY it is 8 bytes long than to say it is 30 bytes long. If a table 
> contains 432 entries,
> the language should operate on 432 entries, not 1,000 entries.
>
> Why are Cobol words limited to 31 characters? Why can't they be any
finite 
> length (less
> than the size of memory)? The reason is because someone, somewhere, had
an 
> aversion to
> variable length strings, found them 'too complicated'.

Oh Dear, there you go assuming again....

I know the answer to this one, because it is one of the questions I asked
on 
my first COBOL course in 1967...

It has nothing to do with variable strings being too complicated for 
compiler writers to deal with.  Later I spent some time with people who
had 
actually written a very popular COBOL compiler, and I even got to patch
the 
compiler myself so it would do what was needed for the site where I was 
employed. All of this experience confirmed that the 31 byte limit on a
COBOL 
name was nothing to do with variable strings being too complicated. I'm
not 
going to tell you what the real reason was, but I can give you this clue:

At the time COBOL was developed the 8 bit byte had not yet become the 
industry standard. Different architectures used 64, 32, or 24 bit words, 
based on a 6 bit character. COBOL ran on these machines just as it did on
8 
bit byte architectures.
>
> "Procrustes (the stretcher), also known as Damastes (subduer) and 
> Polypemon (harming
> much), is a figure from Greek mythology. He was a bandit from Attica,
with 
> a stronghold in
> the hills outside Eleusis. There, he had an iron bed into which he
invited 
> every passerby
> to lie down. If the guest proved too tall, he would amputate the excess 
> length; but if the
> victim was found wanting in height, they were then stretched out on the 
> rack until they
> gained the required inches. ..  Procrustes continued his reign of terror

> until he was
> captured by Theseus, who "fitted" Procrustes to his own bed and cut off 
> his head and feet"
>

Yes, I remember the story of Theseus... :-)

The ending was a real cliff hanger...


>>You are probably right that feelings are involved here; they certainly
are
>>in my case. I just don't like ODO. No really good reason for it, I just
>>avoid it like the plague. BUT, I have never had a program fail because
the
>>DO wasn't set properly and I've never had any problems with ODOs because
I
>>just don't use them.
>
> I've never had to guide the user through installing a 200MB environment
to 
> run my
> programs, because I just don't use .NET. :)

It's actually much easier that defining and accessing tables with ODO.

>
> Last week, I passed up an op****tunity to do that -- wrap Cobol into SOA 
> services and give
> them a pretty C#/AJAX face.

It would be fun.

>
>>> Being a business graduate, he says you could save string expense by
>>> RENTING a string of
>>> the required length and returning it when not in use. Even though 
>>> renting
>>> costs twice as
>>> much as buying, you're not wasting string.
>>>
>>> Thus was born the idea of contract programmers. Expense is doubled but

>>> no
>>> one is idle.
>>
>>I think it is arguable that expense is doubled... if he does the job in 
>>half
>>the time, it certainly isn't... :-)
>
> Doing the job is 50% programming and 50% process overhead. Doing the job

> in half the time
> would require cutting programming time to zero.
>
> Last Sunday, Carl Ichan said on TV (60 Minutes) that he could improve 
> productivity in any
> big company by 30%, just by eliminating waste. By coincidence, the next 
> morning I heard a
> high-powered technology VP say she could improve productivity in any 
> development shop by
> 50%, by good management.
>
> Do I hear 70%?  60%? Going once, twice, SOLD to the lady holding bamboo 
> splints.
>
>>>>I know of no way in COBOL (apart from CICS and Assembler GETMAIN calls

>>>>on
>>>>IBM mainframes) that can DYNAMICALLY allocate storage. So how exactly
am 
>>>>I
>>>>supposed to dynamically allocate these ODO structures?
>>>
>>> I've been doing it heavily, all the time, for over twenty years.
>>>
>>> 1. call 'malloc' using by value length of FOO returning mem-pointer
>>> (every compiler & OS)
>>
>>Gosh, Robert "every compiler and OS"?  How about XEKB under GEORGE on an

>>ICL
>>1900 mainframe? Or CDC COBOL under SCOPE  on a Cyber 76? Or NCR COBOL on
a
>>315? Not fair? OK...How about Fujitsu NetCOBOL under Win XP?
>>
>>The only time I've ever used 'malloc' is in C... Maybe my understanding
is
>>flawed, but why would you state that EVERY OS and COBOL compiler has 
>>access
>>to C language facilities, directly from COBOL?
>
> Think outside the Cobol box. You're not limited to Cobol functions, you 
> can call ANY
> function that follows the XP/ELF/ABI standard. NetCOBOL under Win XP has

> access to
> hundreds, if not thousands, of useful functions. They're only a CALL
away.

So what's the point in using COBOL, then? :-)

Pete.
-- 
"I used to write COBOL...now I can do anything."