OpenCOBOL Programmer's Guide
in [Cobol]
|
Prev: ANN: OpenCOBOL Programmer's Guide
Next: Justice for all
From: Michael Wojcik on 11 Feb 2010 15:44 john(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. > I have no hope of > dissuading those who want to turn COBOL into something different, a > clone of some other language, but I do suggest that we fork the > language. What would this accomplish, that choosing to use or avoid specific features would not? Some implementations already let you set options to restrict the source to COBOL85 constructs or some other subset; adding such a feature to the open-source implementations (if they don't already have it) should be easy. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Michael Wojcik on 11 Feb 2010 15:34 James J. Gavan wrote: > > They all up and left forming a new company. He had certainly looked at > .Net but I don't think he had seriously looked at it at the time of our > conversation. But he has since, and asked himself the question, "Why do > I need an expensive COBOL compiler, over an above what .Net provides > free ?". Now some two years later, I haven't heard from him either. Yes, as we've discussed here before, this is a weakness in COBOL as a ..NET language. You can of course get Micro Focus .NET COBOL for free - the personal/academic version of Net Express - but you can't use it for commercial products, and you can't create programs to distribute for free (unless your users are also going to install the free Net Express). Microsoft makes money from Windows and the fancier, non-free versions of Visual Studio and SQL Server and all their other goodies, and that subsidizes their free .NET languages. Many other free .NET languages, like Iron Python and Iron Ruby, are supplied through open-source projects, using a combination of donated labor (donated by the programmers themselves, or their employers) and outside funding. Micro Focus is a business. We have expenses, and we sell products in order to pay for them. It's hard to see how a free, unrestricted .NET COBOL would help pay the bills. Would it really bootstrap a .NET COBOL development community so large that the fraction willing to pay extra for it would subsidize all the development? That seems unlikely. Customers for .NET COBOL (aside from hobbyists and students using the free version) buy it because they have an existing COBOL codebase that they're interested in running as managed code. There's quite a bit of interest in that, particularly when mainframe emulation is added. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Pete Dashwood on 13 Feb 2010 08:54 Michael Wojcik wrote: > James J. Gavan wrote: >> >> They all up and left forming a new company. He had certainly looked >> at .Net but I don't think he had seriously looked at it at the time >> of our conversation. But he has since, and asked himself the >> question, "Why do I need an expensive COBOL compiler, over an above >> what .Net provides free ?". Now some two years later, I haven't >> heard from him either. > > Yes, as we've discussed here before, this is a weakness in COBOL as a > .NET language. You can of course get Micro Focus .NET COBOL for free - > the personal/academic version of Net Express - but you can't use it > for commercial products, and you can't create programs to distribute > for free (unless your users are also going to install the free Net > Express). > > Microsoft makes money from Windows and the fancier, non-free versions > of Visual Studio and SQL Server and all their other goodies, and that > subsidizes their free .NET languages. Many other free .NET languages, > like Iron Python and Iron Ruby, are supplied through open-source > projects, using a combination of donated labor (donated by the > programmers themselves, or their employers) and outside funding. > > Micro Focus is a business. We have expenses, and we sell products in > order to pay for them. It's hard to see how a free, unrestricted .NET > COBOL would help pay the bills. Would it really bootstrap a .NET COBOL > development community so large that the fraction willing to pay extra > for it would subsidize all the development? That seems unlikely. > Agreed. (Although, I wish the universe of potential COBOL "migrators" was big enough to make this worthwhile for you...) > Customers for .NET COBOL (aside from hobbyists and students using the > free version) buy it because they have an existing COBOL codebase that > they're interested in running as managed code. There's quite a bit of > interest in that, particularly when mainframe emulation is added. This is the most sensible post on this subject that I have seen here, and becoming nothing less than I would expect from you, Michael. :-) As time has gone by and more experience has been attained I am coming to question more and more why ANYONE would want to pay for a .NET COBOL compiler. (Not just the MF one, but the Fujitsu one as well.) Interop Services was DESIGNED into .NET to support legacy (unmanaged) code. I have found through experience over a few years now that Interop Services is robust and seamlessly integrated. It really works much better than I had dared to hope. For me (and my clients) a .NET COBOL compiler is as useful as roller skates to a steeplejack or teats on a bull. BUT, you made the realistic point that SOME clients WILL want to continue with COBOL as long as they possibly can, and at the same time, make their transition to a .NET environment. For these people, and given that it comes with other tools which enable mainframe emulation, this could be an attractive (and useful) option. For myself, I don't think so, but I accept that others will (correctly) disagree. I see migration as going way beyond migrating to a database, or running recompiled COBOL in the .NET environment. I see a complete move away from the existing procedural COBOL codebase into a world of objects and layers with automatic generation of separation layers by means of tools, and automatic amendment of existing code to use the newly generated objects which constitute the separation layers.. (There isn't much point in having a bunch of objects to access your new database with, if all your existing code has to be manually changed...) For me, the idea is not to add a few bolt ons to COBOL, or to recompile COBOL so you can have "same old same old" in a new environment, it is to salvage what was useful in the existing environment and bring that into a new environment of objects and layers, where it can run alongside new objects developed in specific OO langauges for .NET (AS WELL AS COBOL, if that is what you REALLY want...) Over the last few months I have been watching people doing this and it is really quite amazing. Someone provides 2 reports that are identical. One is built using the existing on site legacy code and accessing ISAM files, the other is accessing a normalized Relational database, generated from their existing COBOL COPYbooks, using object code that was entirely generated from tools, and application code that was completely automatically modified to invoke the objects, instead of the ISAM code. "Look Ma, no hands!" When you see a web based front end using the same objects, it is really pretty exciting. When you can generate a database and code to access it, then modify the existing application code to use the new objects, converting legacy procedural code into object oriented code, and do all of this in seconds or minutes (if you have many legacy apps.), it is impressive. I have people telling me all the time: "I get a buzz every time I run the Tooset and see weeks of manual work being done in seconds..." But, for me, the excitement is in seeing them leveraging their procedural code into OO code that uses objects, and moving forward in a way that DOESNT tie them to COBOL. If they use a .NET COBOL compiler that doesn't happen. What they have is procedural COBOL running in a .NET environment. They have spent a considerable amount of money to maintain a status quo, which in my opinion, they SHOULD be moving away from. For this reason I have made sure that the Toolset costs less than a .NET COBOL compiler... :-) Obviously, doing this is challenging, and the software tools which make it possible were not written overnight, but we are having increasing successes and I am very optimistic about where things are heading. Oddly enough, we are finding that the COBSTRUCT.DLL which is given away for free on the COBOL21 web site, is critical to some of the migrations. People are using it in ways we could never have envisioned. (I wish I had charged for it; over 200 people have downloaded it and there is no sign of this falling off... :-)) It's a bit sad that Robert Wagner, who wrote most of it, has moved out of COBOL into SQL. I guess it is kind of Robert's legacy. As I have said before, I don't think people who recompile COBOL for .NET are "wrong", but I don't think it is a good long term solution. And I don't think procedural COBOL is going to get the best out of the .NET environment, even running as managed code. I think that this question will be settled in the next 3 years. I'm picking that most people will not choose to go with .NET COBOL but will replace the exisiting procedural COBOL codebase (as Howard has mentioned they are doing in Colorado (rewrite rather than rewrap)), or they will take solutions's like PRIMA's that allow "Objectifying" of existing code so it can run with "New Technology", or, they'll move directly to OO development in the new technology using languages other than COBOL, or they'll outsource or replace their entire IT function with services and/or packages. It would be a very brave (or foolish) manager who would opt for a strategy that was based on COBOL indefinitely. (However it might not be brave or foolish to have COBOL options as PART of the long term strategy...) Will depend on individual sites, I think. Pete. -- "I used to write COBOL...now I can do anything."
From: john on 13 Feb 2010 11:14 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. 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. 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. John Culleton CPP
From: Richard on 13 Feb 2010 13:21
On Feb 14, 5:14 am, "j...(a)wexfordpress.com" <j...(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++. gcc stands for GNU Compiler Collection, it is a collection of programs that provides backend compilers for several architectures and several front-ends (not just 4) for different languages: """The standard compiler release 4.3 includes front ends for C (gcc), C ++ (g++), Java (gcj), Ada (GNAT), Objective-C (gobjc), Objective-C++ (gobjc++), and Fortran (gfortran). Also available, but not in standard are Modula-2, Modula-3, Pascal (gpc), PL/I, D (gdc), Mercury, VHDL (ghdl).[15] A popular parallel language extension, OpenMP, is also supported. The GCC steering committee has recently announced that it will also support the Go programming language in GCC 4.5 or later. [16]""" You will note that the front end for C++ is not the one for C, nor the same as Objective-C's. > 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 The 'variants' are implemented as separate front-ends which can be chosen by the source language indicated by the suffix, or explicitly. > Many command line switches are shared among the variants. One man > page covers all of them. The front ends and back ends (separate ones for each architecture) are implemented to use a common set of switches, as appropriate. > I agree that these four variants are from a programmer's point of view > quite different, in effect different languages. C, C++ and Objective-C may have features in common, and may have derived from a common ancestor, but they are now separate languages each having its own standard and committee. > The same can be said > of procedural COBOL (pre-2002) and objective COBOL. While there is a language called Objective-C this does indicate that 'objective' is a term used to describe a computer language. The term you are grasping for is 'object-orientated'. All COBOL standards have been in one set of standards driven by one committee. C, for example, has been and continue to being changed to become a new edition independently of the committee that is changing C+ +. > 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. No. You are wrong. It may well be true that you are lost and think that it is like reading French (I have seen French COBOL - a preprocessor converted the keywords to english.) but most of the code is just COBOL. There are some differences in terminology. > 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. Again, you may be expressing your own personal experiences. > 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. C and C++ are different languages because of factors that do not apply to COBOL. Specifically C and C++ are controlled by different working groups (WG14 and WG21) while COBOL is still under one. |