Prev: Help with Tcal
Next: COBOL Error Handling (was: What MF says about ROUNDED(was:Cobol Myth Busters
From: Pete Dashwood on 21 Sep 2007 19:51 "Judson McClendon" <judmc(a)sunvaley0.com> wrote in message news:FmUIi.55648$Y7.19018(a)bignews3.bellsouth.net... > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >> >> ... >> I can assure you I am a very multi-faceted person and no particular >> generalization is going to be totally accurate. ... > > Even "a very multi-faceted person?" ;-) That's a specific description, not a generalization, but I weary of this nonsense... Pete. -- "I used to write COBOL...now I can do anything."
From: Robert on 21 Sep 2007 21:07 On Fri, 21 Sep 2007 12:38:56 -0600, Howard Brazee <howard(a)brazee.net> wrote: >On Thu, 20 Sep 2007 23:29:22 -0500, Robert <no(a)e.mail> wrote: > >>I'm throwing schoolboy insults at mainframers because they destroyed the programming >>language I love. > >What could those mainframers you are insulting on this forum have done >to have kept CoBOL from being "destroyed"? Pete asked the same question sooner. I'll answer both in reply to him.
From: Robert on 21 Sep 2007 21:36 On Fri, 21 Sep 2007 12:45:18 -0600, Howard Brazee <howard(a)brazee.net> wrote: >On Thu, 20 Sep 2007 19:16:43 -0500, Robert <no(a)e.mail> wrote: > >>This could have been prevented by allowing Cobol to change at a normal rate. True >>conservatives would have seen that, and thereby conserved Cobol. > >What is "a normal rate"? Good question. We get the impression rate of change is accelerating, perhaps out of control. Is it really? Computers are marching along according to Moore's Law. Some things never change, for instance human nature. >>What about the ones who destroyed Cobol with excessive resistance to change? They are >>demonstrably not conservatives because they didn't conserve it. > >Give me an example of conservatives changing fast enough to save >something? The United States. It's government hasn't been revolutionalized in ~250 years. >>The most common >>perjorative, dinosaur, might be appropriate. Dinosaurs became extinct because they were >>incapable or unwilling to change .. except for a 'radical faction' that morphed into birds >>and an old school we now call crocodilians. Both are minor players in the biological >>world. > >Dinosaurs changed to survive, and now they are gone. I suppose we >could have morphed CoBOL into Java, but then it wouldn't be CoBOL. Dinosaurs aren't gone, they became birds. Is OO Cobol really Cobol? I think it is. >Dinosaurs were extremely successful. I don't think apes like us will >last nearly as long. I also don't expect Java to last as long as >CoBOL did - things are changing too fast. The longevity of Java depends more on politics than merit. Java is a Sun trademark. C# is Microsoft's competing lookalike, claimed to be what Java should have been. They'll survive until their respective sponsors switch to a replacement. As to the survival of apes, I personally think we'll be supplanted (not replaced) by computers. 'Silicon-based life forms.' When that happens, it will be a knee in the evolutionary curve, a paradigm shift. I think inventing computers was our mission, the 'meaning of human life'.
From: Robert on 21 Sep 2007 21:42 On Fri, 21 Sep 2007 12:48:55 -0600, Howard Brazee <howard(a)brazee.net> wrote: >On Thu, 20 Sep 2007 19:46:02 -0500, Robert <no(a)e.mail> wrote: > >>Unexpectedly, the demand and pay for PL/SQL is sky high. It's number two after Java, ahead >>of C++ and dot-net. Evidently there are shops that write everything in PL/SQL and SQR. How >>desperate and sad. > >Why desperate? > >Sure, I would have more power if there was greater demand for my >skills, but I'm not selfish enough to wish the world would be designed >around me. (Unlike certain politicians) Because SQL isn't generalized enough to 'do everything'. It has difficulty doing things that are easy in traditional programming languages. If the only tool you have is a database query language, every problem looks like a query problem.
From: Robert on 21 Sep 2007 23:15
On Thu, 20 Sep 2007 18:27:53 -0700, Richard <riplin(a)Azonic.co.nz> wrote: > >Robert wrote: >> On Thu, 20 Sep 2007 16:53:29 -0600, LX-i <lxi0007(a)netscape.net> wrote: >> >> >> >You've shown that what used to be significant overhead with subscripts >> >is now gone in one particular environment. >> >> It's gone on all platforms, or soon will be. > >Geez, Robert, is this some magic that will replace everyone's >compilers with brand new ones. Are you walking the streets crying "New >compilers for old" ? Multiplication speed is a function of CPUs, not compilers. A timing test program could show different relative speeds, even though it was not recompiled. >> > But, the completeness of >> >being able to define an array with (an) index(es) of its' very own >> >appeals to some people, who will continue to do it. Using an index >> >isn't 1970's COBOL. >> >> That's true. Indexes were introduced 'recently' in the '74 Standard ... > >To replace subscripts. > >You want to revert to 1960s style. > >> I SAID most Cobol programmers will continue using indexes. > >Just because subscripts have sometimes 'caught up' (or maybe will do) >does not make subscripts better, or even as good as indexes. > >Subscripts may be miscoded with inadequate size or poor usage. >Indexes cannot be. > >Subscripts can be slow. Indexes are always as fast as can be. Valid points. >Subscripts can be corrupted by using the wrong one, there is no check. >Indexes are 'local', they are tied to a table, in fact tied to an >occurs level, the compiler will tell the programmer when they are >wrongly used. Unless the compiler has been 'liberalized' to permit that misuse. I just learned here it's a common extension. I never thought to try it. >Indexes are required for SEARCH. Only the binary version. One can say VARYING on a serial SEARCH. >So why are you trying to persuade people to revert to 1960s >techniques ? Why do you think you are 'modern' when you are simply >uninformed ? The modern feature of my argument is that multiply is no longer slow. Indexes would never have been invented ifmultiply were as fast as load in the Good Old Days. |