weyrich@csun1.UUCP (Orville Weyrich) (11/22/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
eugene@eos.UUCP (Eugene Miya) (11/25/88)
> Comments about standardizing inter-language interfaces.
Far more important is to flood the educational market with cheap
compilation systems. DEC's common code generation system and some Pascal
implementations using a FORTRAN reserved word were cited. Far more
important was the availability of a cheap parser to bootstrap later
more portable compilers (the 6400's P1-P4 series of parsers).
Standards tend to be after the fact documents, not blueprints for what should
be (with some notable exceptions). Good decisions iterated carefully
over time make good final products.
Another gross generalization from
--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
resident cynic at the Rock of Ages Home for Retired Hackers:
"Mailers?! HA!", "If my mail does not reach you, please accept my apology."
{uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene
"Send mail, avoid follow-ups. If enough, I'll summarize."ssd@sugar.uu.net (Scott Denham) (11/25/88)
In article <311@csun1.UUCP>, weyrich@csun1.UUCP (Orville Weyrich) writes: > 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. > > DEC demonstrates that this can be done in the VAX/VMS family of programming > languages (although this is a private DEC standard). > > 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 :-). > On the basis of conversations I've had with the language development folks from MY vendor, they'd like nothing better than to be able to do just that. But there are lots of issues, some of them pretty nasty. First, to take an existing environment in which all the languages work differently and move to a common library environment, somebody's got to change. Thats a nasty word around people with lots of "dusty decks" that they don't wnat to have break because sombody changed the way the library works in some subtle way. My understanding is that by starting more or less from scratch, DEC didn't have to worry about this so much with the VAX family. Secondly, there's the issue of "who's the boss here" when you have multiple languages involved - if a run-time error occurs, who takes care of it, and how? What happens when the standard or customary action is different between the two languages (E.G. fixed-point overflow in Fortran vs PLI). Again, a truly common linkage/library system might be able to address this by knowing exactly what sort of routine was in control at the time of the error, but that could get pretty messy, and expensive. Finally, in defining a common linkage convention, you have to allow for all the bells and whistles every language needs, or you have to be able to tell at compile time what sort of module you are linking to. This is likely to have nasty effects on linkage overhead from the standpoint of FORTRAN and C folks who are accustomed to quick, simple, and computationally cheap linkages. (This problem is not strictly a inter-language problem - making F77 and F8x get along will entail similar headaches). Now if we can just get around all that (and the stuff I have no doubt forgotten) we'll be cruisin'. I agree that if the environment worked well, a lot of the "multiple license" arguments would probably go away, and we'd also probably have a lot more professionals proficient in multiple languages. Scott Denham Western Atlas International Houston, TX > > What does the rest of the net think? > > -- > Orville R. Weyrich, Jr. | UUCP : ...gatech!ugacs!csun1!weyrich
smryan@garth.UUCP (Steven Ryan) (11/26/88)
>Some early Pascal compiler writers realized this, and provided a FORTRAN >reserved word for allowing the Pascal programmer to link in FORTRAN libraries. Algol-60 definition (for all compilers) included a "code" procedure body used to indicate external interface. If you want an example of another compiler's willingness to interface, check out the now defunct CDC Algol-5. -- -- s m ryan +-------------------------------+----------------------------------------------+ | Home of the brave and land of | Congress shall make no law respecting the | | [deleted by the authority of | establishment of religion,...; or abridging | | the Official Secrets Act]. | the freedom of speech, or of the press;... | +-------------------------------+----------------------------------------------+
stachour@umn-cs.CS.UMN.EDU (Paul Stachour) (11/29/88)
In article <311@csun1.UUCP> weyrich@csun1.UUCP (Orville Weyrich) writes: >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 :-). Of course we need to be able to call any other language from any other language. But DEC was by no means the first to think about this. GE and MIT, when they built the Multics system, way-back-in-60's, provided that any language could call any other, and even without having to provide any such thing as a "pragma" or other means of saying "I'm calling FORTRAN here from COBOL or PL/I or ...". And the standard they created is still good enough today to handle Ada, even though the HOLWG didn't even exist yet when Multics was done. But, as many of us know, people don't buy reliability, or security, or ease-of-programming. They buy "cheap" and pay through the nose for it again and again and again. For the curious, the Multics conventions are based on passing 1+n+n words as an argument-list, with the "1" telling how many arg-pointers and how many descriptor-pointers there are. The n+n are the arg-pointers and descriptor-pointers. Languages like FORTRAN pass only 1+n, ones like PL/I and Pascal pass 1+n+n, and the inter-language calls from PL/I to FORTRAN are done by FORTRAN ignoring the descriptors. Calls from FORTRAN to PL/I are done by the PL/I code simply not referencing the non-existant descriptors, since nothing could have been passed that needed one! "Computer Science loses its memory, if not its mind, at regular (six month???) intervals. (from ???)" ...Paul