OpenCOBOL Programmer's Guide
in [Cobol]
|
Prev: ANN: OpenCOBOL Programmer's Guide
Next: Justice for all
From: Michael Wojcik on 13 Feb 2010 13:01 john(a)wexfordpress.com wrote: > On Feb 11, 3:44 pm, Michael Wojcik <mwoj...(a)newsguy.com> wrote: >> j...(a)wexfordpress.com wrote: >> >>> The C progamming language has now three defined variants. One can >>> write in C, Objective C, and C++. >> This is nonsense, frankly. C, Objective C, and C++ are different >> languages; that the latter two were developed from C does not make >> them "variants" of it, any more than C is a "variant" of B. >> >>> Each is considered a separate >>> entity, although the same base compiler supports each, just as a C >>> compiler supports Open Cobol, Tcl and so on. >> Certainly some compiler front ends support C and other languages. That >> has nothing to do with the relationships among languages. > > Gcc is not a compiler front end. It is a compiler which handles four > variants, C, C++, Objective C, Objective C++. There's GCC, the GNU Compiler Collection, which includes a front end binary named gcc (and various other front ends: g++, gfortran, etc). GCC supports quite a bit more than those four languages, including various Fortran standards, Java, and Ada. C, C++, Objective C, and Objective C++ are not "variants" of anything. They are substantially different languages, as a quick comparison of, say, ISO 9899 (the C standard) and ISO 14882 (the C++ standard) would show. > There is one man page > for gcc that covers the variants, and the command line options for > each. The gcc man page does not define the languages. For that matter, it doesn't define GCC, or even gcc. The official reference for GCC is the texinfo GCC documentation, available from gcc.gnu.org. > The compiler chooses the correct variant by the suffix of the > source program The front end chooses the correct language-dependent tier. Many compilers have front ends that do this; it says nothing about the relationships among the languages they recognize. > If by your argument C and C++ are separate languages They're separate languages because they have separate standards documents. C has an official definition, and C++ has an official definition, and they are different definitions. > [an OO COBOL program is not comprehensible to a maintainer who > knows only COBOL85] Certainly. Neither is a Ruby program, or a C program, or a Fortran program, or a LISP program. I suspect the hypothetical COBOL85-only programmer would find the OO COBOL language skills easier to acquire than any of those others. At any rate, this does not in itself make an argument for restricting COBOL to the '85 standard. You could certainly claim that there is economic advantage for maintainers to refuse to acquire new skills, or for organizations to employ such maintainers - but that remains to be demonstrated. > then by my > argument COBOL85 and COBOL2002 are or rather should be separate > languages also. Whether they should be is, of course, a subjective question. Objectively, they are not, since one standard (the 2002 COBOL standard) defines them both, having superseded the 1985 COBOL standard. New programming languages are constantly being developed. Many existing ones are being extended and refined. Analogous changes happen in most industries. Practitioners may accommodate change, or they may refuse to do so. Sometimes the strategy they pick is successful. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Pete Dashwood on 13 Feb 2010 18:14 john(a)wexfordpress.com wrote: > On Feb 11, 3:44 pm, Michael Wojcik <mwoj...(a)newsguy.com> wrote: >> j...(a)wexfordpress.com wrote: >> >>> The C progamming language has now three defined variants. One can >>> write in C, Objective C, and C++. >> >> This is nonsense, frankly. C, Objective C, and C++ are different >> languages; that the latter two were developed from C does not make >> them "variants" of it, any more than C is a "variant" of B. Variants >> of C are K&R C, C90, C95, and C99; and arguably the various >> not-quite-C languages, like that implemented by gcc's C compiler in >> non-standard mode. >> >> If Objective C is a "variant" of C, then so is D, and so are plenty >> of other "improved C" languages. >> >>> Each is considered a separate >>> entity, although the same base compiler supports each, just as a C >>> compiler supports Open Cobol, Tcl and so on. >> >> Certainly some compiler front ends support C and other languages. >> That has nothing to do with the relationships among languages. > >> Michael Wojcik >> Micro Focus >> Rhetoric & Writing, Michigan State University > > Gcc is not a compiler front end. It is a compiler which handles four > variants, C, C++, Objective C, Objective C++. There is one man page > for gcc that covers the variants, and the command line options for > each. The compiler chooses the correct variant by the suffix of the > source program, such as: > file.cc > file.cp > file.cxx > file.cpp > file.CPP > file.c++ > file.C > > Many command line switches are shared among the variants. One man > page covers all of them. > > I agree that these four variants are from a programmer's point of view > quite different, in effect different languages. The same can be said > of procedural COBOL (pre-2002) and objective COBOL. > > Open Cobol can be restricted to Cobol85 by a switch. But that is not > the point. A program written > COBOL 2002 using all its OO features is totally different than one > written in COBOL 85. A programmer > skilled in one will be lost in the other. It is like reading English > versus reading French. John, I respect your point of view (even though I don't share it) but PLEASE qualify these generalizations. "A programmer skilled in one will be lost in the other." That is simply insulting to the many programmers for whom that ISN'T the case (and I am one). It is ONLY programmers who have NOT expanded their skill set who will be "lost" and even then, bright people can usually figure out OO COBOL. You are assuming that most COBOL programmers have NOT moved on to something else as well as COBOL. I believe that is arguable. Certainly, there are an old guard now approaching retirement who "got by" writing procedural COBOL for a lifetime, but the people who have always been into programming computers largely didn't do that, and your remark is offensive to them. Many people (and I have worked with a number of them) learned Java (which includes OO concepts) and would be quite capable of "reading" OO COBOL, others have moved to web based environments and learned Perl, PHP, even Eiffel, all of which include Object Orientation. The days when we all wrote COBOL because that was all we needed, are long gone and many COBOL guys moved on. > > The worst program to deal with as a maintenance programmer is one that > mixes the two. > That requires one to be bilingual. It is like Spanglish as spoken in > Spanish Harlem. > The brain load on the maintenance programmer is too high. Some would argue that being a clerk in the Civil Administration, or running for political office, might be better career options than computer programming for someone who has problems with high brain loads. Some of us actually revel in using our brains. > > If by your argument C and C++ are separate languages then by my > argument COBOL85 and COBOL2002 are or rather should be separate > languages also. The extension of COBOL to have OO facilities, in my opinion is one of the greatest feats of software engineering of all time. It was carried out by people with imagination and vision and they made it seamless. Unfortuantely it was a bridge too far. They were simply ahead of the game and the community using COBOL wasn't. Nevertheless, it is completely unfair to suggest that they created a new language. They worked very hard to stay true to the concepts and methods embodied in the existing language. They simply extended it to encompass a paradigm they could see was going to be important. In my opinion it is a pity the COBOL community couldn't see it. Guys like yourself, fiercely resistant of change to COBOL, scotched it and the result is what we see today. If, instead, they had embraced it and OO COBOL was being used in development all over the world, we would today see COBOL objects playing nicely alongside C, C++, Java, VB, and C# , and interacting with them. That is the world I live in and it is a very pleasant one. (Not to mention effective...) Pete -- "I used to write COBOL...now I can do anything."
From: Brian Tiffin on 15 Feb 2010 14:17
Updating link address for Gary's shiny new document. http://opencobol.add1tocobol.com/OpenCOBOL%20Programmers%20Guide.pdf This should be a long term link address that COBOL programmers can pass down to their grandcoders for generations to come. ;) Much thanks to Gary. Gary has done the world a favour that can't not help expanding COBOL knowledge and mindshare, imho. And OpenCOBOL gets some press ... all the more. Nice thing this. Cheers, Brian Tiffin |