Corruption of COBOL.
in [Cobol]
|
Prev: 182966 Constantly updated Free COmputer and business portal 94
Next: Traditional COBOL environment
From: john on 3 Feb 2010 09:48 Many of the posts to this groups involve translating COBOL from brand x to brand y. And many code snippets would make no sense whatever to a programmer skilled in COBOL 85 or earlier. I submit that this new language isn't really COBOL. It isn't readable by most programmers and isn't portable. It may be useful, it may be fun, but it reminds me of the old hotrodders dictum "jack up the horn and build a car around it." I question whether even the horn has been kept. My general advice is to write in the 85 standard, the last standard that looked like COBOL, and avoid proprietary extensions as much as possible. If some proprietary extensions for reading/writing to gui's are necessary then isolate them as a subprogram or copy files. Writing to COBOL 85 means never having to say "it won't run on my new company's compiler." COBOL should be portable, readable, modifiable by any skilled COBOL programmer and suitable for solving business problems. As a fellow who once shook hands with Grace Murray Hopper I say: "Don't try to rewrite Shakespeare in Esperanto." John Culleton
From: rtwolfe on 3 Feb 2010 11:48 On Feb 3, 9:48 am, "j...(a)wexfordpress.com" <j...(a)wexfordpress.com> wrote: > Many of the posts to this groups involve translating COBOL from brand > x to brand y. And many code snippets would make no sense whatever to > a programmer skilled in COBOL 85 or earlier. I submit that > this new language isn't really COBOL. It isn't readable by most > programmers and isn't portable. It may > be useful, it may be fun, but it reminds me of the old hotrodders > dictum "jack up the horn and build a car > around it." I question whether even the horn has been kept. > > My general advice is to write in the 85 standard, the last standard > that looked like COBOL, and avoid > proprietary extensions as much as possible. If some proprietary > extensions for reading/writing to gui's are necessary then isolate > them as a subprogram or copy files. > > Writing to COBOL 85 means never having to say "it won't run on my new > company's compiler." COBOL should be > portable, readable, modifiable by any skilled COBOL programmer and > suitable for solving business problems. > > As a fellow who once shook hands with Grace Murray Hopper I say: > "Don't try to rewrite Shakespeare > in Esperanto." > > John Culleton John, You should familiarize yourself with the Flexus COBOL products. Our philosophy is and always has been that COBOL source should be compiler independent. Our advanced tools use COBOL CALLs and working storage variables. I'll send more details via private e-mail so that I don't clutter the newsgroup with shameless commercial messages.
From: Pete Dashwood on 5 Feb 2010 05:32 I really enjoyed your post John. I couldn't let it go without comment, though :-) see below... john(a)wexfordpress.com wrote: > Many of the posts to this groups involve translating COBOL from brand > x to brand y. And there are other subtleties like moving from indexed files to relational databases. You may wonder why people would want to do that. > And many code snippets would make no sense whatever to > a programmer skilled in COBOL 85 or earlier. I am a programmer skilled in COBOL 85 or earlier. I first used COBOL 59 on a tape based system in 1967. The new stuff makes perfect sense to me. I think what you wanted to say was that it wouldn't make sense to "a programmer skilled in COBOL 85 or earlier" WHO HAD NOT BOTHERED TO EXPAND HIS SKILL SET AND BELIEVED THAT EVERYTHING HE WANTED TO DO HE COULD DO in COBOL 85 or earlier? Yes, I've met a few of those. They seem to have limited horizons. >I submit that > this new language isn't really COBOL. Object Oriented COBOL is CERTAINLY COBOL and has been endorsed as such by that august body the ANSI. > It isn't readable by most > programmers and isn't portable. I have OO COBOL components running across 7 different platforms (mainframe and Client/Server) on the Web and on the desktop. I have it interacting with modern languages like C#, Java and C++. How can it NOT be "portable"? If you mean the source code is not portable, you might be right, but in the world of objects the source code of an object is irrelevant. If I can write "COBOL" on one platform and know that what I've written can be distributed to every platform that is connected to the World Wide Web, I don't see that portability is a stumbling block. "Not readable by most programmers"? I think you mean Procedural COBOL Programmers. As these are less than 4% of the programmers in the world, I am struggling with your use of "most". MOST programmers in the world can't read COBOL or understand the subtleties of it. Neither do they need to. > It may > be useful, it may be fun, but it reminds me of the old hotrodders > dictum "jack up the horn and build a car > around it." I question whether even the horn has been kept. Certainly the horn has been kept, along with a few other more important parts, but the car is no longer a model T. (Sadly, it is not a Ferrari either, but that is a different discussion). > > My general advice is to write in the 85 standard, the last standard > that looked like COBOL, and avoid > proprietary extensions as much as possible. Sound advice, for people limiting themselves to Procedural COBOL. Unfortunately, the world at large voted with its feet and moved on, some time ago. There is a new paradigm that simply works better for most things. (COBOL 85 is still very good for batch processing, but the days of batch processing may be numbered...) There are still pockets of standard COBOL but most sites are seeking to remove it long term. They are not doing this because of spite against COBOL. They are not doing it even because they can't do what they need to in (modern OO) COBOL. They are doing it because COBOL costs too much, and there are MUCH cheaper (and in many ways better) alternatives available. At this point I might as well go back to the earlier point about people moving to Relational Databases. If you benchmark a well written system using indexed files, for performance against a functionally equivalent Relational Database, there is a fighting chance that the indexed files will win. But it isn't technology that decides. It is cost. It is easier to get people who can write Stored SQL procedures than it is to get COBOL guys. But much more importantly, moving to the RDB environment "opens " the data resource. Now it can be easily shared by spreadsheets and desktop DB systems. Need a report? Instead of taking 3 days to get a COBOL guy to design, code debug and deliver it, you can have it generated by standard software like Crystal Reports or StimulSoft or even ACCESS Reports, in minutes, using a graphic interface that lets you drag and drop fields, control breaks, literals, and totals wherever you want them, instead of the tedium of counting fillers in a printline. Instead of the corporate data asset being locked up behind the mysterious veil of COBOL programming, it is open and available to anyone authorised to access it. >If some proprietary > extensions for reading/writing to gui's are necessary then isolate > them as a subprogram or copy files. > Bob Wolfe has already responded to this, and his company's products are excellent. There are many excellent products you can bolt on to COBOL to enhance its usefulness, but it remains COBOL. There is a very large question mark over its long term future. Like I said before, it simply costs too much and it isn't capable enough, compared to other products that are now available. I am strongly committed to NOT throwing COBOL away and am offering solutions that can extend the life of useful code, but I have no illusions that there will be a long term viability for it. (please visit: http://primacomputing.co.nz/cobol21) Long term, the goal has to be to move to a world of Objects and Layers, where your existing COBOL code can work with other objects written in other languages on the desktop and (increasingly) the web. Object Orientation can do this easily and seamlessly; Procedural code can't. (Fortunately, it is possible to "wrap" existng procedural code so that it can. This is a viable way to bring existing code into the "New Technology".) > Writing to COBOL 85 means never having to say "it won't run on my new > company's compiler." Assuming the new company HAS a compiler. >COBOL should be > portable, readable, modifiable by any skilled COBOL programmer and > suitable for solving business problems. Why? New languages are portable, readable, modifiable by even a moderately skilled programmer and have thousands of prewritten components that immediately solve business problems. Not only that, but most of them are FREE. You can't say that about COBOL. > > As a fellow who once shook hands with Grace Murray Hopper I say: > "Don't try to rewrite Shakespeare > in Esperanto." > Sure. But don't try and rewrite Shakespeare in English, either. Pete. -- "I used to write COBOL...now I can do anything."
From: Alistair on 5 Feb 2010 09:52 On Feb 5, 10:32 am, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > Sure. But don't try and rewrite Shakespeare in English, either. > I can't resist: 2 B / not 2 B?
From: Pete Dashwood on 5 Feb 2010 17:42
Alistair wrote: > On Feb 5, 10:32 am, "Pete Dashwood" > <dashw...(a)removethis.enternet.co.nz> wrote: >> Sure. But don't try and rewrite Shakespeare in English, either. >> > > I can't resist: > > 2 B / not 2 B? LOL! I guess it is only a matterof time before someone with more time on their hands than they should have, produces a TXT version of the works of Shakespeare. If it would get kids to read the original, I wouldn't complain. :-) -- "I used to write COBOL...now I can do anything." |