billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/22/90)
From article <420@mck-csc.UUCP>, by jw@mck-csc.UUCP (Jeffrey Weiss): > All these recent jokes about COBOL's age and verbosity are fun, but, if > we can get serious for just a sec. or two... > > What are the real SUBSTANTIVE problems with COBOL? Suppose I were suddenly in > charge of a large DP shop. Would it make sense for me to migrate away from > COBOL? Remember that my DP shop has billions of lines of installed code in > COBOL, and conversion will require enormous time and cost. Not to mention > exposing me to the risk of problems when installing new softwares. > > Now, I'm a reasonably hi-tech guy, not long out of Engineering school, but > I need real arguments (that make business sense) to give to my boss, the CEO. > And, are there viable alternatives such as "re-engineering" the existing code > and investing in tools that make the COBOL environment more palatable? From a business perspective, the real substantive problem with COBOL is that typically 80% of effort is spent trying to maintain code which fundamentally is unmaintainable. The reason for this is that COBOL has found itself unable to evolve quickly enough to keep up with the last 20-30 years' worth of evolution in programming language technology. The language COBOL was invented by the US Department of Defense, and later abandoned because it was no longer adequate as a tool for the effective support of good software engineering practices. Since the DoD also has had a large installed base of COBOL software, it has been the leader in applying effective strategies for dealing with that particular problem. The Ada programming language was designed with a mechanism called "pragma Interface" which enables it to call code written in other languages. If you have one of the compilers which supports calls to COBOL (the IBM Ada compiler should certainly be able to do this), you can simply call upon your existing COBOL software system for as long as it remains serviceable. Ultimately, old COBOL systems become so unmaintainable that it makes sense to rewrite the system, and at that point the system should be rewritten in Ada. So the conversion need not be done all at once (although there are a number of companies which will gladly do such a conversion for you, for enough $$$); by simply using Ada for all NEW code, it is possible to upgrade to Ada incrementally without too much stress on the organization. Now let me just briefly sketch out why COBOL is considered to be no longer adequate. In Ada there is a concept of separating specification from implementation. You can design a software system in terms of different subsystems by specifying (in a "package specification") how each of the subsystems is to function. Then you compile these into the Ada program library. Now there is an agreement among the members of the software development team that this is what the different subsystems will do, and all that remains is to write the software which will cause the subsystems to do what is expected of them. What has happened is: we have broken down a large problem into several smaller subproblems. Now the project can be broken up into several different programming teams, NONE OF WHICH KNOWS ANYTHING ABOUT HOW ANY OF THE OTHER SUBSYSTEMS ARE ACTUALLY IMPLEMENTED. It is enough that they understand how the other subsystems are to operate. They can then write their particular subsystem relying only on the services which the other subsystems have agreed to provide -- the specification of their subsystem is a "contract" that they must fulfill, and in turn the other teams must fulfill their contracts. The Ada compiler will ensure that the terms of the contract are adhered to. So why is this going to help us in maintenance? Well, let's assume that a change is needed. Unless it's a truly major change which would basically invalidate the entire system, we can almost always limit the scope of the change to a particular subsystem. If that subsystem is in turn partitioned into different sub-subsystems, the change can be limited even further. Only the changed area will have to be recompiled, and soon the modified system is up and running. But what if there has to be a change in the terms of a contract? Now the Ada compiler REALLY helps you out... it will automatically identify parts of the software system which depended upon the old contract but which are no longer being satisfied due to the changes which were made. It helps you to minimize the extent of any needed changes, and helps you to track and control the effects of any major change. But more than this -- think about the potential for reusing subsystems. Once you have a very useful subsystem written and tested, you can use it over and over again without any copying of code. With copying of code there is the problem of trying to find all the copies to update them in case there is a change, but in Ada there is no need. If you find a defect in the implementation of a subsystem, you can simply correct the implementation and let the Ada compiler handle the rest. And there is even the ability to construct "generic" subsystems -- subsystems which are written to do something generally and which (with you supplying a small amount of information) can be quickly customized to do it in a particular fashion. For one example, suppose that you wanted to have a priority queue (a system in which items are deposited with different priorities, and you always want to retrieve the item which has the minimum or maximum priority). In Ada, you can write a package Generic_Priority_Queue in which the idea of a priority queue is programmed, without knowing exactly what type of object is to be carried in the queue (the user will decide this). Later, the user comes along, describes the type of object to be carried, and all that software for handling a priority queue is immediately made available for use with that type of object, courtesy of your Ada compiler. You could also describe a network and how to do things with it (compute the shortest path between two points, find out how many connections will have to break in order to cut off all paths between two given points, etc.) independently of the type of object at each point or the nature of the connections. As you can see, this is a very powerful mechanism for reuse. This article is long enough already, but if you pick up a book on the Ada programming language and study it, you will begin to realize just how much advancement has occurred over the last 20-30 years, and how COBOL has not kept up with the times. Please contact me via electronic mail (the address is wtwolfe@hubcap.clemson.edu) if there is anything I can provide (such as hard numbers on exactly how much Ada has been demonstrated to improve productivity) which would fall outside of the intended scope of the alt.cobol newsgroup. As a specialist in Business Information Systems who has chosen Ada as the preferred technology for that domain, I will be happy to provide assistance to anyone who would like more information on why I believe this is far and away the best language technology for the domain of Information Systems applications. Bill Wolfe, wtwolfe@hubcap.clemson.edu
jw@mck-csc.UUCP (Jeffrey Weiss) (03/23/90)
In article <8458@hubcap.clemson.edu>, billwolf exercises the keyboard and comes up with: >From article <420@mck-csc.UUCP>, by jw@mck-csc.UUCP (Jeffrey Weiss): >> >> ...What are the real SUBSTANTIVE problems with COBOL? > > From a business perspective, the real substantive problem with COBOL > is that typically 80% of effort is spent trying to maintain code which > fundamentally is unmaintainable. The reason for this is that COBOL has > found itself unable to evolve quickly enough to keep up with the last > 20-30 years' worth of evolution in programming language technology. > [ ...history of COBOL and Software Engineering 101 deleted...] > Now let me just briefly sketch out why COBOL is considered to be no > longer adequate. [ ...brief 80-line description of Ada features deleted...] Those lines indicated two features (apparantly well supported by Ada) that might be linked to maintainability. Those are: - Module dependency tracking to aid in identifying "ripple-effects" when implementing a change. - Ability to build callable libraries of generic functionality, thus supporting layered, modular programming. I agree, these are important. (Someone else has mentioned local variables not existing in COBOL, a feature which fits nicely in the above list.) Now, are there really no ways to implement the above features in a COBOL environment? Are function calls and libraries not possible for some reason? And could tools such as SCCS or "make" provide the first point? ...mit-eddie!mck-csc!jw Jeffrey Weiss
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/23/90)
From article <423@mck-csc.UUCP>, by jw@mck-csc.UUCP (Jeffrey Weiss): >> typically 80% of effort is spent trying to maintain code which >> fundamentally is unmaintainable. The reason for this is that COBOL has >> found itself unable to evolve quickly enough to keep up with the last >> 20-30 years' worth of evolution in programming language technology. > % - Module dependency tracking to aid in identifying "ripple-effects" % when implementing a change. % - Ability to build callable libraries of generic functionality, thus % supporting layered, modular programming. % % I agree, these are important. (Someone else has mentioned local variables not % existing in COBOL, a feature which fits nicely in the above list.) Now, are % there really no ways to implement the above features in a COBOL environment? % Are function calls and libraries not possible for some reason? And could % tools such as SCCS or "make" provide the first point? There's considerably more as well... Ada's exception handling (a means of "damage control", similar to COBOL's "ON END" but considerably more sophisticated) and many other safety features enhance the reliability of software systems in ways that simply cannot be attained within COBOL. There is also multitasking -- the ability to express the idea of objects which do their work in parallel. Here COBOL is helpless, even though it is much more natural in many cases to break down a system into different objects which exist in parallel and interact with one another. And remember the generic priority queue I described earlier? If one is to design such a system so that it can hold any number of objects, it is necessary to implement it using what is known as "recursion". This is what happens when a procedure or function calls itself, an idea which COBOL strictly prohibits. Recursion is considered to be fundamental to the proper implementation of many such data structures, and in fact is a fundamental basis of much of Computer Science. There is also tremendous difficulty when one tries to describe what is known as an "abstract data type" in COBOL. This is a style by which one identifies and characterizes a real-world object through a description of the operations which can be done with that object, such that a guarantee exists that nobody can do anything with the object without making use of the predefined operations available for it -- this makes sure that the "integrity of the abstraction", or the standard concept that everyone has of the object, is upheld. In COBOL, even the idea of having user-defined types is not supported, much less supported with the level of enforcement provided by the Ada "limited private" mechanism. There is quite a lot that COBOL has missed out on over the years, and this is why the DoD has given up on the idea of continuing to use it. With Ada support available now for typical MIS platforms, and given the prospect of an incremental conversion, it just doesn't make much sense to continue on with COBOL. Bill Wolfe, wtwolfe@hubcap.clemson.edu
mph@lion.inmos.co.uk (Mike Harrison) (03/23/90)
In article <8458@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From article <420@mck-csc.UUCP>, by jw@mck-csc.UUCP (Jeffrey Weiss): >> All these recent jokes about COBOL's age and verbosity are fun, but, if >> we can get serious for just a sec. or two... ... > > Now let me just briefly sketch out why COBOL is considered to be no > longer adequate. In Ada there is a concept of separating specification > from implementation. You can design a software system in terms of > different subsystems by specifying (in a "package specification") how > each of the subsystems is to function. Then you compile these into > the Ada program library. Now there is an agreement among the members > of the software development team that this is what the different > subsystems will do, and all that remains is to write the software > which will cause the subsystems to do what is expected of them. What > has happened is: we have broken down a large problem into several > smaller subproblems. Now the project can be broken up into several > different programming teams, NONE OF WHICH KNOWS ANYTHING ABOUT HOW > ANY OF THE OTHER SUBSYSTEMS ARE ACTUALLY IMPLEMENTED. It is enough > that they understand how the other subsystems are to operate. They > can then write their particular subsystem relying only on the services > which the other subsystems have agreed to provide -- the specification > of their subsystem is a "contract" that they must fulfill, and in turn > the other teams must fulfill their contracts. The Ada compiler will > ensure that the terms of the contract are adhered to. First let me say that I am an enthusiastic supporter of Ada's separate compilation mechanism and the separation of specification and implementation. I believe that those mechanisms, together with private types and packages are *well* worth the (occasional) infelicities of Ada. [I particularly miss the 'everything is an expression' character of Algol 68!] However, let's not get carried away by all this. Yes, the Ada specifications do provide a sort of interface contract, but they only enforce the *syntactic* (and perhaps *static* semantic) aspects of the interface, for example, for subprograms: - number and order of parameters, - types of parameters, - modes of parameters, - types of results. There is however, no support for checking the *dynamic* semantics of the interface, so the programmers on opposite sides of the interface may take very different views of the *meaning* of so data or code object, eg. a parameter may describe a 'length'; the specification writer may view this as 'feet', the writer of the body may treat the value as 'inches' and some user may be expecting 'metres'. This is usually handled by an associated 'specification document', (I know that complicated data type definitions can be written to ameliorate this example, but that still can't prevent a programmer from multiplying by 12 to convert from 'feet' to 'inches'). I am not saying that Ada should have included mechanisms to control this sort of problem, it was a considerable advance of previous languages, but I think that we should not try to *oversell* Ada. There is probably a case for putting some kind of assertion mechanism (at least on interfaces) into the new Ada design. I know about the problems of dynamic assertions, what I mean is some sort of statically evaluable assertions, to be used as an extension of the present separate compilation checks. Has anybody done any work on this? Mike, Michael P. Harrison - Software Group - Inmos Ltd. UK. ----------------------------------------------------------- UK : mph@inmos.co.uk with STANDARD_DISCLAIMERS; US : mph@inmos.com use STANDARD_DISCLAIMERS;
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/24/90)
From mph@lion.inmos.co.uk (Mike Harrison): > Yes, the Ada specifications do provide a sort of interface contract, > but they only enforce the *syntactic* (and perhaps *static* semantic) > aspects of the interface... There is however, no support for checking > the *dynamic* semantics of the interface... To completely check the semantics of the interface is probably so computationally complex as to be not realistically achievable. But practically speaking there is a way to let Ada help you here as well. Simply temporarily *remove* the modified procedure or function from the specification and recompile. Then the Ada compiler will point out *all* places at which the modified procedure or function was referenced. Now recompile the "complete" specification, and verify that all the points at which the semantically modified procedure or function was referenced are OK with respect to the semantic modification. This has the disadvantage of perhaps being overconservative -- leading you to points at which the semantic change may not actually do any harm -- but it's certainly better than manually trying to track the effects of the change, and in all probability it's the most practical solution. Bill Wolfe, wtwolfe@hubcap.clemson.edu
madd@world.std.com (jim frost) (03/24/90)
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) babbles: > There is also multitasking -- the ability to express the idea of > objects which do their work in parallel. [...] > it is necessary to implement it using what is known as "recursion". > This is what happens when a procedure or function calls itself [...] > ...an "abstract data type" ... is a style by > which one identifies and characterizes a real-world object through > a description of the operations which can be done with that object, What is this, a review of a freshman course in CS? Have you resorted to believing that all people who use cobol are "common folk, people of the land (you know, morons)"? Assume, for a change, that we're all professionals here and don't need trivial concepts described, especially inaccurately. jim frost saber software jimf@saber.com
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/25/90)
From madd@world.std.com (jim frost): > What is this, a review of a freshman course in CS? Have you resorted > to believing that all people who use cobol are "common folk, people of > the land (you know, morons)"? At my undergraduate institution, those who opted for the CIS program (Computer Information Systems) rather than the CS program (Computer Science) did not receive instruction regarding topics such as ADTs, recursion, and so on, receiving instead extensive COBOL and database knowledge without benefit of a solid computer science foundation. This was at Purdue University, the first institution in the world to institute a computer science program... the pattern seems to have been characteristic of CIS programs at that point in time. > Assume, for a change, that we're all professionals here and don't need > trivial concepts described, especially inaccurately. Please explicitly point out what specific statements you considered inaccurate, if any. The fact that many CIS degrees do not provide their holders with adequate preparation for the task of keeping up with technical advances in computer science does NOT imply any lack of professionalism on the part of the degree-holder, at least from my point of view. Your view, of course, may be different. Bill Wolfe, wtwolfe@hubcap.clemson.edu
steve@uspm650.Dayton.NCR.COM (Steve Bridges) (03/25/90)
In article <1990Mar24.154331.3328@world.std.com> madd@world.std.com (jim frost) writes: >billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) babbles: >> There is also multitasking -- the ability to express the idea of >> objects which do their work in parallel. >[...] >> it is necessary to implement it using what is known as "recursion". >> This is what happens when a procedure or function calls itself >[...] >> ...an "abstract data type" ... is a style by >> which one identifies and characterizes a real-world object through >> a description of the operations which can be done with that object, > >What is this, a review of a freshman course in CS? Have you resorted >to believing that all people who use cobol are "common folk, people of >the land (you know, morons)"? > >Assume, for a change, that we're all professionals here and don't need >trivial concepts described, especially inaccurately. Jim is right -- this does sound like a freshman CS course (a whole lot like a one I took). Let's face facts -- there is nothing inherently wrong with COBOL. A properly structured COBOL program CAN have a modular design, can do recursion (see the following code segment: PROCEDURE DIVISION. MAIN-PARA. MOVE "N" TO PARA-STOP. PERFORM PARA-A THRU PARA-A-EXIT. STOP RUN. PARA-A. do something here. PERFORM PARA-A THRU PARA-A-EXIT UNTIL PARA-STOP = "Y". PARA-E-EXIT. If you dissect that code, it is recursive. The initial call in the main paragraph will execute ONCE. The second perform within PARA-A will continue to perform PARA-A UNTIL THE EXIT CONDITION IS MET!. Granted, COBOL was designed a long time ago, but it is still a valid language, and possibly more portable than C. COBOL exists for all the operating systems I am familiar with (Unix, MS/PC-DOS, CP/M, MVS, VMS, VRX, ITX, IRX, IMOS.....). You can take that same COBOL code, re-compile it on the target machine, and IMHO, probably spend less time getting it to work than trying to take a C program with it's dependence on include files. Don't get me wrong, C is great for some things, but let's remember why COBOL was developed... for businesses. Not to write operating systems in, or word processing applications, or other similiar types of things where you have to get down and talk to the hardware at a lower level than COBOL (or FORTRAN) will allow. In our department, we use COBOL on a daily basis. Why? Because development time is quicker, debugging is easy, file I/O is quick, and it runs like a scalded cat. But, we also use 4 G/L type products like Informix and Progress. Why don't we use Pascal/C, or other object oriented type stuff? Because IT DOESN'T MEET OUR NEEDS. We need to analyze business information, not spend time worrying about abstract data types and whether our product can do recursion. Granted, if we were responsible for writing operation systems and the like, OO type languages would be the choice, but we don't. Bill - I guess what I am trying to say is don't condemn a language that people use until you look at what the problems they are trying to solve. -- Steve Bridges | NCR - USG Product Marketing and Support OLS Steve.Bridges@Dayton.NCR.COM | Phone:(513)-445-4182 622-4182 (Voice Plus) ..!ncrlnk!usglnk!uspm650!steve | AOPA #916233 ..!uunet!ncrlnk!usglnk!uspm650!steve| PP-ASEL, AMEL
madd@world.std.com (jim frost) (03/26/90)
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847) writes: > Please explicitly point out what specific statements you considered > inaccurate, if any. Earlier he had written: > There is also tremendous difficulty when one tries to describe what > is known as an "abstract data type" in COBOL. This is a style by > which one identifies and characterizes a real-world object through > a description of the operations which can be done with that object, > such that a guarantee exists that nobody can do anything with the > object without making use of the predefined operations available > for it You are defining "abstract data type" incorrectly; I would call it "any data type which does not exist by default in the language specification". What you are describing is a little more complex than an abstract data type, yes? Happy hacking, jim frost saber software jimf@saber.com
alawrenc@sobeco.com (a.lawrence) (03/28/90)
From article <8483@hubcap.clemson.edu>, by billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ): > From madd@world.std.com (jim frost): >> What is this, a review of a freshman course in CS? Have you resorted >> to believing that all people who use cobol are "common folk, people of >> the land (you know, morons)"? > > At my undergraduate institution, those who opted for the CIS program > (Computer Information Systems) rather than the CS program (Computer > Science) did not receive instruction regarding topics such as ADTs, > recursion, and so on, receiving instead extensive COBOL and database > knowledge without benefit of a solid computer science foundation. > > This was at Purdue University, the first institution in the world > to institute a computer science program... the pattern seems to have > been characteristic of CIS programs at that point in time. > I don't know when you did your studies in Computer Science, but I did mine in the late 60's at the U. of Waterloo. COBOL was never mentionned once in the curriculum at the time and databases were still the subject of much research and very little practicle experience. I did recieve a fairly good *basic* training in compiler theory, numerical methods, basic operating systems concepts, and hardware theory. >> Assume, for a change, that we're all professionals here and don't need >> trivial concepts described, especially inaccurately. > > Please explicitly point out what specific statements you considered > inaccurate, if any. The fact that many CIS degrees do not provide > their holders with adequate preparation for the task of keeping up > with technical advances in computer science does NOT imply any > lack of professionalism on the part of the degree-holder, at least > from my point of view. Your view, of course, may be different. > Keeping up with the technical advances in information science is a matter of professionalism, not basic education. In the *REAL* world, there is no need for the average programmer to be a "Software Engineer". In fact, based on over 20 years of experience, I find that perhaps 1 programmer/ analyst out of 10 in a large installation (over 100 programmer/analysts) could even be remotely classified as a "Software Engineer"; and those I would classify as "Software Engineers" have the strangest educational backgrounds from high-school drop outs to PhD's in Nuclear Physics. You may dislike COBOL, but for large _business_ systems I wouldn't use any other language. I can put multiple programmers to work on the same program (I have had as many as 10 work on the same program at the same time). The programmer who "tests/debugs" a module does not have to be the programmer who wrote it. Without any code generation tools I can expect an average though put of approx. 100 line of code per man day, including design and testing time. The code will be portable without any special hooks (i.e. conditional compilation lines) to any machine with a ANSI COBOL compiler. My programmer's won't waste time chasing bugs cased by pointers being misused, writing special file access routines, or trying to write their "own" function for string manipulation. Most of what you have described in previous posts as the qualities of ADA and deficiencies of COBOL are not a properties of the actual language being used, but rather of the analysis and design tools being used. No computer language is going to make future maintenance and enhancement easier if proper thought is not put into the design before the first line of code is written. While object oriented techniques provide many advantages, there is also a price to pay in code size and especially performance. --- On a clear disk you can seek forever. ------------------------------------------------------------------------- Andrew Lawrence | alawrenc@sobmips.sobeco.UUCP Informaticien Conseil | {attcan,mcgill-vision}!sobeco!sobmips!alawrenc 3462 Jeanne-Mance, #1 | Montreal, Que CANADA | Voice (514) 281-5196
ext_iai@gsbacd.uchicago.edu (03/29/90)
>You may dislike COBOL, but for large _business_ systems I wouldn't use >any other language. I can put multiple programmers to work on the same >program (I have had as many as 10 work on the same program at the same >time). The programmer who "tests/debugs" a module does not have to be the >programmer who wrote it. Without any code generation tools I can expect >an average though put of approx. 100 line of code per man day, including >design and testing time. The code will be portable without any special >hooks (i.e. conditional compilation lines) to any machine with a ANSI >COBOL compiler. My programmer's won't waste time chasing bugs cased >by pointers being misused, writing special file access routines, or trying >to write their "own" function for string manipulation. > I am surprised (due to my lack of knowledge, I am sure) to hear that COBOL is still a serious system development tool outside of places like EDS which (according to their sunk cost fallacy management style) has spent huge amounts developing tools for managing COBOL programmers... The things which you laud about COBOL development do not seem, to me, to be unique to COBOL. Is their a specific kind of application or hardware platform that your points are true for? Would you say that UNIX is not a serious business OS platform? Would you use COBOL on a UNIX system? What kind of user interfaces does COBOL support -- or are you using a client-server architecture which allows for user interfaces to be developed on completely different platforms? Forgive my naive questions, I just want to learn and all of my CS work has been in assembly, C, and various "small system" OS... yours, Edward Shelton Mgr, Operations and Technology Information Arts Inc. ext_IAI@gsbacd.uchicago.edu
mfeldman@seas.gwu.edu (Mike Feldman) (03/29/90)
Truce! PLEASE.......? --------------------------------------------------------------------------- Prof. Michael Feldman Department of Electrical Engineering and Computer Science The George Washington University Washington, DC 20052 +1-202-994-5253 mfeldman@seas.gwu.edu ---------------------------------------------------------------------------
dwiggins@atsun.a-t.com (Don Dwiggins) (04/07/90)
From article <420@mck-csc.UUCP>, by jw@mck-csc.UUCP (Jeffrey Weiss): > > Now, I'm a reasonably hi-tech guy, not long out of Engineering school, but > I need real arguments (that make business sense) to give to my boss, the CEO. > And, are there viable alternatives such as "re-engineering" the existing code > and investing in tools that make the COBOL environment more palatable? You seem to have provoked a storm; I'll try to give a response that makes business sense. I think that it does make sense to migrate away from Cobol, but not too fast. The migration should be part of the company's overall plan of improving its software engineering capability, and should take other elements of the plan into account, e.g. what platforms are we writing software on and for? What skills do our folks have now, what are they willing to learn, what kind of experience is possessed by the kind of people we'd like to hire? How do we plan to maintain, enhance, and obsolete our current software base? You get the idea; language religion plays a fairly small part in it. Yes, there are re-engineering and reverse engineering tools for Cobol, in fact more for it than any other language (after all, there's a huge vein of spaghetti Cobol waiting to be mined). In addition to restructuring programs so they can be more easily maintained, design information can be extracted to simplify porting to another language. Hope this helps, -- Don Dwiggins "Solvitur Ambulando" Ashton-Tate, Inc. dwiggins@ashtate.a-t.com
jay@splut.UUCP (06/02/90)
Article-I.D.: splut.=R0+#.A References: <8151@tank.uchicago.edu> <1990Mar30.074056.5936@sobeco.com> <1990Mar31.160005.12743@world.std.com> <1722@sparko.gwu.edu> Reply-To: jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) Followup-To: alt.dev.null Organization: Confederate Microsystems, League City, TX Lines: 25 In article <1722@sparko.gwu.edu> mfeldman@seas.gwu.edu () writes: >Oh, Lord! Are we gonna see a language war on the _Ada_ group between the C >and Cobol and RPG guys? _Please_ take it somewhere else, fellas... >If you want to argue about Cobol, don't cross-post to the Ada group... >I thank you, and so, I'm sure, do other folks who wanna discuss _Ada_ here. If you wanna argue about how ADA is better than COBOL, _please_ don't cross-post to the COBOL group, either. We want language wars as little as you do. I might point out that this was all started by an ADA-ite who kept proselytizing in alt.cobol, despite the expressed wishes of those in this group. I thank you, and so, I'm sure, do other folks who wanna discuss COBOL here - and don't give a fuzzy rat's posterior about whether, or how, ADA may or may not be better. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jay@splut.conmicro.com (eieio)| adequately be explained by stupidity. attctc, RIP. It was nice knowing ya +---------------------------------------- "Flying is a lot more fun than being in the Senate." -- Senator Jake Garn