weyrich@ugacs.UUCP (Orville Weyrich) (11/25/88)
In article <395@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: > However you slice it, COBOL->C conversion still smells like baloney to me! ........ > Algol-type languages are neat for certain computer-science stuff, and > COBOL is OK for routine commercial programs. > So why translate? > Commercial companies cannot hire enough competent programmers to let them >switch to more "advanced" languages, so, until 4GLs or AI techniques help them >make do with fewer programmers, they probably should keep using COBOL. > My point was not that one language is better than another, but that I feel >it is usually silly to translate programs from a language into another that is >_very_ different from the first. Rewrites may well be cheaper! >-- >Bill Hutchison, DP Consultant rutgers!cbmvax!burdvax!ubbpc!wgh I think that this discussion points out a neglected aspect of programming language development and language standardization: defining standard and useful interfaces *between* languages, so that for example new code in modern languages can be smoothly integrated into old programs written in old languages without the need for massive rewrites. Some early Pascal compiler writers realized this, and provided a FORTRAN reserved word for allowing the Pascal programmer to link in FORTRAN libraries. DEC demonstrates that this can be done in the VAX/VMS family of programming languages (although this is a private DEC standard). It *must* be easier, faster, and more cost-effective to define linkage between say FORTRAN and Ada than it is to redefine FORTRAN to have most of the features of Ada (as is being done by the 8X committee). Of course, such a proposal is not expected to be greeted with a warm welcome by certain mainframe manufactures who have trouble getting their own standard linkage conventions standardized :-), or those who have separate and incompatible runtime libraries for each language :-), or those who do not have language-independent code generators :-). The pseudo-issue of the cost of licensing multiple compilers for a single job shop seems to be easily defeated: 1) If in order to meet a new language standard, most of the existing compiler must be discarded and rewritten, the user *will* pay royally because it *does* cost the manufacturers big bucks. 2) Given that at least some manufacturers have compatible runtime libraries and language-independent code generators for languages like FORTRAN-77 and Ada, it would cost very little to conform to new standards which were restricted primarily to elaborating a standard interface between the existing languages. Manufacturers with this capability would be able to improve their market share by passing on their savings, while certain others would be stuck doing major surgery to get their products working together (comparable in effort to a total rewrite of both language compilers?) (this looks like a real political hot potato! :-( ). What does the rest of the net think? Post followups to comp.lang.misc. -- Orville R. Weyrich, Jr. | UUCP : ...gatech!ugacs!csun1!weyrich Department of Computer Science | University of Georgia | Athens, GA 30602 USA | MA BELL : (404) 542-1082
wgh@ubbpc.UUCP (William G. Hutchison) (11/30/88)
In article <479@ugacs.UUCP>, weyrich@ugacs.UUCP (Orville Weyrich) writes: > In article <395@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: > > ... > >it is usually silly to translate programs from a language into another that's > >_very_ different from the first. Rewrites may well be cheaper! > >-- > >Bill Hutchison, DP Consultant rutgers!cbmvax!burdvax!ubbpc!wgh > > I think that this discussion points out a neglected aspect of programming > language development and language standardization: defining standard and > useful interfaces *between* languages, so that for example new code in modern > languages can be smoothly integrated into old programs in old languages > without the need for massive rewrites. > > What does the rest of the net think? This part of the net thinks you have brought up a good point. Here at the Unisys Portation Center we keep having trouble with programs that call C from COBOL or whatever. This is a can of worms that standards writers have ignored, probably because it is such a mess. I do not have a good solution yet, but, in the spirit of Computer Science, I want to propose a Paradigm: Inter-language data passing might be specified in a manner like the GKS graphics standard Language Bindings. E.G. the ANSI COBOL standard could have an appendix about the data types that could be passed to C, FORTRAN, etc. and details about pass by reference, etc. Let us not be deterred by the fact that it may not be feasible! A small step in that direction is section 3F of the UNIX programmers manual which specifies connections between FORTRAN code and UNIX library routines. Here is another way out, for those who eventually get UN*X System V release 4: do all inter-language calls using RPC (remote procedure call), then the data types and calling sequences would be required to be in XDR (eXternal Data Representation) format. Each language developer would have to provide RPC and XDR wrapper functions for their utility, library, and I/O routines. But they will have to do that anyway to support Release 4, no? Do we see light at the proverbial end of the proverbial tunnel here? -- Bill Hutchison, DP Consultant rutgers!liberty!burdvax!ubbpc!wgh Unisys UNIX Portation Center "What one fool can do, another can!" P.O. Box 500, M.S. B121 Ancient Simian Proverb, quoted by Blue Bell, PA 19424 Sylvanus P. Thompson, in _Calculus Made Easy_