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

"Robert" <no@[EMAIL PROTECTED]
> wrote in message 
news:0hfut3ll67seud23rj0jbv0herlrotqpeq@[EMAIL PROTECTED]
> On Tue, 18 Mar 2008 11:57:35 +1300, "Pete Dashwood" 
> <dashwood@[EMAIL PROTECTED]
>
> wrote:
>
>>"Robert" <no@[EMAIL PROTECTED]
> wrote in message
>>news:morrt39o3it8im7uvpk5rlc33o6a5i69vu@[EMAIL PROTECTED]
>>> On Mon, 17 Mar 2008 11:39:05 +1300, "Pete Dashwood"
>>> <dashwood@[EMAIL PROTECTED]
>
>>> wrote:
>>>
>>>>There is no need for code review if an Agile approach is adopted. Code
>>>>either works or it doesn't and most of what is written won't be 
>>>>maintained
>>>
>>> What about code that makes complex decisions? How do you know its
>>> decisions are right?
>>
>>By the results. How else would you know whether code is right?
>
> I know by reading the code and understanding what it says. Beyond
trivial 
> cases, it's
> impossible to test all possible inputs to a program, because the number
of 
> combinations
> grows exponentially. That's why truth tables failed.
>
> Say the program is testing three integers. To test every combination of 
> positive values,
> you would need  9903520314283042199192993792 test cases. If it's testing

> five alphanumeric
> bytes, you would need 10000000000 test cases.

So, you test the range limits for each integer and do a number of random 
tests, then apply last month's live data to it....

What you are saying would require you to read and understand every line of

production code on a givern site. Given there could be several million 
lines, this will take longer than your lifetime, and it might not be wrong

anyway...:-)  I prefer the pragmatic approach. It is tested to the 
satisfaction of all interested parties and if it fails after that, it gets

fixed immediately. I am not suggesting that code should not be written 
carefully or thoughtfully. I am saying it can evolve, rather than be 
designed from day one. (At least, it can if you don't have to keep 
maintaining it...and you won't have to, if working functionality is
properly 
encapsulated. If code is NOT integrated, but is separated by layers and 
components, it DOESN'T need the same levels of maintenance and testing.)
OO 
sites know this; it is much harder for non-OO sites to grasp.

>
>>> How do you know what the rules for those decisions are? By talking to
>>> users? Rules must be
>>> in a document of some kind.
>>
>>Only in your world. Certainly not in mine. They can be encapsulated into
a
>>component which simply documents itself.
>
> Self-documenting code. This is where I came in.
>
>>It gets tested and reviewd by
>>interested parties (not just the programmer who wrote it) a number of 
>>times.
>>If you put these things into a document and they change, the document 
>>needs
>>to be updated; if they are put into program code, the tool that
documents
>>the code finds the changes automatically.
>
> Why can't you do that with Cobol or any other language?

You can (and I do...) with C#.

>
>>> Have you ever seen links in program source code?
>>
>>ALL the time. It is a popular and useful way of documenting C#. I set 
>>links
>>to my own notes, to web sites that are pertinent, to sample code on the 
>>Web,
>>all within my own code. Sure, some of these links will fail over time,
but
>>the ones I have control over won't, and I still find it useful while I
am
>>learning the language. C# can also document itself by means of embedded
>>links, to anchor points within the program itself.
>
> That's the way it should be. I'm pleased to read C# people got it right.
>

It is an upward leap from COBOL. But it had the benefit of 50 years of 
hindsight, which COBOL did not.

(I still regard CODASYL with awe; they did an incredible job, given the 
knowledge and circumstances of the time. It is a bloody shame their noble 
vision was screwed over by subsequent guardians of COBOL.)

Also, the author of it is a real world programmer and not an ivory tower 
academic. I have been very impressed with his attitude and approach in 
interviews and instructional videos where he talks enthusiastically about 
it, and where he shares his vision of where he wants it to go. He doesn't 
have to battle a moribund standards authority, like COBOL either.

I still can't believe it is free... it's like you picked a sports car and 
the guy on the lot said: "OK, we really want to get people driving these,
so 
you can have it for nothing..." :-)

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