Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!sun!chiba!khb From: khb%chiba@Sun.COM (Keith Bierman - SPD Languages Marketing -- MTS) Newsgroups: comp.lang.fortran Subject: Re: Responses to M. Shapiro & K. Bierma Message-ID: <100922@sun.Eng.Sun.COM> Date: 25 Apr 89 02:55:33 GMT References: <24091@beta.lanl.gov> <44400037@hcx2> Sender: news@sun.Eng.Sun.COM Reply-To: khb@sun.UUCP (Keith Bierman - SPD Languages Marketing -- MTS) Organization: Sun Microsystems, Mountain View Lines: 60 In article <50500124@uxe.cso.uiuc.edu> it is written: > >As to your second sentence first, it appears that right now, after some >changes, that it is proposed to keep all of Fortran 77. HOWEVER, >in the draft that was sent out for comment, it was proposed that >all of Fortran 77 would be in F8x BUT that one would have had to >assume that a long list of things (like common, equivalence, and >ordinary do loops(!)) would disappear from F9x. No. What had been proposed was that certain features be labeled as CANDIATES for eventual removeal. The most aggressive schedule would be marked in f8x, moved to a seperate heap in f9x, and possibly deleted for real in f20xx. Since the actions of the current committee do not bind the future committees this could still happen, but without the extra decade of warning and debate (but it will be much harder for some features, because they have been closely integrated in with new features.. which would have been "cleaner" without the old baggage). Furthermore it was simply not possible for the current committee to ensure that the future committees would have _ever_ done the actual deletion. > >The problem with a gigantic language is that if one wants to write >efficient programs, one MUST understand not only the syntax of the >whole language, but also the relative efficiency of doing things >in different ways. It is just not realistic to propose that people >understand or use a subset. In fact, most people do just that. Once the efficient ways become known, and probably published in books by clever folks (say, for example, Metcalf, Brainard, Wagoner) many people will never learn all the sub-optimal ways one _could_ code. The reason that some folks argued for labeling things for eventual deletion is that there was/is a feeling that the "language is too large". One way to make is smaller is to leave out (arguably) needed features. Another is to remove old disused features. What seems to have upset many people is that features marked as _eventually_ removeable are currently in heavy use....but if the original schedule was followed the "dirty deed" would be a good thirty years off... now how many of us have codes which have NEVER been modified since 1959 ? Cheers. -- Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *) Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *)