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
mcdonald@uxe.cso.uiuc.edu (11/28/88)
>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). And all the Microsoft languages (Basic, C, Fortran, and Pascal) can easily call each other. >What does the rest of the net think? I think it is a great idea. Unfortunately, when I have proposed it to our member on X3J3, Kurt Hirchert, he has given it the royal cold shoulder. X3J3 at least doesn't want to have anything to do with other languages. They are only interested in making the "perfect" Fortran, in and of itself (*), not in helping the poor user get at other languages, or even those parts of the operating system that aren't covered by the rather limiting Fortran IO system. Both DEC and Microsoft have shown that it can be done - and as best as I can tell both methods would work for either one (except that Microsoft would have to add some way to take care of DEC's hideous "descriptors" - better DEC to rid itself of them). By the way, how is poor F9x? Still in intensive care? Any report, Kurt? Are they ever going to reply to our comments sent in a year ago? Doug McDonald (mcdonald@uiucuxe) * And, given the troubles thay have, that is understandable.
hirchert@uxe.cso.uiuc.edu (11/29/88)
In an earlier article, Doug McDonald (mcdonald@uiucuxe.cso.uiuc.edu) ascribed some positions to me that, unfortunately, weren't accurate, so let me clear the record before I get flamed for things I didn't do or say. 1. Compatible calling conventions for all languages is not within the scope of X3J3 or any of the standards committees for specific languages. There is, however, a separate committee that was investigating this area for possible standardization. I do not know when or if anything will come of this work. 2. Even standardizing the interface between two specific languages is tricky. For example, one might be tempted to say that in calls between Fortran and C, one might be tempted to say that Fortran INTEGERs correspond to C ints. However, Fortran INTEGERs are required to be the same size as REALs, while C ints are expected to be the machines natural word size, so on some machines, this correspondence will not hold. Again, this is not a topic that falls within the scope of standards committee for any single language. 3. What would fall within the scope of X3J3 would be some kind of statement, attribute, or processor directive to indicate that the external procedure one is calling was written in some other language (and thus may have different calling conventions). I have proposed such features for Fortran 8x (in various forms) and have supported proposals made by others, but no such proposal has won majority support from the members of X3J3. There are a number of comments on this issue in the public comment, so I may prepare another proposal for next meeting. (On the other hand, I'm getting married in less than three weeks, so I may be otherwise occupied.) Now, in spite of my strongly supporting the idea of standardizing the communications between languages, I do not see that as reducing the pressure for much of what is in the Fortran 8x draft. Most of the new functionality is not of the sort that can readily be utilized merely by making procedure calls. For example, . I certainly wouldn't find it particularly convenient to have to call another language to execute a CASE statement or construct a non-counting loop. . I would not find acceptable the need to call a procedure to reference dynamic storage, nor would I find acceptable the need to reference every dynamic objects through procedure dummy arguments. (The overhead of the CALLs would kill performance. . When working on machines with vector or parallel architectures, procedure calls are not acceptable as the sole means of accessing these capabilities. In many problems, the overhead would again be a killer. . For obvious reasons, external procedures in other languages are not going to provide the functionality of internal procedures in Fortran. Since the Fortran standard has always provided for the possibility of calling procedures written in other languages, much of the pressure for extension was in areas where this did not work well. Some other random observations . All the good examples of interlanguage communications that I have seen apply to single machine architectures. I suspect it may be an order of magnitude more difficult to define standards for interlanguage communication that make sense across machine architecture boundaries. . It may be politically difficult to get such standards adopted because many vendors may find it necessary to scrap or make major revisions to _all_ their language products, not just those with new standards. Furthermore, their new products, though compatible with each other, may have to be incompatible with their previous products. . There is a big difference, in terms of training costs, between learning to use a new feature in a language you already know and learning a new language to make use of a comparable feature. . Even if you are willing to spend the money, not all languages are available on all machines. For example, there is no Ada compiler for the machine on which I currently program in Fortran. . The question of the cost of supporting multiple languages is not as trivial as some have suggested. If the machine is a central resource, the cost of acquiring another language may well be comparable to the cost of a major upgrade to an existing language, and in many cases this is likely to be a rather small part of the overall budget. On the other hand, when one is dealing with workstations, the cost of supporting an additional language on each of several hundred machines can be much worse than the cost of even a major upgrade of the software already present on those machines, and this cost is likely to be significant relative to the budget for such machines. Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
hirchert@uxe.cso.uiuc.edu (11/29/88)
In my last posting, I forgot to respond to Doug McDonald's request for information about the status of the Fortran 8x work. At the November X3J3 meeting, X3J3 decided to use the recommendations in WG5 resolution P2 as a basis for producing the next draft for Fortran 8x and passed a large number of proposals modifying its draft in that direction. X3J3 did not adopt the WG5 document in its entirety, and some of the proposals adopted are at odds with the WG5 recommendations, but the differences are for the most part in areas where it was perceived that changes would not result in opposition from one of the other nations represented on WG5. X3J3 also accepted a schedule which, if met, would result in the forwarding of a new draft and approval and mailing of responses to all public comments following the May meeting of next year. If none of the other X3J3 members on the net does it sooner, I will try to post a more specific list of approved technical changes later this week. Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (11/30/88)
In article <50500092@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > > ** stuff about interlanguage calling > >>DEC demonstrates that this can be done in the VAX/VMS family of programming >>languages (although this is a private DEC standard). As did UNIVAC, CDC, etc. years before DEC. > >And all the Microsoft languages (Basic, C, Fortran, and Pascal) can >easily call each other. MS has come a long way from the old Z80 days...but back then the documentation said it was easy (and explained how), but actually calling BASIC from FORTRAN from COBOL and similar stunts nearly always failed. Incompatible libraries (MS supplied) were the root cause. > >>What does the rest of the net think? > >I think it is a great idea. Unfortunately, when I have proposed it >to our member on X3J3, Kurt Hirchert, he has given it the royal cold >shoulder. X3J3 at least doesn't want to have anything to do with >other languages. They are only interested in making the "perfect" >Fortran, in and of itself (*), not in helping the poor user get at other >languages, or even those parts of the operating system that >aren't covered by the rather limiting Fortran IO system. I suspect that Kurt and crew DO care. The problem is that it is not an X3J3 issue. If someone wants to set up a committee for interlanguage issues, which will then interface with the language committees I'm sure something could be worked out. At this point the technical (what objects are "basic" how should they be handled ? etc.) issues are non-trivial, and the political ones are really pretty big (it is hard to get agreement JUST on a language ... much less get committees of comittess to agree). Ultimate we can hope/expect this evolution, but computers are still pretty young. > Both DEC >and Microsoft have shown that it can be done - and as best as I can >tell both methods would work for either one (except that Microsoft >would have to add some way to take care of DEC's hideous "descriptors" - >better DEC to rid itself of them). Your examples "prove" that a single vendor can do it (btw: dec's descriptors are quite useful for resolving interlingual issues, better MS adopt the dec solution) but given the total non-portability this introduces into your code is this really a good idea ? > >By the way, how is poor F9x? Still in intensive care? Any report, Kurt? >Are they ever going to reply to our comments sent in a year ago? There have been numerous postings about F88 over the last few months. WG5 has ordained it, subject to some modest changes. Since WG5 voted to accept the existing document (modulo changes) this year, it chose to call the standard by this years handle. So we have a new international standard. The american standard will lag a bit (counter-intuitive, since x3j3 wrote the document WG5 accepted ... but that's the way it goes). Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus