doon@unrvax.UUCP (10/27/87)
Hi, I've heard that Fortran-88 is about to debut. Could somebody tell me about this new-and-improved Fortran or where I may read about it? Thanks, Harry Reed doon@unrvax
jkw@a.UUCP (Jay Wooten) (10/28/87)
In article <780@unrvax.UUCP>, doon@unrvax.UUCP (Harry W Reed) writes: > > Hi, > I've heard that Fortran-88 is about to debut. Could somebody > tell me about this new-and-improved Fortran or where I may read about it? The FORTRAN 8X proposed standard has been in the works for several years and is still far from approval by ANSI, much less available as a real compiler from any vendor. Many vendors oppose the latest 8X proposal because it is a major change (33 new statements, 14 "decremented" statements). Some say that it really is a new language because it is so far removed from F77. For more info on the debate and f8X's current status, see pp. 22-28 of the October 15 DATAMATION magazine. Probably about as close to F8X as you'll come for a while is the VMS FORTRAN compiler which has many extensions which are similar to some of those proposed for 8X. Jay Wooten Los Alamos National Lab ARPA: jkw@lanl.gov
cdb@hpclcdb.HP.COM (11/04/87)
Please see my reply to the basenote by bct@its63b for all the details and options I know for joining th public review. Carl Burch hplabs!hpda!cdb
brainerd@unmvax.unm.edu (Walt Brainerd) (10/18/88)
Another point I forgot to mention previously (the significance of which you can puzzle over for yourself) in response to someone who noted that the Europeans seem to represent the consumer viewpoint more than X3J3: The document favored by ISO/WG5 was put into its final form by five people on X3J3 who all represent users; the hardest opposition is coming from some of the vendors.
psmith@mozart.uucp (Presley Smith) (10/19/88)
In article <2045@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: Let us explore this a bit: >Another point I forgot to mention previously (the significance of which >you can puzzle over for yourself) in response to someone who noted that >the Europeans seem to represent the consumer viewpoint more than X3J3: I don't believe that the European's public comment represent the consumer viewpoint any more than the U.S. public comments represents the consumer viewpoint. What are the facts... 1. The Europeans were invited to a series of "FORTRAN Forums." These Forums presented the positive side of the FORTRAN 8x standard and pumped up the users to respond to "get the standard out...without delay." There are many of these comments in the European response. In fact, I could list the particular comment numbers here, but I will not. I don't believe that any of these Forums discussed the information that was presented in the Steve Rowan's article that was posted on the net today, also. I don't believe these Forums discussed that FORTRAN 8x is actually bigger than Ada, that with depedent compilation, compilers will run much slower, and that implementation of some of the new constructs of FORTRAN 8x would cause major compiler efforts because they don't fit really well with the old FORTRAN construncts. I'll bet that not a one of these Forums discussed the amount of time it took to get FORTRAN 77 implemented on the majority of the machines in the world and how much more complex FORTRAN 8x is to implement. 2. In the U.S. various groups received a more balanced set of information. Presentations presented the new features, benefits of each, and the drawbacks of each. Discussions did not center around the "beauty" of the "modern FORTRAN" language, but around how it would help the user and how it would hurt the user. In the U.S. we also discussed how it would be more complex for an engineer to pick up this 8x language quickly (one would need a better computer science background...) and issues of sustaining programs that were created with a mixture of FORTRAN 77 and FORTRAN 8x constructs... In Europe, many of the presenters of the Forums were users that were in favor of making FORTRAN a "modern language" that would "compete" with other languages like Ada and Pascal. In the U.S. most presentations were made by the Vendors. The ones that must support the FORTRAN user base and provide quality products for their use. It seems strange that the major vendors: IBM, DEC, and UNISYS all said "NO" to FORTRAN 8x. Has anyone really looked at the why? It's spelled out in their ballot comments on FORTRAN 8x, but many tend to ignore those and claim that the vendors just don't want to implement a new FORTRAN. Take a look at those ballot comments... >The document favored by ISO/WG5 was put into its final form by five >people on X3J3 who all represent users; the hardest opposition is >coming from some of the vendors. Your are right, the hardest opposition is coming from the vendors. They believe that FORTRAN 8x is too big, too complex, has too many "neat" things that are not needed or wanted by their user base. They also understand that it will take years to produce quality FORTRAN compilers for a standard this complex. It's real simple. If you don't get the vendors to sign up to producing compilers and supporting those compilers, NO new standard will be successful. It's ALGOL 68 again. A beautiful language that none of the major vendors implemented. That could have a lot to do with why we are still programming in FORTRAN and not ALGOL 68. The other problem with this statement is that "five people on X3J3" put together this ISO/WG5 document from documents that had NOT been accepted by X3J3 at the last X3J3 meeting as being acceptable for a base document for the new FORTRAN standard. In fact, the delegation from X3J3 to the WG5 meeting was directed by X3J3 NOT to support this document as a base for the new FORTRAN standard. And now "five people on X3J3" are putting this document, that was rejected at the last X3J3 meeting, into final form. I don't believe this "five people on X3J3" have been operating on the instructions of X3J3 to produce this document. From the votes at the last X3J3 meeting and the direction from X3, it is unclear that X3J3 or X3 would authorize this work. One other thing to note. ANY document given to any ISO/SC/WG organization must be passed throughper the procedures sified in the SD-2. up, p If this document is not processed properly, major internation problems may result.
metzger@mozart.uucp (Bob Metzger) (10/19/88)
DISCLAIMER: These are my opinions, not my employers. I found Mr. Brainerd's most recent postings highly amusing. He seems to think that dragging the FORTRAN 8x discussions down to the level of the US Presidential elections is his only hope of rescuing his draft (he is the editor of the FORTRAN 8x draft that the U.S. public comment rejected.) There's a future for you in political advertising, Mr. Brainerd. For example, this assertion that the "Gang of 5" that wrote the current draft are "users". You know as well as I that they are mostly, like yourself, actually Ph.D. computer scientists. I think it is safe to assert that if there is any class of programmers who are not typical FORTRAN users, it is Ph.D. computer scientists. Engineers and physical scientists are the real FORTRAN users. Or how about the assertion that it is the vendors, not the users, who oppose your draft, Mr Brainerd? How do you explain the fact that the revision proposal that got the largest number of votes in August, and is the one that the majority of the vendors support, is written by a mathematician from Boeing? A real non-computer scientist who doesn't work for a computer vendor. Sounds like a real FORTRAN user to me! And why do you think that all those vendors oppose the current draft, Mr. Brainerd? Because the vendors employ people who have actually implemented production quality compilers, and who know that this language, which is certainly not FORTRAN, is a recipe for disaster. I realize that you doubt the value of the hundreds of years of compiler development experience represented by the nearly 2 dozen organizations that oppose the current draft. Compiler experts from such fierce competitors as IBM and DEC and UNISYS all agree that the current draft is not acceptable. The FORTRAN user community would do well to realize that such concerted opposition could only occur if there were real technical flaws in the current draft. Yes, there's a future for you in political advertising, Mr. Brainerd. DISCLAIMER: These are my opinions, not my employers.
bobal@microsoft.UUCP (Bob Allison) (10/19/88)
[Walt wrote in note previous to the one referenced:] >Two points have been overlooked in the recent discussion of the happenings >in the wonderful world of Fortran standards: > >1. X3J3 is "tasked" by WG5 of ISO to create the ISO standard. This may be true, but it doesn't seem to have any procedural significance: witness the X3 direction to X3J3. Also, the private discussion with an X3 member who asserted that if WG-5 tried to take the current draft and use it without going through X3J3 that X3 would move to defend its ownership of the document (I guess through copyright) by whatever means are necessary. > >2. There is only one document that is close enough to be a standard > in the next five years; it is the one favored by ISO/WG5. So the choices > are: a) the same ISO and ANSI standard or > b) an ISO standard and _no_ ANSI standard (at least not for several years). I don't buy this for an instant: I don't understand what "could be" means, but certainly the draft sent for public review, the original FORTRAN 77 text, and dozens of other permutations "could be a standard in the next five years". Given five years (your number above) I believe any standard is possible. > >Also, from what I have heard, it is quite likely that any ISO standard >would become a U. S. Federal (FIP) standard whether it is an American >national standard or not, so vendors wanting to sell to Uncle Sam would >have to implement it. I don't think this is predictable at this time. The FIPS process is completely independent and also has review cycles. I believe either conclusion can be argued with the same confidence (namely, none). In article <2045@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: >Another point I forgot to mention previously (the significance of which >you can puzzle over for yourself) in response to someone who noted that >the Europeans seem to represent the consumer viewpoint more than X3J3: > >The document favored by ISO/WG5 was put into its final form by five >people on X3J3 who all represent users; the hardest opposition is >coming from some of the vendors. Well, I find this an over-simplification: there is some pretty strong resistance from Boeing, SHARE (the IBM users group), and (starting next meeting) DECUS. There are vendors in favor of the ISO/WG5 document and other users opposed. This whole users/vendors thing is just jingoism. At the last meeting, the document closest to ISO/WG5 went down 11-20-7, and 11-24-5 depending on the time of week. I do not believe there were 24 people representing vendors and only 11 representing users in the room. These things are not so clear cut as some would have you believe: I know that (contrary to the votes of members of the committee from the same organizations) employees wrote in public review letters against the draft from Amoco and NCAR, and in favor of the draft from employees of Boeing and users of IBM machines. In the end result, the votes come down to who is voting: we have seen organizations change votes when a new person came along from that organization. This is especially true of "vendors" (so I guess the companies' brainwashing methods have not been perfected yet ;-). Bob Allison PS. I was gone for a week, so I only saw two responses to my note about 8X pointers (one about double colons, one about "=>" being only one character different from "="). Any I missed? Everyone pretty happy with this proposal?
link@stew.ssl.berkeley.edu (Richard Link) (10/20/88)
In article <660@convex.UUCP> metzger@mozart.UUCP (Bob Metzger) writes: > >For example, this assertion that the "Gang of 5" that wrote the >current draft are "users". You know as well as I that they are mostly, >like yourself, actually Ph.D. computer scientists. I think it is safe >to assert that if there is any class of programmers who are not typical >FORTRAN users, it is Ph.D. computer scientists. Engineers and >physical scientists are the real FORTRAN users. I agree !!!!! *MY* biggest problem with F88 is that it looks like FORTRAN was hijacked by a bunch of academic Pascal/C advocates who insist on turning it into an all-purpose language, instead of the efficient number cruncher it was designed to be. I get the impression that the committee members did not learn FORTRAN as their first language. Hence, the bias towards incorporating "modern", but totally unnecessary, constructs into the draft standard. We've already got Pascal, Modula-2, Ada, and C. There is no need to re-invent these languages. My background is in the development of complex numerical models for the analysis and interpretation of space physics data. I taught FORTRAN for 5 years, and ALGOL (!) for 2. If you can give me a better number cruncher, then I'm all in favor. However, I see little to recommend in the new draft standard. In our laboratory, we select the best language available for the job at hand. Our satellite control functions are coded in C, but the scientific analysis programs are in FORTRAN. As it stands, I think that the proposed draft standard will meet with the same success as ALGOL-68 and PL/1. To ANSI committee members: Go think about it for a while, and come back when you have a language called FORTRAN. Dr. Richard Link Space Sciences Laboratory University of California, Berkeley link@ssl.berkeley.edu
mcdonald@uxe.cso.uiuc.edu (10/20/88)
>Another point I forgot to mention previously (the significance of which >you can puzzle over for yourself) in response to someone who noted that >the Europeans seem to represent the consumer viewpoint more than X3J3: It certainly looked to me from the list of about 400 responses that was posted on the net that the "consumers" from the US were more opposed than for. The European responses constituted the core of the yes votes. I don't see how Europeans should expect their "votes", if you can call them that, should count at all for a US standard.
hirchert@uxe.cso.uiuc.edu (10/21/88)
Presley Simith(psmith@mozart.uucp) writes: >I don't believe that the European's public comment represent the consumer >viewpoint any more than the U.S. public comments represents the consumer >viewpoint. What are the facts... >1. The Europeans were invited to a series of "FORTRAN Forums." These >Forums presented the positive side of the FORTRAN 8x standard and pumped >up the users to respond to "get the standard out...without delay." There >are many of these comments in the European response. In fact, I could >list the particular comment numbers here, but I will not. and, as you note later, most U.S. commenters got their information from presentations made by vendors opposed to the draft. Because of ISO rules, the European presentations were allowed to give attendees copies of the draft. Because of X3/CBEMA rules, attendees of U.S. presentations had to order theirs from Global Engineering. Many either chose not to because of cost or received their copies from Global Engineering so late that they did not have time to adequately review them, so they simply echoed what was presented to them. (I, too, could list particular comment numbers.) Do you really to argue that people that had copies of the draft are less representative than those who did not? > ... I don't believe these Forums discussed that FORTRAN 8x >is actually bigger than Ada, The measures that call Fortran 8x bigger than Ada also call FORTRAN 77 about the same size as Ada. I find such measures less than convincing. > that with depedent compilation, compilers >will run much slower, IMHO, anyone who writes a compiler that is slower because of dependent compilation is probably less than competent. I have access to a number of compilers and assemblers with similar features, and every one of them runs substantially faster with these features used than without them. (More subjectively, I find there performance when these features are not used to be comparable to that of processors that didn't have the features in the first place.) > and that implementation of some of the new >constructs of FORTRAN 8x would cause major compiler efforts because >they don't fit really well with the old FORTRAN construncts. This is one of those generalizations I keep hearing without supporting specifics. Which features do you have in mind? How is it that they don't fit with the old constructs? How will this cause major compiler efforts? (The major compiler effort that is most obvious to me is the optimization of array expression evaluation, but most of the people I know opposed to the Fortran 8x draft still support the array language.) > I'll bet >that not a one of these Forums discussed the amount of time it took >to get FORTRAN 77 implemented on the majority of the machines in the >world and how much more complex FORTRAN 8x is to implement. and I'll bet that the U.S. presentations didn't talk about how unrepresentative it is to consider the implementation time for many of those FORTRAN 77 implementations. (Many vendors took FORTRAN 77 as an opportunity to write new compilers based on new compiler technology (e.g., writing in HLL's rather than assembler, using common back-ends for code generation, using automatically generated parsers, etc. On the other hand, vendors seem inclined to implement Fortran 8x as extensions to their existing products. Indeed, many have already implemented large parts of 8x in precisely this manner.) >2. In the U.S. various groups received a more balanced set of >information. Presentations presented the new features, benefits >of each, and the drawbacks of each. Discussions did not center >around the "beauty" of the "modern FORTRAN" language, but around >how it would help the user and how it would hurt the user. In >the U.S. we also discussed how it would be more complex for an >engineer to pick up this 8x language quickly (one would need a >better computer science background...) and issues of sustaining >programs that were created with a mixture of FORTRAN 77 and >FORTRAN 8x constructs... My impression of many of the U.S. presentations is that they presented minor "straw man" benefits of many of the new features (ignoring benefits I would consider far more important), and then attacked them with "facts" that I find highly questionable. In my experience, the measure of a balanced presentation is that both sides think it was biased towards the other side. I don't see that the U.S. presentations met this criterion any better than the European presentations. (I.e., presentations on both sides of the Atlantic tended to reflect the biases of the presenters.) >In Europe, many of the presenters of the Forums were users that >were in favor of making FORTRAN a "modern language" that would >"compete" with other languages like Ada and Pascal. >In the U.S. most presentations were made by the Vendors. The >ones that must support the FORTRAN user base and provide quality >products for their use. It seems strange that the major >vendors: IBM, DEC, and UNISYS all said "NO" to FORTRAN 8x. >Has anyone really looked at the why? I sure have. I happen not to agree with many of their technical arguments and assertions. (Unfortunately, for two of the above three, I find political or tactical motives to be a better predictor of their positions than technical considerations. I still listen to their technical arguments carefully, but I take them with a grain of salt, especially when they involve unsupported assertions.) > It's spelled out in their >ballot comments on FORTRAN 8x, but many tend to ignore those >and claim that the vendors just don't want to implement a >new FORTRAN. Take a look at those ballot comments... >>The document favored by ISO/WG5 was put into its final form by five >>people on X3J3 who all represent users; the hardest opposition is >>coming from some of the vendors. >Your are right, the hardest opposition is coming from the vendors. >They believe that FORTRAN 8x is too big, too complex, has too many >"neat" things that are not needed or wanted by their user base. >They also understand that it will take years to produce quality >FORTRAN compilers for a standard this complex. There is substantial disagreement about what the user base wants and needs; it depends a lot on how you ask the question and how you interpret the answer. Is it better to wait 5 years for a compiler with all the features you want or to get some of them in 3 years and then wait another 10 years for the rest (if your're lucky)? If you are certain you don't really need the features in the second batch, 3 years is clearly better than 5. If you are certain you need features in the second batch, 5 years is clearly a lot better than 13. If you're uncertain, you'll have to judge for yourself. >It's real simple. If you don't get the vendors to sign up to >producing compilers and supporting those compilers, NO new standard >will be successful. It's ALGOL 68 again. A beautiful language >that none of the major vendors implemented. That could have a >lot to do with why we are still programming in FORTRAN and not >ALGOL 68. Then again, the fact that no existing programs would run in the new language may have had something to do with why there wasn't enough demand to get the major vendors to do good implementations of Algol 68. (Several of the major vendors did implementations, but typically they weren't very impressive.) Fortran 8x is designed to support the existing base of programs as well as offer new features to the Fortran community. >The other problem with this statement is that "five people on X3J3" >put together this ISO/WG5 document from documents that had NOT been >accepted by X3J3 at the last X3J3 meeting as being acceptable for a base >document for the new FORTRAN standard. In fact, the delegation from X3J3 >to the WG5 meeting was directed by X3J3 NOT to support this document >as a base for the new FORTRAN standard. That's not the way I remember it. First of all, there was no "X3J3 delegation". X3J3 instructed the U.S. delegation, all of whose members were also members of X3J3. X3J3 had no authority to instruct those X3J3 members who were part of non-U.S. delegations. Second, the instruction was not to present the ABMSW plan and to avoid a situation in which WG5 took the job of producing the international standard away from X3J3. As I read the meeting reports, these instructions were followed. The ABMSW plan was presented by a member of one of the other delegations, and WG5 left the job of producing the international standard in X3J3's hands but gave X3J3 more explicit instructions about what it wants the international standard to contain. The ball is now in X3J3's court to decide whether there can be one standard for both ISO and ANSI. > And now "five people on >X3J3" are putting this document, that was rejected at the last X3J3 >meeting, into final form. I don't believe this "five people on X3J3" >have been operating on the instructions of X3J3 to produce this document. >From the votes at the last X3J3 meeting and the direction from X3, it >is unclear that X3J3 or X3 would authorize this work. Come on now. X3J3 members are free, as individuals, to work on whatever they choose. It didn't X3J3 or X3 authorization for you and I to produce these Usenet articles. Given the position of WG5, it is not unreasonable for these people to do work to show X3J3 what an implememtation of the WG5 instructions might look like. What, if anything, X3J3 does with this work is another issue entirely. That is where X3J3 votes, X3 authorizations, etc. come into play. >One other thing to note. ANY document given to any ISO/SC/WG organization >must be passed throughper the procedures sified in the SD-2. up, p >If this document is not processed properly, major internation >problems may result. Maybe, and then again, maybe not. The Hague agreement is no longer in effect, so ISO standards no longer have to be developed by national standards bodies. Working documents of committees following ANSI procedures are required to be in the public domain (except for the standard itself). If X3J3 were to produce a working document reflecting WG5's instructions, X3J3 might not be able to "give" it to WG5, but there would be nothing wrong with WG5 "taking" it as the basis for an ISO standard. (Having said this, let me also say that I would prefer that this not be the way things happen.) Finally, let me make a couple of comments not directly in response to Presley's. In the U.S., the trade press has tended to cover Fortran standardization only when X3J3 produced a draft or report or when X3J3 had major internal disagreements. In Europe, on the other hand, there has been a great deal of continuing coverage. Also, most of the ISO delegates have been involved in Fortran standardization for many years, while a large part of the X3J3 membership (especially among those opposed to the Fortran 8x draft) who joined within the last couple of years. Is it possible then that the greater acceptance of the Fortran 8x draft outside the U.S. (and by WG5, in particular) might be a result of long-term familiarity with its contents, reducing the "fear of the unknown" factor and providing a greater opportunity to assess and appreciate the benefits as well as the costs of the new features. Regardless of its cause, I think we have to deal with WG5's position as it is. Trying to ignore it by characterizing it as unimportant or unrepresentative is just as much a cop out as ignoring the negative comments from the U.S. Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
ssd@sugar.uu.net (Scott Denham) (10/21/88)
In article <15744@agate.BERKELEY.EDU>, link@stew.ssl.berkeley.edu (Richard Link) writes: > *MY* biggest problem with F88 is that it looks like FORTRAN was > hijacked by a bunch of academic Pascal/C advocates who insist on > turning it into an all-purpose language, instead of the efficient > number cruncher it was designed to be. > Now I'm certainly not defending the 8x standard as it exists today, but I do think that FORTRAN needs to become more of an "all-purpose" language than it is in it's present form, if it is to survive. Consider the dilemma the company I work for faces : We have two "types" of FORTRAN coders - researchers, who are trying to invent and refine new whiz-bang techniques to find oil, and development programmers, who are attempting to incorporate the good ideas of these researchers into stable, efficient, user-friendly, veratile code (for the most part, the researcher's code is none of these things). These code segments must be merged into a much larger system that requires a lot of "computer scientist" sort of tricks (E.G. pointers, dynamic arrays, etc). We currently do all of this in FORTRAN, but only through severe abuse of the published standard. In this form, FORTRAN can hardly be considered portable. So we need a language that is acceptable to the researchers, but allows us to build the whole system without making it so machine-dependent that we are trapped to a specific hardware platform. A FORTAN 8X-like language would go a long way towards solving this problem. Sure, we could try to convert the whole thing to "C", but that would involve retraining about 95% of the people that have to work with the code. Clearly, a more "modern" FORTRAN is the answer. FORTRAN 66 was great, until the underlying systems got more complex and the expectations of the end user got higher (E.G. decent looking reports - much assisted by F77). So the "if it ain't broke, don't fix it" argument doesn't carry very far with us. On the other hand, making it so complex that it would be SIMPLER to convert it to "C" or (gasp) ADA is certainly no solution either. FORTRAN needs to grow up some. > > To ANSI committee members: Go think about it for a while, and come back > when you have a language called FORTRAN. > > Dr. Richard Link RIGHT!! Just be sure it's not still called FORTRAN 77 !! Scott Denham Western Atlas International Houston, TX The opinions experess herein are my own; my employer's only opinion is that they have no opinion.
link@stew.ssl.berkeley.edu (Richard Link) (10/21/88)
In article <2870@sugar.uu.net> ssd@sugar.uu.net (Scott Denham) writes: >In article <15744@agate.BERKELEY.EDU>, link@stew.ssl.berkeley.edu (Richard Link) writes: >> *MY* biggest problem with F88 is that it looks like FORTRAN was >> hijacked by a bunch of academic Pascal/C advocates who insist on >> turning it into an all-purpose language, instead of the efficient >> number cruncher it was designed to be. >> >Now I'm certainly not defending the 8x standard as it exists today, but >I do think that FORTRAN needs to become more of an "all-purpose" language >than it is in it's present form, if it is to survive. Consider the >dilemma the company I work for faces : We have two "types" of FORTRAN >coders - researchers, who are trying to invent and refine new whiz-bang >techniques to find oil, and development programmers, who are attempting to >incorporate the good ideas of these researchers into stable, efficient, >user-friendly, veratile code (for the most part, the researcher's code is >none of these things). I did not mean to imply that FORTRAN cannot be greatly improved. What I am concerned about is changing the *scope* of the language - from something that does a few things well, to something that does a lot of things less well. There are penalties for increasing the size of the language. My central argument has not been challenged - one should use the best tool for the job at hand. Why does your programming staff bend F77 rules, when there are other languages like C that could probably do those kinds of jobs much better? I guess I don't understand the rationale behind your company using a language not suited for the application. This may be more of a management error, rather than a FORTRAN shortcoming. Dr. Richard Link Space Sciences Laboratory University of California, Berkeley link@ssl.berkeley.edu
ssd@sugar.uu.net (Scott Denham) (10/21/88)
In article <15776@agate.BERKELEY.EDU>, link@stew.ssl.berkeley.edu (Richard Link) writes: > > I did not mean to imply that FORTRAN cannot be greatly improved. What I > am concerned about is changing the *scope* of the language - from > something that does a few things well, to something that does a lot of > things less well. There are penalties for increasing the size of the > language. No, I didn't think you meant Fortran couldn't be improved (though I have spoken with folks who think F77 is perfect and should be frozen for eternity!). And FORTRAN should certainly NOT be extended to try to do everything well; I have no desire to write another payroll program in FORTRAN, and we don't need another PL/I. The point I was trying to make is that as the underlying systems get more complex, FORTRAN will have to be able to do MORE things well to continue to be as useful as it has been. > > My central argument has not been challenged - one should use the > best tool for the job at hand. Why does your programming staff bend > F77 rules, when there are other languages like C that could probably > do those kinds of jobs much better? I guess I don't understand the > rationale behind your company using a language not suited for the > application. This may be more of a management error, rather than a > FORTRAN shortcoming. > AH, but for the most part, FORTRAN is VERY well suited to the application; I'm sure something like 99% of the code in our industry has been written in FORTRAN, and I don't see that changing much. There are just some things that are not so simple in FORTRAN 77 without breaking rules - and virtually every commercial user I have discussed this with confesses to using the same "tricks" for things like: Dynamic sizing of arrays/Dynamic aquisition of storage. Variable length calling sequences. Structures of mixed type, or having to handle varying data representeation As far as management policy goes, there are lots of good reasons to try to mimimize the number of languages in use; there's always one or two applications that work better in another language, but then you are "stuck" with it; we were burned by PL/I this way when one guy was allowed to go off and develop a sizable system in it. He's long gone and nobody else wants anything to do with PL/I - and if a site wants to run that one application, they have to shell out something on the order of $500 a month for a PL/I license. Consider also the cost of training, manuals, and support tools, and the problems of having to support this code in a number of data centers around the world. The cost is NOT small. And as a last point, some vendors (though I'd never mention IBM by name) do an absolutly LOUSY job of integrating their language products; the thought of trying to get say "C", FORTRAN, and ADA modules linked up and cooperating without their run-time libraries getting into a major war curls my hair!! > Dr. Richard Link > Space Sciences Laboratory > University of California, Berkeley > link@ssl.berkeley.edu Scott Denham Western Atlas International
cik@l.cc.purdue.edu (Herman Rubin) (10/21/88)
In article <15776@agate.BERKELEY.EDU>, link@stew.ssl.berkeley.edu (Richard Link) writes: > In article <2870@sugar.uu.net> ssd@sugar.uu.net (Scott Denham) writes: > >In article <15744@agate.BERKELEY.EDU>, link@stew.ssl.berkeley.edu (Richard Link) writes: > >> *MY* biggest problem with F88 is that it looks like FORTRAN was > >> hijacked by a bunch of academic Pascal/C advocates who insist on > >> turning it into an all-purpose language, instead of the efficient > >> number cruncher it was designed to be. > >> > >Now I'm certainly not defending the 8x standard as it exists today, but > >I do think that FORTRAN needs to become more of an "all-purpose" language > >than it is in it's present form, if it is to survive. Consider the > >dilemma the company I work for faces : We have two "types" of FORTRAN > >coders - researchers, who are trying to invent and refine new whiz-bang > >techniques to find oil, and development programmers, who are attempting to > >incorporate the good ideas of these researchers into stable, efficient, > >user-friendly, veratile code (for the most part, the researcher's code is > >none of these things). > > I did not mean to imply that FORTRAN cannot be greatly improved. What I > am concerned about is changing the *scope* of the language - from > something that does a few things well, to something that does a lot of > things less well. There are penalties for increasing the size of the > language. I find C, with all its disadvantages, better than Fortran because of all the things not present in Fortran. I believe that some of them are addressed in Fortran 8x, but probably not enough. For good programming, it is necessary to have a versatile language. Costs of subroutine calls are high. It is clearly impossible to write one line of code in Fortran and the next line in C. C has left too much out, also. The only penalties for increasing the size of the language are the size, and to a lesser extent the speed, of the compiler. If you are producing a non- trivial program, these costs are likely to be irrelevant. It also may be necessary to explicitly type all variables, instead of using default types. Many source programs already do this to avoid errors. All of the present languages deny the programmer the power of the machine. If execution time is at all important, this is criminal. Machine structure is simpler than Fortran (any machine). Of course, some things will be non- portable. This is not the catastrophe that some may think. A few comments can explain why the non-portable parts are and what they do. If they only constitute a small part of the program, the problems will not be great. However, the portable problems arising out of the deficiencies of Fortran are great, and should be addressed. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)
tsh@mace.cc.purdue.edu (Greg Kamer) (10/21/88)
Article 779 of comp.lang.fortran: In article <2870@sugar.uu.net> ssd@sugar.uu.net (Scott Denham) writes: >In article <15744@agate.BERKELEY.EDU>, link@stew.ssl.berkeley.edu (Richard Link) writes: >> *MY* biggest problem with F88 is that it looks like FORTRAN was >> hijacked by a bunch of academic Pascal/C advocates who insist on >> turning it into an all-purpose language, instead of the efficient >> number cruncher it was designed to be. >> >Now I'm certainly not defending the 8x standard as it exists today, but >I do think that FORTRAN needs to become more of an "all-purpose" language >than it is in it's present form, if it is to survive. Consider the >dilemma the company I work for faces : We have two "types" of FORTRAN >coders - researchers, who are trying to invent and refine new whiz-bang >techniques to find oil, and development programmers, who are attempting to >incorporate the good ideas of these researchers into stable, efficient, >user-friendly, veratile code (for the most part, the researcher's code is >none of these things). This strikes a VERY familiar chord! The group I work for consists of about 30 researchers who want to solve THEIR problem, don't want to take the time to generalize the code and document it properly, and yet feel perfectly justified about complaining when something I end up having to install for general use doesn't solve the next problem that is encountered. I maintain about 300,000 lines of very quickly mutating code in about 25 major programs and a bunch of ancillary programs for the macromolecular crystallography group at Purdue. We use about 1/2 of the time on the university's Cyber 205, and the ability to write clean, fast code with a nice user interface is critical to our productivity. The division between researchers who want a simple, easy-to-learn language and the requirements of making the code run fast enough while part of a large package would be impossible to deal with in "pure" Fortran 77 for the problems we deal with. Fortran 88 makes several very important steps toward curing this problem. The most important to us in terms of number crunching are the allocatable arrays and vector syntax. The process of integrating all of this into packages demands that I either 1) use Fortran 77 syntax and end up with hard to follow code (doing database oriented work and making good interactive menus is not nearly as easy or clear in Fortran as it is in, say, Pascal or C). 2) write it in another language, in which case nobody else here will be able to read it The record construct in particular DOES make this a more general purpose language (we still need pointers!). This is good, because we are moving away from separate number crunching programs that require a painfully intimate knowledge of the operating system to use to fully integrated packages designed to be used by a non-programmer. Integrating the original pieces and parts in a clean manner will be a lot easier with Fortran 88. In other words, what we want to do with the programs has not changed, but our expectations of the quality of the man/machine interface have risen. Its time to come out with a language that has evolved to make that easier. Hardware and user expectations have come a long, long way in 20 years. Fortran hasn't. There are 2 ways of looking at the complexity of the proposed standard. A pessimist would say that you are making the language too complex and that it will be harder to implement and learn. An optimist would say the the language will be much more powerful than the current standard and will allow us to cleaner and more transportable code. My own feelings : 1) It will make it a lot easier for people who have to put together large programs from scraps written by people who can barely program. 2) The same people who took the time to learn Fortran 77 when it came out (and were ecstatic about thinks like CHARACTER variables) will take up the new syntax as fast as they can and drop Fortran 77 as fast as they dropped Fortran 66. 3) Those who prefer to keep puttering along with "simple" languages like Fortran 66 (gosh, wasn't dealing with character data in this very "simple" revision of the language fun?) and deliberatly refused to bother to learn Fortran 77 constructs will keep on writing in whatever they first learned. We have several people here like that- they are still annoyed when I use CHARACTER variables and those horrid IF () ... ENDIF clauses instead of nice neat GOTO's. Indentation of code is also a radical and frightening idea to these people. Before Fortran 77 came out, the compilers here had implemented about 3/4 of the constructs already. Some of the stuff in the 88 standard has been implemented in vendor-specific constructs already. Looking at just the Cray and CDC Fortran compilers and all of their high-performance additions to the language would seem to indicate that if we don't come up with a standard SOON for some of these constructs we are going to end up with a LOT of Fortran 77 code that can only run on one vendors machines. We already have about 110,000 lines of such code - we had to use the vendor specific syntax in order to get the programs to run in a reasonable amount of time. Now we can't share these programs with Cray users, since they use a different syntax. Kind of makes one wish that certain companies had gotten together and come up with a standard a few years back. I shudder to think what it costs to port our programs to the VAXens and Crays used by most of our collegues. I don't like everything in Fortran 88, but there is a lot more that I want to use VERY badly. So I say, forget about the people who are unwilling to add useful constructs to the language. In most cases, no matter what the constructs are, they won't want to learn them and would prefer to stay with whatever they learned in the first place. Fine. They don't have to use 'em. Alas, the same people who whined about having to open a book or ask someone what an IF () ... ENDIF construct was when Fortran 77 came out will be singing the same song when Fortran 88 comes out and they encounter someone elses code who decided that they were really neat. C'est la vie... -- Greg Kamer - Purdue Macromolecular Crystallography tsh@mace.cc.purdue.edu (internet - read every day) xtsh@purccvm.bitnet (bitnet - read very rarely)
fpst@hubcap.UUCP (Steve Stevenson) (10/22/88)
From article <977@l.cc.purdue.edu>, by cik@l.cc.purdue.edu (Herman Rubin): > The only penalties for increasing the size of the language are the size, and > to a lesser extent the speed, of the compiler. Believe that PL/I will show you quite differently. The cost of very large languages is in the generality of the underlying coding structures. These are hidden from all but the compiler types. You're being naive. > All of the present languages deny the programmer the power of the machine. > If execution time is at all important, this is criminal. Machine structure > is simpler than Fortran (any machine). For von Neumann machines, this probably is not the case (Fortran). It WILL be the case when y'all start trying to force a von Neumann language to do distributed processing. -- Steve Stevenson fpst@hubcap.clemson.edu (aka D. E. Stevenson), fpst@prism.clemson.csnet Department of Computer Science, comp.parallel Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell
brainerd@unmvax.unm.edu (Walt Brainerd) (10/22/88)
The purpose of an ANSI technical committee such as X3J3 is to discuss
and resolve technical issues. Some of you reading this column must be
sensing how frustrating it is to conduct a rational technical argument
with people like the folks from Convex, who say that
a) the proposed Fortran 88 is no good because Ken Kennedy, a Ph. D.
computer scientist, says it isn't.
b) the proposed Fortran 88 is no good because some Ph. D. computer scientists
had a hand in developing it.
Well, if you're not too logical, then maybe you should be politically astute;
one of the officers of X3J3 is the Editor, but it is not Walt Brainerd
(as P Smith, a member of X3J3, seems to think) and never has been!
Some other basic facts of recent postings need to be corrected:
1. My first language (other than an assembler) was Fortran,
first learned in 1960, before Pascal and C were invented, I believe.
That does not mean that the good ideas from these more recent languages
should not be borrowed.
2. The document discussed by ISO/WG5 was the work of X3J3 over the last
ten years. The "five" mentioned only served as a group to modify
the draft standard to simplify it as requested by many commenters.
For example, ALIAS, IDENTIFY, RANGE, internal procedures, and
host association were removed.
Some differences of opinion:
1. I think "computer scientists" with vast experience with Fortran and
scientific computing, even if they ARE educated, are at least as
qualified to design Fortran as compiler writers. Acutally, I was also
hoping that my compilers would be written by people knowledgable in the
field of computer science. The issue of proper representation reminds
me of the U.S. senator that, when accused of being quite mediocre, said
that mediocre people need representation. Users need all of the
representation they can get and some of that representation
should be through people who understand language design issues.
Some of it, inevitably, will be mediocre.
2. Hey, folks, we're approaching the 1990s. Technology is getting more
complicated, and so are compilers (along with the technology available
to write them), but anyone who thinks Fortran 88 is as complicated as
Ada has been ingesting brain-damaging substances.
I appreciate Bob Allison's sentiment to try to downplay polarization
of vendors and users. Of course there are exceptions on both sides,
but I stick by my statement (with which P Smith of Convex agrees) that
the hard objections come from some vendors (and the hard push for it
is coming from some of those representing users). It didn't used to be this way
when most members contributed toward making the proposed standard the best
they could, whatever their technical positions were.
The above ARE the opinion of my employer (which is NOT the University
of New Mexico, by the way), as well as myself.
Walt Brainerd 505/275-0800
Unicomp, Inc. Albuquerque, NMlink@stew.ssl.berkeley.edu (Richard Link) (10/22/88)
In article <894@mace.cc.purdue.edu> tsh@mace.cc.purdue.edu (Greg Kamer) writes: >This strikes a VERY familiar chord! The group I work for consists of >about 30 researchers who want to solve THEIR problem, don't want to >take the time to generalize the code and document it properly, and >yet feel perfectly justified about complaining when something I end >up having to install for general use doesn't solve the next problem >that is encountered. I have now seen several comments to the effect that scientists can't program, or are at least sloppy & don't follow modern programming constructs and software engineering practices. This is an over-generalization. I can show you code written by scientists that would teach programmers a thing or two. On the other hand, I've seen very elegant FORTRAN code written by a programmer, which very greatly influenced my own programming style, but which nevertheless was quite wrong. (The software was for quality control of commercial aircraft navigation systems. The company did not know that the statistics calculations were wrong until I had to modify the code. Here's a perfect example of Kernighan & Plauger's "make it right before you make it faster". This error could have had potentially disasterous consequuences). I think we can each come up with examples and counter-examples of who can program better, but that adds nothing to the FORTRAN standards debate. However, I do resent this kind of condescending attitude towards scientists who program. Remember, physicists invented the computer and programming languages. I think we deserve our 2 cents' worth. Dr. Richard Link Space Sciences Laboratory University of California, Berkeley link@ssl.berkeley.edu
fouts@lemming. (Marty Fouts) (10/22/88)
In article <15821@agate.BERKELEY.EDU> link@stew.ssl.berkeley.edu (Richard Link) writes: > However, I do resent this kind of condescending attitude towards > scientists who program. Remember, physicists invented the computer > and programming languages. I think we deserve our 2 cents' worth. I have tracked down this condescending attitude in a lot of programmers who have worked for / with me over the years, and it is often a response to a certain kind of arrogant physicist who makes outrageous claims like "remeber physicists invented the computer and programming languages." (;-) Although I assume Dr. Link is not one of these arrogant physicist, I have frequently had to deal with such. And with condescending programmers. Neither side does the other either good; nor themselves in the relationship. For the history books, the invention of the computer (Meaning of course, the modern stored program digital electronic computer) is lost in antiquity. Interesting claims have been made for Macauly/Echert (sp?), Von Neumann, and Turing, among others. Not all of the claimed individuals were pysicists. Depending on how you defining the invention of programming languages, you can either give credit to those who did the fundemental work in computational semantics, such as Church, Turing, Chomsky et. al; or you can give credit the independent inventors of the first handful of recognized languages. The latter batch of people are truely a mixed bag, and include physicists, mathematicians, the occasional Navy captain, and even (shudder) computer scientists, although few thought of themselves as such at the time. Even the group of people who invented Fortran weren't all physicists. Unfortunately, there is a lot of myopia in the physics/engineering community, which is increased by the condescending attitude taken by some computer scientists. (BTW, I'm neither.) I would like the physicists to notice that physics isn't the only numerical programming, and that not even all physics problems get solved the same way. I would like programming language bigots to notice that physicists have real problems to solve, and I would like to see them talk to each other, not at each other. But, its Friday night and I/ve been waiting for the Y/MP to come back up for an hour so I may as well spend my time believing in miracles as anything else. Marty -- +-+-+-+ I don't know who I am, why should you? +-+-+-+ | fouts@lemming.nas.nasa.gov | | ...!ames!orville!fouts | | Never attribute to malice what can be | +-+-+-+ explained by incompetence. +-+-+-+
link@sag4.ssl.berkeley.edu (Richard Link) (10/22/88)
In article <2060@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: >how frustrating it is to conduct a rational technical argument >with people like the folks from Convex, who say that > >b) the proposed Fortran 88 is no good because some Ph. D. computer scientists > had a hand in developing it. As far as my own postings are concerned, I did not mean to impune the legitimate and important contributions of Ph.D. computer scientists to language theory. What I object to is turning FORTRAN from a number cruncher (FORmula TRANslator), it's original scope, into an all-purpose language with lots of bells and whistles, simply because some Ph.D. computer scientists *evidently* feel that this should be so. The new standard does not serve my needs. I feel that I should speak up, since numerical analysis and modeling in FORTRAN is what I do for a living. I *do* want an improved FORTRAN, but I want the "improvements" to be truly useful, without overloading the language with constructs *deemed*, but not proven, useful by the aforementioned Ph.D. computer scientists. As far as I can tell, the needs of the end-users (such as myself) were not given much consideration in drafting the proposed standard. (This is a subjective opinion only, please spare me the flames). >Some other basic facts of recent postings need to be corrected: > >1. My first language (other than an assembler) was Fortran, > first learned in 1960, before Pascal and C were invented, I believe. If you can't remember, no wonder FORTRAN is in trouble! :-) > That does not mean that the good ideas from these more recent languages > should not be borrowed. I agree with this, but only so far as it improves FORTRAN without changing its scope. I don't want a lot of garbage simply because Pascal or C has it! If you want another Ada, it's already been invented. Richard Link, Ph.D. Space Sciences Laboratory University of California, Berkeley link@ssl.berkeley.edu
psmith@mozart.uucp (Presley Smith) (10/22/88)
In article <2060@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: > >The purpose of an ANSI technical committee such as X3J3 is to discuss >and resolve technical issues. Some of you reading this column must be >sensing how frustrating it is to conduct a rational technical argument >with people like the folks from Convex, who say that > >a) the proposed Fortran 88 is no good because Ken Kennedy, a Ph. D. > computer scientist, says it isn't. > >b) the proposed Fortran 88 is no good because some Ph. D. computer scientists > had a hand in developing it. > >Well, if you're not too logical, then maybe you should be politically astute; >one of the officers of X3J3 is the Editor, but it is not Walt Brainerd >(as P Smith, a member of X3J3, seems to think) and never has been! Walt, I hate to contradict you, but I know full well who the editor is. I also don't control the people at CONVEX that want to express their OWN opinions which may NOT be my opinions and NOT the opinions of the company. In fact, Bob put a disclaimer on his article that the opinions were his own, and they certainly do not necessarily represent my views. I believe if you look at the series of information that is on the net, that I have NEVER said anything about Ken Kennedy or about PHD computer scientists. I also am NOT asking others to write messages. I'm prepared to take full responsibility for my message and for how politically astute I may be, but not for the personal responses of others. They have a right to their own opinions, just as you have a right to yours. I will continue to request that eveyone express their opinions whether they agree with mine or not. > >Some other basic facts of recent postings need to be corrected: > >1. My first language (other than an assembler) was Fortran, > first learned in 1960, before Pascal and C were invented, I believe. > That does not mean that the good ideas from these more recent languages > should not be borrowed. > >2. The document discussed by ISO/WG5 was the work of X3J3 over the last > ten years. The "five" mentioned only served as a group to modify > the draft standard to simplify it as requested by many commenters. > For example, ALIAS, IDENTIFY, RANGE, internal procedures, and > host association were removed. > Okay, let's put some more facts on the table. The "document discussed" at the ISO/WG5 meeting was a document "based" on the work of X3J3 over the last ten years. That final document was actually produced by YOU in a hotel room in Jackson during the last X3J3 meeting. That document as modified was NOT voted on in the Jackson meeting and was NOT approved by X3J3 to be submitted to ISO or WG5. The SD-2 is very clear that documents to be submitted to the international groups are to be passed through the X3 Secretariat prior to being forwarded to the international group. From the votes at the X3J3 meeting in Jackson, it is clear that this document does not have the 2/3 approval of the X3J3 committee required to make this document the base for a revision to the proposed 8x standard. WG5 in resolution 2 requested that DP1539 be modified with the changes specified in that resolution. DP1539 is S8.104 which was the draft proposed standard that was sent out for public review. Since that time, you, Walt, have produced S8.108, S8.109, and are in the process of producing S8.110 which supposedly will be S8.104 plus what WG5 requested. My problem is with the process and not just with the document. 1. The full X3J3 committee has NOT been approving the changes going into S8.110 prior to their being added or changed. There are changes that have been made by a small group of people that have not been approved by the whole committee that are going into this document. WG5 saw changes that had NOT been approved by X3J3. 2. The members of X3J3 has no way of actually telling what changes have been other than to read this 400 page document and attempt by hand to compare it's current contents to the S8.104. I am not alone in my skepticism on this point. 3. The debate in the committee in the last two meetings has been on what document to start with as a base document for the changes required by the public review comments. Most members have been looking at functionality that is going to be removed or added and not at the details of "is the proposed document technically correct?" X3J3 is still trying to decide what functionality will be in or out of the proposed standard. And we are being asked by WG5 to approve and transmit a new proposal in a two month time period that has not been properly reviewed for technical accuracy...and that proposal will probably become the new ISO standard. I'm sorry, Walt, but I don't buy it. That's why X3 has now directed X3J3 to follow the rules. 3. Using a document as a base that is NOT DP1539 is NOT following the instructions of WG5 in resolution P2. I'd like to see the change record for document S8.110 that shows that it started with DP1539 and changed the following lines to whatever and produced S8.110. Can you produce such a document? If WG5 asks for such a record, can you show compliance? >Some differences of opinion: > >1. I think "computer scientists" with vast experience with Fortran and > scientific computing, even if they ARE educated, are at least as > qualified to design Fortran as compiler writers. Acutally, I was also > hoping that my compilers would be written by people knowledgable in the > field of computer science. The issue of proper representation reminds > me of the U.S. senator that, when accused of being quite mediocre, said > that mediocre people need representation. Users need all of the > representation they can get and some of that representation > should be through people who understand language design issues. > Some of it, inevitably, will be mediocre. > >2. Hey, folks, we're approaching the 1990s. Technology is getting more > complicated, and so are compilers (along with the technology available > to write them), but anyone who thinks Fortran 88 is as complicated as > Ada has been ingesting brain-damaging substances. It's interesting that there is a chart in the IBM ballot response that compares FORTRAN 8x to Ada... pull it out and take a look. >I appreciate Bob Allison's sentiment to try to downplay polarization >of vendors and users. Of course there are exceptions on both sides, >but I stick by my statement (with which P Smith of Convex agrees) that >the hard objections come from some vendors (and the hard push for it >is coming from some of those representing users). It didn't used to be this way >when most members contributed toward making the proposed standard the best >they could, whatever their technical positions were. > P Smith certainly agrees that "NO" votes on the X3J3 committee for the FORTRAN 8x standard have been from vendors. But a users such as Los Alamos, Boeing, and others voted "NO" also. Since we've opened this again, I will make two other comments: 1. I believe the public review comments reflected both the amount of information and the tone of the information presented to the user community either in Europe or the U.S. In the U.S. much of that information was toward the "NO" side and in Europe most of it was toward the "YES" side. I beleive this is clear. The facts also are that 60% of the public comments was negative and that was not all from the U.S. There were many positive comments on both sides of the oceans. 2. I still do not believe the statement that Europe knows the views of the user community any better than any the other group. Vendors have a way of providing information to their users and collecting information from their users. Part of the debate has been that of vendors vs users. Large user groups that work with the various vendors are also members of X3J3 and provide input directly to their vendors. Some of these groups are DECUS, Share, Guide, etc. For example, I can show you a resolution that the DECUS user group put together last year at one of their meetings that supported DEC's position on FORTRAN 8x. These user groups are independent organizations from the vendors and are NOT required to support the vendor. May times they pressure the vendor to make changes in products, etc. CONVEX just completed it's user group meeting in October. We had a session on the status of FORTRAN 8x. In discussions with various users, their number one concern is performance and not new language features. May of them are interested in array notation and other parts of the proposed FORTRAN 8x. Some expressed dismay at the way things are going and at the international rif that appears to be forming. I believe that the vendors are in touch with the users and that they listen to their user groups. We certainly listen to our user group and attempt to make changes in our products based on what they say. We also attempt to represent the view of that group to X3J3 in the way we vote.
bill@hcx2.SSD.HARRIS.COM (10/22/88)
/* Written 12:02 pm Oct 20, 1988 by hirchert@uxe.cso.uiuc.edu in hcx2:comp.lang.fortran */ Kurt Hirchert (hirchert@uxe.cso.uiuc.edu) writes: > and, as you note later, most U.S. commenters got their information from > presentations made by vendors opposed to the draft. Because of ISO > rules, the European presentations were allowed to give attendees copies > of the draft. Because of X3/CBEMA rules, attendees of U.S. presentations > had to order theirs from Global Engineering. Many either chose not to > because of cost or received their copies from Global Engineering so late > that they did not have time to adequately review them, so they simply > echoed what was presented to them. (I, too, could list particular > comment numbers.) Do you really to argue that people that had copies of > the draft are less representative than those who did not? This whole issue of "vendors" versus "users" really angers me. I took the time to go through the public comment and note opposing comments that came from organizations I knew to be heavy FORTRAN users. I selected only those letters that, based on the detailed comments, indicated a reasonable depth of review of the draft. Here is just a partial list (those marked with an asterisk proclaimed themselves to be "official positions" of that organization): Organization Number of comments from ---------------------------------------- ----------------------- ARCO Oil and Gas Co. 1 ATT Technology Systems 1 Amoco Corporation 1 * Boeing (various divisions) 17 Center for Lithospheric Studies 1 Chevron Oil Field Research Co. 1 Exxon Central Services 1 * Federal Communications Commission 1 General Electric (various divisions) 3 Jet Propulsion Laboratory 2 Lawrence Livermore National Labs 2 Los Alamos National Labs 11 NASA - Goddard Space Flight Center 2 National Center for Supercomputing Applications 1 (Mr. Hirchert's employer) U.S. Army (various installations) 3 In all, I counted 73 letters like this. Don't tell me it is just "vendors" and "uninformed users" that are opposed to the draft standard; it just ain't so! Also, I have been doing a survey of Harris FORTRAN users to find out more about their views on the draft standard as well as FORTRAN in general. So far, a very small minority have answered "yes" to the question "Are you familiar with the 8x draft?". One question I keep asking myself is this: If users are really hungering for major new features/changes in FORTRAN/77, why are they not informing themselves about X3J3 activities? I think it is because the premise is false; they are NOT hungering for major changes. Improvement, yes, but not on the order of the 8x draft. > and I'll bet that the U.S. presentations didn't talk about how > unrepresentative it is to consider the implementation time for many of > those FORTRAN 77 implementations. (Many vendors took FORTRAN 77 as an > opportunity to write new compilers based on new compiler technology > (e.g., writing in HLL's rather than assembler, using common back-ends for > code generation, using automatically generated parsers, etc. On the > other hand, vendors seem inclined to implement Fortran 8x as extensions > to their existing products. Indeed, many have already implemented large > parts of 8x in precisely this manner.) I think you just argued against yourself, Kurt. Most of the vendors who have implemented parts of 8x as extensions did so because they had already rewritten their FORTRAN compiler once; they didn't want to do it again. Moreover, those compilers were now "up-to-date" on technology, so the impetus for rewrite that existed with old FORTRAN/66 compilers no longer existed for them. However, that does not prove that all FORTRAN/8x features can be done as "add-ons" to a FORTRAN/77 compiler. FORTRAN/8x changes many of the assumptions that a compiler could make about a FORTRAN/77 program -- assumptions that most likely are embedded in the design of almost all FORTRAN/77 compilers. You want specifics? Okay. In FORTRAN/77, there is no need to have dynamic-sized temporaries; in 8x it is a must for array operations. In 77, you can throw away everything about a program unit once it is compiled; in 8x this is isn't true, because of MODULES. In 77, each procedure is self-contained; there is no information "inherited" from outside it. In 8x, MODULE and internal procedures inherit information about variables and types from outside the program unit. This isn't the whole story, either. The argument I find most compelling is this: Just about every compiler implementor I have asked agrees with my estimate of 8x compiler complexity at about half that of Ada. Now, we have a darn good Ada compiler. We bought the front-end, and we have a common back end known as CCG. Yet, for the three years since we started the Ada project, it has consumed at least 4 people full time, all year every year, just to maintain this product; there were even more involved in its development. We have NEVER had that many people working on our FORTRAN/77 compiler, even when it was being developed (with the same technology). >>It's real simple. If you don't get the vendors to sign up to >>producing compilers and supporting those compilers, NO new standard >>will be successful. It's ALGOL 68 again. A beautiful language >>that none of the major vendors implemented. That could have a >>lot to do with why we are still programming in FORTRAN and not >>ALGOL 68. > > Then again, the fact that no existing programs would run in the new language > may have had something to do with why there wasn't enough demand to get the > major vendors to do good implementations of Algol 68. (Several of the major > vendors did implementations, but typically they weren't very impressive.) > Fortran 8x is designed to support the existing base of programs as well as > offer new features to the Fortran community. Wait a minute. C was a new language (after FORTRAN); it has been successful. Pascal was a new language, and it has been moderately successful considering it was designed as a teaching tool. BASIC was a new language, and it has been successful. This argument is a non-starter. > Finally, let me make a couple of comments not directly in response to > Presley's. In the U.S., the trade press has tended to cover Fortran > standardization only when X3J3 produced a draft or report or when X3J3 > had major internal disagreements. In Europe, on the other hand, there > has been a great deal of continuing coverage. Also, most of the ISO > delegates have been involved in Fortran standardization for many years, > while a large part of the X3J3 membership (especially among those opposed > to the Fortran 8x draft) who joined within the last couple of years. Is > it possible then that the greater acceptance of the Fortran 8x draft > outside the U.S. (and by WG5, in particular) might be a result of > long-term familiarity with its contents, reducing the "fear of the > unknown" factor and providing a greater opportunity to assess and > appreciate the benefits as well as the costs of the new features. There are at least two other likely causes for greater European acceptance. One: they have spent so much time with 8x that it is now more familiar to them than FORTRAN/77. Thus, they fear going back to something they now don't know very well. Two: They have an enormous emotional investment in 8x; it is psychologically very difficult for them to give up on it. The Europeans have typically been more enamored of "neat features" in languages than in their ultimate utility. Witness "pass by name" in Algol 60. In fact, that is the real reason Algol 68 died: it had "neat" features but not a well-designed set of _useful_ features (witness the absence of I/O). Bill Leonard, X3J3 Member Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.harris.com or bill%ssd.harris.com@eddie.mit.edu
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (10/23/88)
In article <15821@agate.BERKELEY.EDU> link@stew.ssl.berkeley.edu (Richard Link) writes: >In article <894@mace.cc.purdue.edu> tsh@mace.cc.purdue.edu (Greg Kamer) writes: >>This strikes a VERY familiar chord! The group I work for consists of >>about 30 researchers who want to solve THEIR problem, don't want to >>take the time to generalize the code and document it properly, and >>yet feel perfectly justified about complaining when something I end >>up having to install for general use doesn't solve the next problem >>that is encountered. > >I have now seen several comments to the effect that scientists can't >program, or are at least sloppy & don't follow modern programming >constructs and software engineering practices. [lengthy indignant rebuttal deleted] The point is that writing good code is not part of the job description for most scientists. Usually, we're more interested in writing something that does the job at hand, not writing some wonderfully generalized all purpose solutions. Turning this sort of code into general purpose, re-usable modules can be very difficult, and the limitations of the fortran language make it a lot harder. Scientists can write very good code, but most of them, most of the time, don't. It's just not our primary concern. As a practicing physicist at a high-energy research lab, I've re-written a lot of very bad code, and I've wished many times over for a lot of the features in the F8X proposals. The situation is better since we've implemented source control in the lab, and started using SASD and similar techniques, but I still wish for a better Fortran. (and before anyone says it, switching to another language is not an option.) -Dan Riley (dsr@lns61.tn.cornell.edu, dsr@crnlns.bitnet) -Wilson Lab, Cornell U.
ssd@sugar.uu.net (Scott Denham) (10/23/88)
In article <15821@agate.BERKELEY.EDU>, link@stew.ssl.berkeley.edu (Richard Link) writes: > I have now seen several comments to the effect that scientists can't > program, or are at least sloppy & don't follow modern programming > constructs and software engineering practices. > I certainly didn't say "can't", and certainly didn't mean to imply "all" To be more exact, many of our "scientists" in fact do NOT produce what one might consider "production quality" code. Not that they couldn't... many of these folks are excellent programmers; the point is that's not what they are paid to do. Sometimes a good clean design comes naturally; other times it may not, particularly if your research leads you down a somewhat different path than you had expected to take when you started. Their job is to develop and prove the concepts; ours is to take the resulting prototype code and make it part of a robust, generalized production system. To do this cost-effectively we MUST all be working in the same language! I'd LIKE it to be FORTRAN. > > I think we can each come up with examples and counter-examples of > who can program better, but that adds nothing to the FORTRAN > standards debate. I do too! I can show you examples of stuff turned out by so-called "professional programmers" that would curl your hair! (It does mine every time I have to maintain it or answer a "how does it work" question_) > > However, I do resent this kind of condescending attitude towards > scientists who program. Remember, physicists invented the computer > and programming languages. I think we deserve our 2 cents' worth. > I hope nothing in my comments triggerd this outburst :) . As I've said above I've got no problem with scientists who program. And I'm sure there are few of us who don't have an ugly hack job or two, thrown together to get a task accomplished, that we might not exactly want held up as a shining example of uour best work! > Dr. Richard Link Scott Denham Western Atlas International
jejones@mcrware.UUCP (James Jones) (10/23/88)
In article <44400025@hcx2>, bill@hcx2.SSD.HARRIS.COM writes: > In fact, that is the real reason Algol 68 died: it had "neat" features > but not a well-designed set of _useful_ features (witness the absence of > I/O). I think Algol 60 is being confused with Algol 68 here. Algol 68 most definitely did have I/O, though there are those who thought it too convoluted. I dare say there are those who would disagree with the rest of the above characteri- zation of Algol 68. James Jones
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (10/24/88)
In article <15851@agate.BERKELEY.EDU> link@sag4.ssl.berkeley.edu (Richard Link) writes: > >As far as my own postings are concerned, I did not mean to impune the >legitimate and important contributions of Ph.D. computer scientists >to language theory. What I object to is turning FORTRAN from a number >cruncher (FORmula TRANslator), it's original scope, into an all-purpose >language with lots of bells and whistles, simply because some Ph.D. >computer scientists *evidently* feel that this should be so. The new >standard does not serve my needs. Are you complaining that f88 leaves something out ? If your complaint is that it contains features that YOU do not deem useful, it is not logical to conclude that other users do not. These other users, in fact, lobbied hard to get them in and to keep them in. MY background in in mathematics and Kalman filtering (I was involved with co-authoring and porting the resulting code), and there are very few features in f88 that I would not have found very useful. There are, in fact, features MISSING. But I strongly support acceptance of the current draft NOW. It represents a strong step forward. It should not be forgotten that the last couple of years of committee meetings involved attempt after attempt to remove features; the vast majority of these attempts failed, because these "bells and whistles" are considered vital by many. > >I feel that I should speak up, since numerical analysis and modeling >in FORTRAN is what I do for a living. I *do* want an improved FORTRAN, >but I want the "improvements" to be truly useful, without overloading >the language with constructs *deemed*, but not proven, useful by the >aforementioned Ph.D. computer scientists. Not all numerical analysts agree with you that the language is overlaaded with uneeded features. If you would itemize the features you think unecessary, supporters of the standard can produce ideas on how they can be employed to good effect. > >As far as I can tell, the needs of the end-users (such as myself) were >not given much consideration in drafting the proposed standard. >(This is a subjective opinion only, please spare me the flames). > Would you please present your evidence ? Until fairly reccently I too was an end-user (and an offical observer, so I got all the meeting minutes). My needs WERE represented. >> That does not mean that the good ideas from these more recent languages >> should not be borrowed. > >I agree with this, but only so far as it improves FORTRAN without changing >its scope. I don't want a lot of garbage simply because Pascal or C has it! I think everyone agrees with this. But those features which have proved useful belong in FORTRAN. Please define FORTRAN's scope. I have always thought that FORTRAN was THE language for scientific programming (APL notwithstanding). Seems to me that there are a lot of different scientists, with different needs. But it would not make too much sense to have specialized languages for each (who wants to translate IMSL and NAG into dozens of dialects ? Not me!) >If you want another Ada, it's already been invented. Meaning ? F88 is too much like Ada. If so, how ? > > I propose that opponents of the standard give specifics. Propoents can then respond in a reasoned way. Nothing is gained by pointing out that certain vendors are out to gut the standard, calling members of the committee ComputerScientists, or claims that physicsts make poor programmers. Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
psmith@mozart.uucp (Presley Smith) (10/24/88)
In article <50500081@uxe.cso.uiuc.edu> hirchert@uxe.cso.uiuc.edu writes: > >Presley Simith(psmith@mozart.uucp) writes: >>I don't believe that the European's public comment represent the consumer >>viewpoint any more than the U.S. public comments represents the consumer >>viewpoint. What are the facts... > >>1. The Europeans were invited to a series of "FORTRAN Forums." These >>Forums presented the positive side of the FORTRAN 8x standard and pumped >>up the users to respond to "get the standard out...without delay." There >>are many of these comments in the European response. In fact, I could >>list the particular comment numbers here, but I will not. > >and, as you note later, most U.S. commenters got their information from >presentations made by vendors opposed to the draft. Because of ISO rules, >the European presentations were allowed to give attendees copies of the draft. >Because of X3/CBEMA rules, attendees of U.S. presentations had to order theirs >from Global Engineering. Many either chose not to because of cost or received >their copies from Global Engineering so late that they did not have time to >adequately review them, so they simply echoed what was presented to them. (I, >too, could list particular comment numbers.) Do you really to argue that >people that had copies of the draft are less representative than those who did >not? Kurt, I certainly agree with you on the Global Engineering issue. We should be able to freely distribute copies of the proposed standard. This has certainly been a problem. There are a couple of issues with the standard process in general: 1. The draft of Fortran 8x is large. Not every user is willing to spend the time to read and digest what is there. It takes a long time to read and even longer to really understand what each new feature really means and how they all hang together. Help was available in the form of a book by Metcalf and Reid called "Fortran 8x Explained." That provided a more compact way to "review" the proposed standard. 2. Let me remind you that there is NO requirement for a person to have read or understand the proposed standard in order to comment on it. And, the ANSI rules do not separate comments from people who have spent hours studying the proposed standard from those who have heard a presentation and either like or don't like some part of the standard and want to express their opinion on the subject. A comment is a comment. 3. Most Fortran users are not compiler writers, and they are not aware of the issues of producing efficient compilers. Some input from the compiler writing community is helpful in understanding those issues. It appears that some do not believe what the compiler writers are saying. Everyone can make their own determination on what to believe and what not to believe. Much of this input is coming from people who have implemented multiple compilers in their lives and in some cases, compilers for multiple different languages including both Fortran and Ada. ( I have removed a portion of Kurt's response which was addressed by Bill Leonard of Harris...) > >>2. In the U.S. various groups received a more balanced set of >>information. Presentations presented the new features, benefits >>of each, and the drawbacks of each. Discussions did not center >>around the "beauty" of the "modern FORTRAN" language, but around >>how it would help the user and how it would hurt the user. In >>the U.S. we also discussed how it would be more complex for an >>engineer to pick up this 8x language quickly (one would need a >>better computer science background...) and issues of sustaining >>programs that were created with a mixture of FORTRAN 77 and >>FORTRAN 8x constructs... > >My impression of many of the U.S. presentations is that they presented minor >"straw man" benefits of many of the new features (ignoring benefits I would >consider far more important), and then attacked them with "facts" that I find >highly questionable. In my experience, the measure of a balanced presentation >is that both sides think it was biased towards the other side. I don't see >that the U.S. presentations met this criterion any better than the European >presentations. (I.e., presentations on both sides of the Atlantic tended to >reflect the biases of the presenters.) > >>In Europe, many of the presenters of the Forums were users that >>were in favor of making FORTRAN a "modern language" that would >>"compete" with other languages like Ada and Pascal. > >>In the U.S. most presentations were made by the Vendors. The >>ones that must support the FORTRAN user base and provide quality >>products for their use. It seems strange that the major >>vendors: IBM, DEC, and UNISYS all said "NO" to FORTRAN 8x. >>Has anyone really looked at the why? > >I sure have. I happen not to agree with many of their technical arguments >and assertions. (Unfortunately, for two of the above three, I find political >or tactical motives to be a better predictor of their positions than technical >considerations. I still listen to their technical arguments carefully, but I >take them with a grain of salt, especially when they involve unsupported >assertions.) Since we've opened this again, I will make two other comments: 1. I believe the public review comments reflected both the amount of information and the tone of the information presented to the user community either in Europe or the U.S. In the U.S. much of that information was toward the "NO" side and in Europe most of it was toward the "YES" side. I beleive this is clear. The facts also are that 60% of the public comments are negative. The negative comments were not all from the U.S. There were also many positive comments on both sides of the oceans. 2. I still do not believe the statement that Europe knows the views of the user community any better than any the other group. Vendors have a way of providing information to their users and collecting information from their users. Part of the debate has been that of vendors vs users. Large user groups that work with the various vendors are also members of X3J3 and provide input directly to their vendors. Some of these groups are DECUS, Share, Guide, etc. For example, I can show you a resolution that the DECUS user group put together last year at one of their meetings that supported DEC's position on FORTRAN 8x. These user groups are independent organizations from the vendors and are NOT required to support the vendor. May times they pressure the vendor to make changes in products, etc. CONVEX just completed it's user group meeting in October. We had a session on the status of FORTRAN 8x. In discussions with various users, their number one concern is performance and not new language features. May of them are interested in array notation and other parts of the proposed FORTRAN 8x. Some expressed dismay at the way things are going and at the international rif that appears to be forming. I believe that the vendors are in touch with the users and that they listen to their user groups. We certainly listen to our user group and attempt to make changes in our products based on what they say. We also attempt to represent the view of that group to X3J3 in the way we vote. Again, no one can force their opinion on anyone. If you wish not to "agree with many of their technical agruments and assertions", that is certainly your right. It is certainly true that the standards process is also a political process. Witness the result of the WG5 meeting. (Again, some deletion of text...) >There is substantial disagreement about what the user base wants and >needs; it depends a lot on how you ask the question and how you >interpret the answer. Is it better to wait 5 years for a compiler with all >the features you want or to get some of them in 3 years and then wait another >10 years for the rest (if your're lucky)? If you are certain you don't really >need the features in the second batch, 3 years is clearly better than 5. If >you are certain you need features in the second batch, 5 years is clearly a lot >better than 13. If you're uncertain, you'll have to judge for yourself. I am not in favor of delaying the standard. But, it must be done by "due process" as defined in the SD-2. That is the current issue on the table. X3J3 could complete due process and have the new standard back for public review within a few months...if X3J3 would work togehter to make that happen. (More text deleted.) >>The other problem with this statement is that "five people on X3J3" >>put together this ISO/WG5 document from documents that had NOT been >>accepted by X3J3 at the last X3J3 meeting as being acceptable for a base >>document for the new FORTRAN standard. In fact, the delegation from X3J3 >>to the WG5 meeting was directed by X3J3 NOT to support this document >>as a base for the new FORTRAN standard. > >That's not the way I remember it. First of all, there was no "X3J3 delegation". I did not say the X3J3 delegation. My statment is in the previous paragraph. My statement was "the delegation from X3J3". >X3J3 instructed the U.S. delegation, all of whose members were also members of >X3J3. X3J3 had no authority to instruct those X3J3 members who were part of >non-U.S. delegations. Second, the instruction was not to present the ABMSW >plan and to avoid a situation in which WG5 took the job of producing the >international standard away from X3J3. As I read the meeting reports, these >instructions were followed. The ABMSW plan was presented by a member of one of >the other delegations, and WG5 left the job of producing the international >standard in X3J3's hands but gave X3J3 more explicit instructions about what >it wants the international standard to contain. The ball is now in X3J3's >court to decide whether there can be one standard for both ISO and ANSI. > Ture. There are other issues in all this. Certainly the ball is back in X3J3's court. And they will have to decide if there will be one or two standards. >> And now "five people on >>X3J3" are putting this document, that was rejected at the last X3J3 >>meeting, into final form. I don't believe this "five people on X3J3" >>have been operating on the instructions of X3J3 to produce this document. >>From the votes at the last X3J3 meeting and the direction from X3, it >>is unclear that X3J3 or X3 would authorize this work. > >Come on now. X3J3 members are free, as individuals, to work on whatever they >choose. It didn't X3J3 or X3 authorization for you and I to produce these >Usenet articles. Given the position of WG5, it is not unreasonable for these >people to do work to show X3J3 what an implememtation of the WG5 instructions >might look like. What, if anything, X3J3 does with this work is another issue >entirely. That is where X3J3 votes, X3 authorizations, etc. come into play. It's true that X3J3 and X3 did not authorize you and I to discuss this on the net. These individuals can do any work on the documents that they want but the effect of the X3 direction to X3J3 is that X3J3 is to process that document according to the SD-2. That means this document must be processed with the proper approvals prior to giving it back to WG5. That document does NOT belong to the 5 individuals that are doing the work on it and they cannot just give it to WG5 or anyone else as they see fit. >>One other thing to note. ANY document given to any ISO/SC/WG organization >>must be passed throughper the procedures sified in the SD-2. up, p >>If this document is not processed properly, major internation >>problems may result. > >Maybe, and then again, maybe not. The Hague agreement is no longer in effect, >so ISO standards no longer have to be developed by national standards bodies. >Working documents of committees following ANSI procedures are required to be >in the public domain (except for the standard itself). If X3J3 were to produce >a working document reflecting WG5's instructions, X3J3 might not be able to >"give" it to WG5, but there would be nothing wrong with WG5 "taking" it as the >basis for an ISO standard. (Having said this, let me also say that I would >prefer that this not be the way things happen.) I certainly would not be the one to provide the updated document to WG5 without obtaining the proper approvals first. You'll have a real hard time convincing the ANSI BSR that this document, that is made up mostly of the draft standard that went out earlier for public review, is just another "working paper." >Finally, let me make a couple of comments not directly in response to Presley's. >In the U.S., the trade press has tended to cover Fortran standardization only >when X3J3 produced a draft or report or when X3J3 had major internal >disagreements. In Europe, on the other hand, there has been a great deal of >continuing coverage. Also, most of the ISO delegates have been involved in >Fortran standardization for many years, while a large part of the X3J3 >membership (especially among those opposed to the Fortran 8x draft) who joined >within the last couple of years. Is it possible then that the greater >acceptance of the Fortran 8x draft outside the U.S. (and by WG5, in particular) >might be a result of long-term familiarity with its contents, reducing the >"fear of the unknown" factor and providing a greater opportunity to assess and >appreciate the benefits as well as the costs of the new features. > >Regardless of its cause, I think we have to deal with WG5's position as it is. >Trying to ignore it by characterizing it as unimportant or unrepresentative is >just as much a cop out as ignoring the negative comments from the U.S. > Interrupt need to deal with it directly. But, it cannot take precedence over getting on with producing a standard. That's what the X3 direction said... Get on with producing a standard by the rules in the SD-2 and provide WG5 with a response on when and how... and work with them to get to where we need to be...One standard for the world. I believe we all support that position.
lamson@sierra.uucp (scott h lamson) (10/24/88)
> psmith@mozart.uucp (Presley Smith) writes > Vendors have a way of providing information to their users and collecting > information from their users. > I believe that the vendors are in touch with the users and that they > listen to their user groups. > We also > attempt to represent the view of that group to X3J3 in the way we vote. Help me here. I work at General Electric Corporate Research and Development. Probably not one of your smaller companies. We have 300 Sun's, 3 dozen or so VAX's, an IBM 3081K, and a Convex 210 (220 soon...). No vendor has come here to talk about Fortran 8x ever that I have been told about. In order to have an informed opinion, I subscribe to the ACM Fortran Forum, ordered the draft of F8x, 6 copies of Fortran 8X Explained, and have asked about F8x at most vendor presentations. But the vendors have not made an effort to publicize the proposed standard here one way or the other. As for the user groups (DECUS, SHARE, CUG, or others), at least at our site, the people who might go to them are the systems managers, not people who (work for a living.. :) ) use fortran in their work. I will respecfully listen to compiler writers from vendors tell me how difficult the proposed F8x is to implement, that is their area of expertise, I do physics. But I reject the claim that any vendor has the right to say their opinions represent the views of their customers. Certainly that is not the case here, as no vendor has asked anyone I know about F8x. On the difficulty of implementing the proposed F8x, I feel that I must take the word of the experts that it will be difficult. I just think that it will be worth the cost. For each person-year that goes into writing a compiler, how many person-years go into people developing applications using that compiler? Could it be less than an order of magnitude? As for the speed of the compiler, my own opinion is this is a non-issue. The last time I worried about that was on a RAYTHEON 703, and even then the paper tape reader was slower. I spend a lot more time reading code than compiling it. That makes many of the features in modules and module procedures so very important; to get understandable readable code for complex applications. You can only worry about efficiency after you have the right answer. Scott| ARPA: lamson@ge-crd.arpa Lamson| UUCP: uunet!steinmetz!sierra!lamson (518)387-5795| UUCP: uunet!steinmetz!lamson!crd
tsh@mace.cc.purdue.edu (Greg Kamer) (10/24/88)
> In article <894@mace.cc.purdue.edu> tsh@mace.cc.purdue.edu (Greg Kamer) writes: > >This strikes a VERY familiar chord! The group I work for consists of > >about 30 researchers who want to solve THEIR problem, don't want to > >take the time to generalize the code and document it properly, and > >yet feel perfectly justified about complaining when something I end > >up having to install for general use doesn't solve the next problem > >that is encountered. > I have now seen several comments to the effect that scientists can't > program, or are at least sloppy & don't follow modern programming > constructs and software engineering practices. > This is an over-generalization. I can show you > code written by scientists that would teach programmers a thing or > two. On the other hand, I've seen very elegant FORTRAN code written > by a programmer, which very greatly influenced my own programming > style, but which nevertheless was quite wrong. > However, I do resent this kind of condescending attitude towards > scientists who program. Remember, physicists invented the computer > and programming languages. I think we deserve our 2 cents' worth. Sorry, I should have mentioned my background. I am a macromolecular crystallographer by profession (degree actually in Biology, as it was the closest thing available at Purdue), NOT a computer scientist. I write new code, integrate other users code, and maintain and document the stuff. My comments are those of a scientist who specializes in the computational aspects of his field and who is frustrated by the quality of the code passed on to him for integration into general programs. I took the time to learn how to program well (Fortran, Pascal, C and a lot of assembly languages I am doing my best to forget...) and it bugs the heck out of me when I have to deal with code that is not only rubbish from a stylistic point of view, but often, more insidiously, contains scientific errors that are a real pain to find due to the poor coding. -- Greg Kamer - Purdue Macromolecular Crystallography tsh@mace.cc.purdue.edu (internet - read every day) xtsh@purccvm.bitnet (bitnet - read very rarely)
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (10/25/88)
In article <5826@vdsvax.steinmetz.ge.com> lamson@sierra.uucp (scott h lamson) writes: > > >Help me here. I work at General Electric Corporate Research and >Development. Probably not one of your smaller companies. We have 300 >Sun's, 3 dozen or so VAX's, an IBM 3081K, and a Convex 210 (220 >soon...). No vendor has come here to talk about Fortran 8x ever >that I have been told about. In order to have an informed opinion, >I subscribe to the ACM Fortran Forum, Until just over a year ago I too was a user. I even became an X3J3 observer to keep informed. >ordered the draft of F8x, 6 copies of Fortran 8X Explained, and have >asked about F8x at most vendor presentations. But the vendors have >not made an effort to publicize the proposed standard here one way or >the other. Bully for you. As for the user groups (DECUS, SHARE, CUG, or others), at >least at our site, the people who might go to them are the systems >managers, not people who (work for a living.. :) ) use fortran in >their work. This is standard just about everywhere. Furthermore the presentations I got reports about were very biased against the standard. The usual presentation was summed up as "lots of new useless features and very costly to implement, and it will be slow". This is what most users who got ANY information at all got. Very few users went to the lengths you did. >On the difficulty of implementing the proposed F8x, I feel that I must >take the word of the experts that it will be difficult. I just think >that it will be worth the cost. For each person-year that goes into >writing a compiler, how many person-years go into people developing >applications using that compiler? Exactly the point propronets have been making. > As for the speed of the compiler, my own opinion is this >is a non-issue. > I must disagree here. Compile speeds are killing VLIW vendors (Cydrome and Multiflow). Many shops spend much of their time developing code, or using code which has parameters coded in (especially memory sizes) which must be recompiled (ABAQUS comes to mind as an example of a production code which employs a program generator to create a program which is compiled linked and then run). Fortunately many of the features of f8x will REDUCE the number of compiles. Dynamic memory, modules (implemented intellegently), etc. The point being that, as a vendor, we are sensitive to compile speeds (because our users are!) >The last time I worried about that was on a RAYTHEON >703, and even then the paper tape reader was slower. I spend a lot >more time reading code than compiling it. That makes many of the >features in modules and module procedures so very important; to get >understandable readable code for complex applications. You can only >worry about efficiency after you have the right answer. True, but newer programmers like their systems to be highly interactive. This is a great appeal of workstations :>). This is not to say that I am against f88 (quite the contrary), just that compile speed is important. The "public review" is not done very well at all (procedurally). Unless the public is well informed, their comments are meaningless (e.g. How many complained about f88 not compiling f77 programs ? ) Furthermore the procedure is biased towards finding fault (no scientific survey simply asks for responses from the public at large... those who are UNhappy respond most often). Furthermore the draft standard is designed as a formal document to be used for compiler writers to work from. This is a very different sort of document from a user guide (like Metcalf and Reid). User's who have never worked with operator overloading and modules can't be expected to decrypt the standing document and comment. Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
psmith@mozart.uucp (Presley Smith) (10/25/88)
In article <5826@vdsvax.steinmetz.ge.com> lamson@sierra.uucp (scott h lamson) writes: > > >> psmith@mozart.uucp (Presley Smith) writes >> Vendors have a way of providing information to their users and collecting >> information from their users. >> I believe that the vendors are in touch with the users and that they >> listen to their user groups. >> We also >> attempt to represent the view of that group to X3J3 in the way we vote. > >Help me here. I work at General Electric Corporate Research and >Development. Probably not one of your smaller companies. We have 300 >Sun's, 3 dozen or so VAX's, an IBM 3081K, and a Convex 210 (220 >soon...). No vendor has come here to talk about Fortran 8x ever >that I have been told about. In order to have an informed opinion, >I subscribe to the ACM Fortran Forum, >ordered the draft of F8x, 6 copies of Fortran 8X Explained, and have >asked about F8x at most vendor presentations. But the vendors have >not made an effort to publicize the proposed standard here one way or >the other. As for the user groups (DECUS, SHARE, CUG, or others), at >least at our site, the people who might go to them are the systems >managers, not people who (work for a living.. :) ) use fortran in >their work. I will respecfully listen to compiler writers from >vendors tell me how difficult the proposed F8x is to implement, that >is their area of expertise, I do physics. But I reject the claim that >any vendor has the right to say their opinions represent the views of >their customers. Certainly that is not the case here, as no vendor >has asked anyone I know about F8x. Each of the companies that you mentioned has a user group. I know that the DECUS group, the CONVEX group, and both of the IBM groups have been involved in providing information on Fortran 8x. Part of the problem that you experienced was that in the U.S., the vendors were not allowed to make copies of the standard and provide that to users directly. You had to order copies of the proposed standard from Global Engineering and pay for those copies. This is due to an arrangement between a part of the ANSI organization and Global. The reason is that there was so much demand for copies of draft standards that it was taking more and more of their resources to copy and mail drafts. They off loaded this effort to Global. Global is a "for profit" corporation. They make their money from selling draft standards. If ANSI allowed each group to copy and distribute those standards, then Global would not make the money they are due under this arrangement. Many members of X3J3 are not happy with this arrangement, but that is the arrangement at the current time. Most users group meetings are not designed for just system managers. But, the vendors and the user groups do NOT have control of who comes to those meetings or control of what information gets passed around in the company when the attendees return. If you know of someone that is in your company and attending a user group meeting, you should talk with that person and get your input to them and should ask for copies of what is distributed at the user group. Obviously not everyone who is interested can go to every user group meeting. Some of the effort that I know about are: 1. DECUS - had a session last year and again a couple of weeks ago on FORTRAN 8x. There are lots of sessions at a DECUS meeting and one must choose to go that session as opposed to another session. We had people that attended both of those sessions and brought back copies of their presentations and resolutions. That information is passed around inside the company to those who have expressed an interest in seeing it. 2. IBM - I don't know about the IBM user groups, but I do know that IBM sent a packet of information to several thousand sites on the FORTRAN 8x issues. Again, IBM does not have the name and address of each user and so that packet was sent to some central person at each site. I suspect that information was not distributed in many cases... 3. CONVEX - Discussed the proposed standard at their 1987 User Group in October, 1987 and again in October, 1988. We provided handouts, etc. for those who attended the session. At the October, 1988 meeting that session was one of the best attended of any session at the meeting. My point in all this is that various vendors and user groups have attempted to provide the public with information on the proposed standard and have encouraged users to discuss the issues with them. Did I talk to everyone that attended our user group about this issue, NO. But, I did discuss it with anyone that was interested enough in the issue to want to talk. I also collected cards from various users that requested more information and provide additional documentation to them on the subject. It's like the current politial debate that is going on. I cannot say that I am representing all the users that we have because there is a diverse set of views amoung our users. I can say that I've talked to numerous users of our equipment and believe that I have a good sense of what those users have told me about their position on the proposed standard. This, unfortunately, is NOT a black and white issue. Also, there is no way that any vendor can discuss this with every user of their equipment. The bottom line is that many of the vendors have attempted to find out what their user base thinks and have tried to provide ways for that user base to provide input. It's certainly not a perfect system. I take some exception to the argument that the vendors are ignoring the input from their users or that the some other group knows better than the vendors what "users" want. The vendors are listening. It's up to the users to make their views known. > >On the difficulty of implementing the proposed F8x, I feel that I must >take the word of the experts that it will be difficult. I just think >that it will be worth the cost. For each person-year that goes into >writing a compiler, how many person-years go into people developing >applications using that compiler? Could it be less than an order of >magnitude? As for the speed of the compiler, my own opinion is this >is a non-issue. The last time I worried about that was on a RAYTHEON >703, and even then the paper tape reader was slower. I spend a lot >more time reading code than compiling it. That makes many of the >features in modules and module procedures so very important; to get >understandable readable code for complex applications. You can only >worry about efficiency after you have the right answer. Complaints about the speed of the compilers many times come from users that are on larger, faster machines. I've heard Cray users complain about the speed of the CFT77 compiler relative to the older CFT compiler... We receive requests continually for faster compilers. In fact, since 1986, we have nearly doubled the speed of our compilers. And, we still have users that want it to be faster...and we are still working on making it faster. That's direct input from our users. I think that people get used to a particular compilation speed and when it's slower than expected, they notice quickly.
lamson@sierra.uucp (scott h lamson) (10/25/88)
In article <74284@sun.uucp> khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) writes: > > As for the speed of the compiler, my own opinion is this > >is a non-issue. > I must disagree here. Compile speeds are killing VLIW vendors (Cydrome > and Multiflow). I haven't used Multiflow's or Cydrome's, so I can't say much about them. I have used two Fortran compilers on the CRAY-2, one of which runs about ten times longer (cft77 written in Pascal) than the other (cft2 written in assembler). I have no problem with cft77's compile times. It has supported more fortran-77 features sooner, and produces something like 20% faster code. So within one order of magnitude, compile time is, for me, not a concern. Functionality and optimized resultant code is just more important. Scott| ARPA: lamson@ge-crd.arpa Lamson| UUCP: uunet!steinmetz!sierra!lamson (518)387-5795| UUCP: uunet!steinmetz!lamson!crd
lamaster@ames.arc.nasa.gov (Hugh LaMaster) (10/25/88)
In article <74170@sun.uucp> khb@sun.UUCP (Keith Bierman - Sun Tactical Engineering) writes: > >I propose that opponents of the standard give specifics. Propoents can >then respond in a reasoned way. Nothing is gained by pointing out that >certain vendors are out to gut the standard, calling members of the >committee ComputerScientists, or claims that physicsts make poor >programmers. > > > > I would like to point out that there are many people out there who accept MOST of the proposed features of the standard without accepting the complete standard. The specific feature that seems to give the most people trouble is that of MODULE. I wonder if everyone could agree that a subset of the new standard which left out the MODULE stuff (or anything which breaks the self-contained nature of fortran subroutines) would be a reasonably "small" and simple to compile language. Many fortrans already support pointers and vector array notation. So, getting back to the original posting: suppose we leave out MODULE. How many people still object? -- Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117
mike@arizona.edu (Mike Coffin) (10/25/88)
From article <5833@vdsvax.steinmetz.ge.com>, (scott h lamson): [regarding speed of FORTRAN compilers] > I have used two Fortran compilers on the CRAY-2, one of which runs > about ten times longer (cft77 written in Pascal) than the other (cft2 > written in assembler). I have no problem with cft77's compile times. > It has supported more fortran-77 features sooner, and produces > something like 20% faster code. So within one order of magnitude, > compile time is, for me, not a concern. Functionality and optimized > resultant code is just more important. Perhaps you would be more concerned if you weren't compiling on a Cray-2? One weakness of the standard (it seems to me) is that it seems to be designed for extremely powerful machines. A lot of FORTRAN code runs on machines several orders of magnitude slower than a CRAY-2. While the difference between compilation times of 10 seconds and 100 seconds may not be enough to worry about, the difference between 2 minutes and 20 minutes --- the same factor of 10 --- is the difference between a quick stretch and a long coffee break. -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2,ihnp4}!arizona!mike Tucson, AZ 85721 (602)621-2858
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (10/26/88)
> >I would like to point out that there are many people out there who accept >MOST of the proposed features of the standard without accepting the >complete standard. The specific feature that seems to give the most >people trouble is that of MODULE. I wonder if everyone could agree >that a subset of the new standard which left out the MODULE stuff >(or anything which breaks the self-contained nature of fortran subroutines) >would be a reasonably "small" and simple to compile language. Many >fortrans already support pointers and vector array notation. > >So, getting back to the original posting: suppose we leave out MODULE. >How many people still object? > MODULE has proven easy to implement in other languages, no reason to believe f88 will entail any difficulty. Lack of module makes creating libraries (using overloading, and abstract data typing , etc.) hard. If EVERYTHING else were accepted, I would tolerate the removeal of MODULE, but I would lobby for it to be implemented anyway. Frankly I don't understand why anyone wants to remove MODULE. Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (10/26/88)
In article <7540@megaron.arizona.edu> mike@arizona.edu (Mike Coffin) writes:
Perhaps you would be more concerned if you weren't compiling on a
Cray-2? One weakness of the standard (it seems to me) is that it seems
to be designed for extremely powerful machines. A lot of FORTRAN code runs
on machines several orders of magnitude slower than a CRAY-2. While the
difference between compilation times of 10 seconds and 100 seconds may
not be enough to worry about, the difference between 2 minutes and 20
minutes --- the same factor of 10 --- is the difference between a
quick stretch and a long coffee break.
Most of the time spent in such a compiler is the optimizer. If you
don't have a fancy vector processor and a complex set of related
functional units, compilation goes very quickly.
The difference between 2 minutes and 2minutes 45 seconds may feel like
forever, but with f88 you might not need such big source files.
Keith H. Bierman
It's Not My Fault ---- I Voted for Bill & Opuslamson@sierra.uucp (scott h lamson) (10/26/88)
>Perhaps you would be more concerned if you weren't compiling on a >Cray-2? > A lot of FORTRAN code runs > on machines several orders of magnitude slower than a CRAY-2. Given the estimates of how long some people say it will take to get production F8x (current draft) compilers on the streets, this may not be a problem. Your opinion may differ, but I don't care about compile time (within one order of magnitude) even though my primary software development environment is a sun workstation. (I guess about two orders of magnitude slower than the Cray-2, but I haven't been actively benchmarking things lately). The language we select as a standard now will be in use from what... 1990 or 1991 up until 2000?? How many machines in 1995 will be slow enough to make compiling F8x a REAL big problem? Scott| ARPA: lamson@ge-crd.arpa Lamson| UUCP: uunet!steinmetz!sierra!lamson (518)387-5795| UUCP: uunet!steinmetz!lamson!crd
bobal@microsoft.UUCP (Bob Allison) (10/26/88)
In article <17070@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov.UUCP (Hugh LaMaster) writes: > > [...] > >So, getting back to the original posting: suppose we leave out MODULE. >How many people still object? >-- Well, at least one of the proposals at the last meeting did just that and it got fairly good support (I would say it was first or second among the plans). To me, this is one of two areas in the current draft which really give me worries: generalized precision is the other. Now, I don't believe generalized precision is difficult to implement, I just believe it is a completely illusory concept. We don't anticipate machines with more than three or four floating point precisions, and, if IEEE has their way, those precisions will be well-defined and portable. So I support defining a couple of data types with specified minimum precisions and leaving it at that (if we defined REAL to be at least 6 digits and some new data type to be at least 14 it seems we will have solved ninety percent of the problem in a portable way. In fact, more portably than generalized precision which will not guarantee that if you ask for 14 digits you will get it). Also, generalized precision has serious problems if different library vendors select different precisions to market their libraries in. I am also worried about array notation on scalar machines: it is true you can get reasonable code on a scalar machine, but it requires very elaborate optimization methods, which a lot of companies do not have the resources to implement. So, in general, I believe that scalar machines are going to do a pretty crummy job on array expressions. I wish we could tighten up the array language a little bit to improve that situation somewhat. But I cannot argue against the value of array operations. Bob Allison
ssd@sugar.uu.net (Scott Denham) (10/26/88)
In article <673@convex.UUCP>, psmith@mozart.uucp (Presley Smith) writes: > (General discussion of user groups and the 8x standard, distribution of the draft standard, and vendor distribution of info deleted) > > 2. IBM - I don't know about the IBM user groups, but I do know that > IBM sent a packet of information to several thousand sites on > the FORTRAN 8x issues. Again, IBM does not have the name and > address of each user and so that packet was sent to some > central person at each site. I suspect that information was > not distributed in many cases... > I don't know about GUIDE, but the FORTRAN project in SHARE is quite active and VERY intersted in the standard. At least 1 session at every SHARE meeting for the last 4 years has been devoted to 8x - at the very least an update from the SHARE rep to X3J3, and this past spring in LA a panel discussion with 5 or 6 members of X3J3 and some very vocal users. As of mid-year, SHARE now has a representative on X3J3 - prior to that SHARE was represented by someone who was also a company rep to that body. Though the represetation was excellent, it was felt that a rep that had no potential conflict between employer/SHARE positions would be better. IBM did distribute a packet of info on the standard, I belive to every site with a FORTRAN license and every individual registered to receive FORTRAN manuals automatically throught their (gag) SLSS system. This information, though, was TOTALY negative towards the standard and did not, IMHO, present a balanced view of the two sides of the argument. Scott Denham Western Atlas Interational Houston TX I speak only for myself, if I speak at all.
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (10/27/88)
In article <2910@sugar.uu.net> ssd@sugar.uu.net (Scott Denham) writes: > >IBM did distribute a packet of info on the standard, I belive to every >.............This information, though, was TOTALY negative >towards the standard and did not, IMHO, present a balanced view of >the two sides of the argument. > This is not only IYHO. This is exactly why many have characterized the x3j3 public responses as being "vendor biased". The information presented to the public was not "high quality". (* sigh *) Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
lamson@sierra.uucp (scott h lamson) (10/27/88)
In article <673@convex.UUCP> psmith@mozart.uucp (Presley Smith) writes: > psmith@mozart.uucp (Presley Smith) writes > I take some > exception to the argument that the vendors are ignoring the input from > their users or that the some other group knows better than the vendors > what "users" want. The vendors are listening. I didn't say vendors maliciously were ignoring user input or made NO effort to solicit user opinion. I did say and maintain that, at least here in GE (and apparently elsewhere), those efforts were ineffective. Because of that, your comments to X3J3 should be either your personal opinion (just like mine are) or possibly Convex Computer Corp's official opinion (if they chose), but should not carry the weight that you are speaking for all Convex users (such as myself). That is the real point I wanted to make, and I hope that's what I said. {now if you want to nit pick, we have only had our convex since march, but that isn't the point since the IBM and DEC machines have been here for a long time.} > It's up to the users > to make their views known. Who do you want me to talk to? If my letter to X3J3 wasn't clear enough, or if the person at Convex I should talk to can't get it, let me know. User groups like DECUS and SHARE will not get enough real fortran users. Better forums would be SIAM, APS, ACS, AIAA, etc. But that raises the issue of who should be publicizing the draft standard, X3J3 members, vendors or ANSI??? Scott| ARPA: lamson@ge-crd.arpa Lamson| UUCP: uunet!steinmetz!sierra!lamson (518)387-5795| UUCP: uunet!steinmetz!lamson!crd
psmith@mozart.uucp (Presley Smith) (10/28/88)
In article <5858@vdsvax.steinmetz.ge.com> lamson@sierra.uucp (scott h lamson) writes: >In article <673@convex.UUCP> psmith@mozart.uucp (Presley Smith) writes: > >> psmith@mozart.uucp (Presley Smith) writes >> I take some >> exception to the argument that the vendors are ignoring the input from >> their users or that the some other group knows better than the vendors >> what "users" want. The vendors are listening. > >I didn't say vendors maliciously were ignoring user input or made NO >effort to solicit user opinion. I did say and maintain that, at least >here in GE (and apparently elsewhere), those efforts were ineffective. >Because of that, your comments to X3J3 should be either your personal >opinion (just like mine are) or possibly Convex Computer Corp's >official opinion (if they chose), but should not carry the weight that >you are speaking for all Convex users (such as myself). That is the >real point I wanted to make, and I hope that's what I said. >{now if you want to nit pick, we have only had our convex since march, > but that isn't the point since the IBM and DEC machines have been >here for a long time.} > Each member of X3J3 is an "individual expert" unless the member declares that the membership is organizational (Per the SD-2). To my knowledge, the only organizational member on X3J3 is IBM. I certainly do not claim to represent the CONVEX user base. I have certainly talked to many in the user base at various meetings, etc. and have collected their input on the subject. As with any issues of this magnitude, there are many differences of opinion. I'm sure that the vendor efforts to obtain the opinions of their users are not always effective. My point is that I've seen lots of criticism that the vendors are ignoring the "user" input or that some other person or group of people is more "in tune" with the "user's" desires. The users had their opportunity for input during the public comment period. And, about 400 provided their input. Many of the vendors have attempted to obtain the input from their user base also. >> It's up to the users >> to make their views known. >Who do you want me to talk to? If my letter to X3J3 wasn't clear >enough, or if the person at Convex I should talk to can't get it, let >me know. > You did exactly the right thing. Your comment is Number 321 in the public review. The X3J3 committee will consider your comments along with the other 396 comments that were received and attempt to come to a consensus on what changes should be made to the proposed standard to address the public input. Each member of X3J3 should have a copy of your comment and all the other comments that have been received. Your comment is quite clear and well thought out. I note that in your public comment, you commented on the public review process and the fact that "computer vendors claimed to be speaking 'for their users.' I urge the committee not to accept any such nonsense from any vendors who might make such claims." (Page 3 of your public comment.) I totally agree with you. I also don't want the committee to accept such nonsense from some of the USERS on the X3J3 committee who claim to speak for "majority" the users. They, like the vendors, can speak only for themselves or for their company and not the user community as a whole. I don't believe that any vendor or any other user can accurately represent EXACTLY your views on all issues before X3J3. >User groups like DECUS and SHARE will not get enough real fortran >users. Better forums would be SIAM, APS, ACS, AIAA, etc. >But that raises the issue of who should be publicizing the draft >standard, X3J3 members, vendors or ANSI??? I am certainly believe that the proposed standard would have gotten a wider review had it been published some of the various groups that you mention. Unfortunately, the ANSI rules did not allow that to happen.
bobal@microsoft.UUCP (Bob Allison) (10/28/88)
In article <74566@sun.uucp> khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) writes: >In article <7540@megaron.arizona.edu> mike@arizona.edu (Mike Coffin) writes: > > > Perhaps you would be more concerned if you weren't compiling on a > Cray-2? One weakness of the standard (it seems to me) is that it seems > to be designed for extremely powerful machines. A lot of FORTRAN code runs > on machines several orders of magnitude slower than a CRAY-2. While the > difference between compilation times of 10 seconds and 100 seconds may > not be enough to worry about, the difference between 2 minutes and 20 > minutes --- the same factor of 10 --- is the difference between a > quick stretch and a long coffee break. > >Most of the time spent in such a compiler is the optimizer. If you >don't have a fancy vector processor and a complex set of related >functional units, compilation goes very quickly. > >The difference between 2 minutes and 2minutes 45 seconds may feel like >forever, but with f88 you might not need such big source files. >Keith H. Bierman >It's Not My Fault ---- I Voted for Bill & Opus Ah, but this is precisely the problem: on a small scalar machine, an optimization phase is just as time-intensive as on a Cray, but the array language reduces the amount of optimization necessary on a Cray (well, a little) and greatly increases the amount of optimization necessary on a scalar machine. "If you don't have ... a complex sex of related functional units": this is the same guy who couldn't understand why anyone was against MODULEs, I believe (if not, accept my apologies; but the point is still valid). Also, run-time performance will necessarily decrease, since I can't figure out how to do compile-time analysis of an array statement such as: A = RESHAPE(ESHAPE(A),TRANSPOSE(SPREAD(B,3,I))) (Complete nonsense, but it makes the point that at compile time I have no idea what the size of intermediate array expressions will be). So, while I am in favor of the concept of array operations, I want people to realize it will not be a freebie, and I want to try to reduce the possibility of statements like the above popping up. Bob Allison
bobal@microsoft.UUCP (Bob Allison) (10/28/88)
In article <5838@vdsvax.steinmetz.ge.com> lamson@sierra.uucp (scott h lamson) writes: > [...] >be a problem. Your opinion may differ, but I don't care about compile >time (within one order of magnitude) even though my primary software >development environment is a sun workstation. (I guess about two >orders of magnitude slower than the Cray-2, but I haven't been >actively benchmarking things lately). >The language we select as a standard now will be in use from what... >1990 or 1991 up until 2000?? How many machines in 1995 will be slow >enough to make compiling F8x a REAL big problem? > Well, you may not care about compile time, but what about execution time. I can personally guarantee that, if you use array expressions, running any reasonable 8X program will be at least 25% slower than an equivalent program written in 77 (to avoid an often belabored point: if such a program can be written in 77). I can make this statement with confidence for FORTRAN compilers on the PC, probably until at least 1995. Many other scalar machines will be in the same boat. I agree that machines will speed up by more than 25% in the interim, but most people don't buy a machine which runs 25% faster just so their software can run as fast as it used to. They buy the machine so THEIR software runs 25% faster. Bob Allison
mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel) (10/29/88)
In article <5833@vdsvax.steinmetz.ge.com> lamson@sierra.uucp (scott h lamson) writes: > >... I have used two Fortran compilers on the CRAY-2, one of which runs ^^^^^^ !! >about ten times longer (cft77 written in Pascal) than the other (cft2 >written in assembler). [stuff deleted] > So within one order of magnitude, >compile time is, for me, not a concern. Functionality and optimized >resultant code is just more important. Perhaps there's a connection here? :-) Matt K mbkennel@phoenix.princeton.edu
lamaster@ames.arc.nasa.gov (Hugh LaMaster) (10/29/88)
In article <1128@microsoft.UUCP> bobal@microsoft.UUCP (Bob Allison (uunet!microsoft!bobal)) writes: >Well, you may not care about compile time, but what about execution time. >I can personally guarantee that, if you use array expressions, running >any reasonable 8X program will be at least 25% slower than an equivalent >program written in 77 (to avoid an often belabored point: if such a Well, I wasn't going to butt in on this, but, I don't follow this. On the Cyber 205 at least, when the compiler recognizes array constructs (I don't mean Q8 calls for those in the know, but rather, implicit and explicit vector constructs) it generates optimal code. On many newer microprocessors, there will be a significant advantage to optimally pipelined code, and it is easier to generate optimal code for array constructs when the array operations are already defined. A previous poster gave an example that used vector temporaries. No problem that I know of. You just allocate space on the runtime stack. Depending on what kind of machine it is you are talking about, you may use an intermediate representation that preserves the explicit vectors, and copies the vector temporaries on the stack. Then again, if you have a scalar machine, you may not. I just don't see why it is going to be so hard to generate code for scalar machines as some people have been saying. My experience is that it works the other way... -- Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (10/29/88)
In article <1127@microsoft.UUCP> bobal@microsoft.UUCP (Bob Allison (uunet!microsoft!bobal)) writes: >> >>Most of the time spent in such a compiler is the optimizer. If you >>don't have a fancy vector processor and a complex set of related >>functional units, compilation goes very quickly. >> >Ah, but this is precisely the problem: on a small scalar machine, an >optimization phase is just as time-intensive as on a Cray, but the array >language reduces the amount of optimization necessary on a Cray (well, >a little) and greatly increases the amount of optimization necessary on >a scalar machine. No Bob it isn't even close. There is no need to do massive instruction scheduling, dependency analyses nor most of the fun things which crop up in "real machine optimizers". Also interprocedural analysis is much less interesting (since the cost of a contex switch is vastly cheaper, reg saves, breaking the pipelines, and dozens of other effects). If this were true compiles which take minutes with my Lahey compiler (or seconds on a Sun4 with our compiler) would take hours (viz. the cydra 5 compiler, pathalogical cases). >"If you don't have ... a complex sex of related functional units": this >is the same guy who couldn't understand why anyone was against MODULEs, >I believe (if not, accept my apologies; but the point is still valid). No you're right. I'm that guy. Look at any Modula II implementation; they compile very quickly, and their internal organization (in some cases) is quite clean. Most are the products of small groups, working in a very limited time. F88's modules should not be any harder to implement. > >Also, run-time performance will necessarily decrease, since I can't figure >out how to do compile-time analysis of an array statement such as: > >A = RESHAPE(ESHAPE(A),TRANSPOSE(SPREAD(B,3,I))) > >(Complete nonsense, but it makes the point that at compile time I have >no idea what the size of intermediate array expressions will be). So, while >I am in favor of the concept of array operations, I want people to realize >it will not be a freebie, and I want to try to reduce the possibility of >statements like the above popping up. a) I strongly suspect that such knowlege exits...among those who have had to cope (cdc, cray, convex, compass, etc. also among those who have implemented apl-like languages). b) for a simple scalar machine why do you really care ? dynamic memory is already required for f88 (and C, and Modula, and nearly all operating systems, and etc.). Deferring such things to run time hurts high performance machines, not "simple scalar processors". khb Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (10/29/88)
In article <1128@microsoft.UUCP> bobal@microsoft.UUCP (Bob Allison (uunet!microsoft!bobal)) writes: >>be a problem. Your opinion may differ, but I don't care about compile >>time (within one order of magnitude) >> > >Well, you may not care about compile time, but what about execution time. >I can personally guarantee that, if you use array expressions, running >any reasonable 8X program will be at least 25% slower than an equivalent >program written in 77 (to avoid an often belabored point: if such a >program can be written in 77). I can make this statement with confidence >for FORTRAN compilers on the PC, probably until at least 1995. Many other >scalar machines will be in the same boat. 1) I doubt that it will take Lahey and his merrie crew anywhere near that long. 2) Those working in the realm of high performance are well aware of the fact that 5-25% of the code consumes 75-95% of the cycles (e.g. a famous structural code, in a slightly outdated version, spent 97% of its time in 7 lines of code on a cydra 5). If our vendor of choice (sun of course :>) can't optimize the array facilities, the user uses the nifty profiling tools to determine where the glitch is, and rewrites a few lines of code. Those who balk at such fun and games run slower, chose a different vendor, or buy different machines. But when you get to the world of high performance, this is ALWAYS necessary to get peak performance. >I agree that machines will speed up by more than 25% in the interim, but >most people don't buy a machine which runs 25% faster just so their software >can run as fast as it used to. They buy the machine so THEIR software runs >25% faster. True. But by the time f88 is widely available machines can be 2x as fast. Most user's of PC's now have 80286's or 8088's, running at moderate clocks. 25mhz+ 80386/7 machines are already available and do pretty well. (* RISC chips do even better *). The real point is will it reduce the cost of developing software. (* yes it will *), this cost is much higher than the productively lost by having to hand optimize a few modules, in the most critical applications. >Bob Allison Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
bill@hcx2.SSD.HARRIS.COM (10/31/88)
As regards representation of users: How many times have your Senator or Congressman asked you PERSONALLY what your opinion is on an issue coming up for a vote in the Senate or the House? (I would wager the number is very small, close to zero.) Yet, they purport to represent you on each of those issues. My point is that no member of X3J3, vendor or otherwise, can ask EVERY user his/her opinion on every issue, or even a significant subset of the issues. Most of us have tried, through surveys, user groups, various discussion forums, etc., to get a "representative" sample of opinions. Unless a user is totally alone in his stand on a particular issue, theoretically his/her voice has been heard by someone somewhere sometime. Just because you haven't been asked personally, that doesn't mean you are unrepresented. Remember: a good democratic government requires participation by the electorate, via letters to Congressmen as well as at the ballot box. The same applies to ANSI standards: YOU are responsible for getting your voice heard. Don't wait for someone else to do it for you; if you do, don't be surprised that your views aren't incorporated. "Ask not what the Standard can do for you, ask what you can do for the Standard."
bill@hcx2.SSD.HARRIS.COM (11/01/88)
As regards compile time and the array language:
The gentleman who thinks that optimizers only do vectorization is just dead
wrong. We (Harris) have a very good optimizer, yet we don't have a vector
machine at all. YOU may not be concerned about compile speed, but our
customers certainly are. Consider that our USERS (not us) came up with a
feature known as DATAPOOL, which is a variant of COMMON. The difference is
that the location of variables within a DATAPOOL is not specified to the
compiler, but rather to a separate program; thus references to DATAPOOL
variables are resolved at link time, rather than by the compiler as an
offset into a COMMON block. The chief advantage is that one can rearrange
the variables within the DATAPOOL without recompiling all the program units
that reference them; one merely relinks the program. Our users invented
this because (re)compilation was too slow!
As for the array language, let me offer a concrete example. Consider
the following F77 fragment:
S = 0
DO 10 I = 1,N
DO 20 J = 1,M
B(J,I) = C(I,J)
20 CONTINUE
K = I + 100
S = S + A(K)
10 CONTINUE
Now this code was obviously written by a clever programmer, as the
array A has no relationship to B and C except that it has the same
number of elements. However, this programmer noticed that he could
save the outer loop overhead by putting the summation of A inside
the outer loop with the transposition of C into B. Now consider the
equivalent F8x code:
B(1:M,1:N) = TRANSPOSE(C(1:N,1:M))
S = SUM(A(100:N+100))
Note that it is impossible for the _programmer_ to use the nice
array-language facility AND tell the compiler that it is okay to
jam two of the (implied) loops together. The analysis required
of the compiler to figure this out (in the general case) is roughly
equivalent to that required to vectorize the original F77 code.
On a scalar machine, then, the F8x code will run slower; how much
depends on the ratio of the loop overhead to the actual computation.
(Clearly, in this example the loop overhead must have been significant,
or the programmer wouldn't have written the F77 code as he did.)
This example, while real enough, is not nearly as complicated as what one
typically encounters in real applications. Just as most of the analysis
for vectorization involves making sure that the vectorized code gets the
same answer, the same is true for the "scalarization" of array-language
code. The BIG difference is that vectorizers usually run on high-end
machines, whereas the "scalarizers" will be running on low to medium-sized
machines. The hit on compile time will be much more noticeable, if the
analysis is done; if it isn't done, then the hit on execution speed will be
just as noticeable. Either way, the user loses.hirchert@uxe.cso.uiuc.edu (11/05/88)
Bill Leonard(bill@hcx2.SSD.HARRIS.COM) writes about the cost of using the Fortran 8x array notation on a scalar processor. First, I would like to pick a couple of nits: >As for the array language, let me offer a concrete example. Consider >the following F77 fragment: > S = 0 > DO 10 I = 1,N > DO 20 J = 1,M > B(J,I) = C(I,J) > 20 CONTINUE > K = I + 100 > S = S + A(K) > 10 CONTINUE > Now consider the >equivalent F8x code: >B(1:M,1:N) = TRANSPOSE(C(1:N,1:M)) >S = SUM(A(100:N+100)) ^^^ not that it matters, but this should be 101. >(Clearly, in this example the loop overhead must have been significant, >or the programmer wouldn't have written the F77 code as he did.) On a number of scalar machines I have worked on, the separate loop version might actually be faster (due to locality of reference, instruction caches, and other such effects). Even on machines where the combined loop version is faster, the difference is rarely significant in absolute terms, so that its significance in relative terms is typically important if this computation in embedded in yet another loop so that a significant part of the overall program is spend doing this operation. My experience suggests that while there are a few programmers that would evaluate these kind of issues, most do not. The most likely reasons for the programmer to have combined the loops are . that the effective sizes of A, B, and C are related and the programmer wishes to insure that the size computed on is the same . that the programmer has been told it is more efficient to combine loops and does so without verifying that this is true for his program on his machine . that it takes one less DO statement and one less CONTINUE statement to write the combined loop The last reason (compact notation) may well be the most likely. >This example, while real enough, is not nearly as complicated as what one >typically encounters in real applications. If you mean that the most complicated statement in a typical application would be more complicated you may be right. If you mean that the typical statement in a typical application would be more complicated, I disagree; most applications consist primarily of a large number of very simple statements. > Just as most of the analysis >for vectorization involves making sure that the vectorized code gets the >same answer, the same is true for the "scalarization" of array-language >code. Here I am in total agreement. In fact, this will be true of register-based vector processors (such as those from Cray Research or Alliant) as well. The conversion between parallel notation and efficient sequential notation involves reordering of operations the must be analyzed for validity. For the most part, it doesn't matter which direction you are converting or how far, the basic analysis is the same. As I see it, array notation offers three benefits: . It is a more compact notation (and thus, for some people, a more convenient notation) for expressing many common operations on arrays. . Its basic semantics are more highly parallel (at the cost of higher temporary storage usage). In many cases, analysis can be done to determine the equivalence of this parallel notation and the traditional sequential notation. In cases where this analysis either cannot be done or where it is not done because of cost, the parallel notation will produce better performance on machines which support parallel or overlapped evaluation. (Originally, all the parallel machine were top of the line machines. Today, there are a number of "middle tier" machine with these properties and we are beginning to see add-on boards with these properties for machines in the workstation class. In other words, parallel and overlapped execution issues are affecting an ever increasing fraction of the Fortran community.) . The array notation puts under processor control a number of aspects of array computation where getting good performance is processor dependent. For example, when doing array operations on a two-dimensional array, there are a number of factors the go into the decision of which loop is the inner loop, including locality of reference, memory bank conflicts, and relative length of the two loops. The relative importance of these factors varies from processor to processor, so on one machine it may be best one way while on another machine it may be better the other way. Thus, a sequential statement of the operation will be optimal for only one of those machines. The parallel notation lets the processor choose the inner loop and thus be optimal one both machines. It also has costs: . It adds to the complexity of expression analysis, etc. . In cases where the parallel-sequential equivalency analysis can not or is not done, the parallel notation will produce worse performance on purely sequential machines. (Not necessarily significantly worse, but definitely worse) . In the added factors under the processor's control, if the analysis is done incorrectly (or not done), the wrong decision may be made, producing worse code than what the programmer could have written using the sequential notation. On some machines, the benefits outweigh the costs. On others, the costs outweigh the benefits. From the number of vendors already implementing the array notation, it is clear that the array notation is likely to be available on machines where the benefits outweigh the costs. Given that, I ask the following questions: . Do we want to standardize the notation available on such machines (to improve portability among such machines)? . Is it likely that people working on machines where the costs outweigh the benefits will nevertheless wish to import programs orginally written on machines where the array notation is available? Finally, I might note that even if the array notation is adopted as part of the Fortran standard, it would be possible to leave it out of your compiler if you provide a separate tool that converts the parallel notation to a sequential notation accepted by the compiler. (In this case, the "standard-conforming processor" would be the combination of the compiler and the tool.) On some machines this might be a beneficial implementation strategy: . When importing programs written using the array notation, the cost of analyzing that notation to sequentialize could be paid just once. . When writing codes on the machine, the user could decide whether or not to use the array notation by deciding for himself whether the notational benefits justified the cost of the extra analysis on each translation cycle. Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications