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

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.

>> 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.

>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.

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'.

"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"

>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. :)

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

>> 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.