bill@hcx2.SSD.HARRIS.COM (04/17/89)
Having been present at the X3J3 meetings over the past year when most of the "WG5 vs. U.S." debate was going on, I will strongly differ with Keith Bierman on what the major topic was. It was NOT, repeat NOT, pointers! The _form_ of pointer was hotly debated, yes. But the major source of contention was not what to ADD, it was what to DELETE from FORTRAN/8x. I and others on the committee have been trying to pare down the language to reduce its cost to users. Much of the public comment complained about the size and/or complexity of FORTRAN/8x, and at least some of us think X3J3 should respond intelligently to those complaints. (Let's debate that some other time.) However, WG5 members ABSOLUTELY REFUSED to give up anything of consequence. (In fact, several WG5 members literally threatened X3J3 with a NO vote based on a single issue: removing MODULE/USE.) Instead, they insisted on adding (stream I/O, pointers, a bit data type). Mostly, they got everything they wanted. I think one international standard for FORTRAN is a wonderful idea, but saying so doesn't make it possible. Where is it written that all FORTRAN users want the same things from FORTRAN? It has become evident to me that there are several, very vocal, groups of users, both in the U.S. and in other countries, who have radically different views on what FORTRAN should be. It also appears to me that the majority of American users fall into a different group than the majority of, say, European users. That, I believe, is the fundamental reason for the present difficulties. No matter what happens, some group(s) of FORTRAN users are going to be dissatisfied. But I find it very strange that an American standard (remember, the A in ANSI stands for American) should dissatisfy the majority of American users. I also find disturbing the fact that many users from U.S. Government labs and departments (including the U.S. Army) expressed strong disapproval of this standard, yet ANSI seems intent on adopting it. Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.harris.com or hcx1!bill@uunet.uu.net
maine@drynix.dfrf.nasa.gov (04/18/89)
In article <44400035@hcx2> bill@hcx2.SSD.HARRIS.COM writes: > I think one international standard for FORTRAN is a wonderful idea, but > saying so doesn't make it possible. Where is it written that all FORTRAN > users want the same things from FORTRAN? It has become evident to me that > there are several, very vocal, groups of users, both in the U.S. and in > other countries, who have radically different views on what FORTRAN should > be. I strongly agree with the statement that different users want very different things out of Fortran. That is what drives the language to become "large" enough to encompass many of these wants/needs. I strongly disagree that this is reason to segregate Fortran into separate languages or whatever. This would defeat much of the purpose of standardization. Standards not only help portability of codes between machines; they also help portability of code between applications and thus integration of applications. I have programmed in Fortran as my primary language (I do mostly numerical engineering applications) for nearly 20 years. It is still my preferred language for engineering work. But over the last 5 years or so, the language has seemed increasingly inadequate for many of the applications that arise. I've been driven to work in Pascal and c (and starting to be pushed into Ada). I really want to get back to doing most of my work in a single language. This has a lot of very concrete advantages. I'll avoid elaborating my list of what ought to be in that language except to say that Fortran 8x looks like a lot better candidate than any of the others. I'll place myself in the camp that wants, more than any specific feature, a Fortran that is broad enough to meet all (well, ok, how about most?) of the needs within the context of a single integrated language. I'm perfectly willing to give up a modest amount of performance if that's what it takes; it would save a lot more of my time than it would cost of the computer's and I happen to think my time is more important (biased of me, I'm sure). Yes, I am aware that there are people that disagree with these priorities, sometimes vehemently. There was a time when the costs of a language large enough to encompass all these needs was unacceptably large. I believe that time has past. I don't doubt that it will take a lot of work to make a good Fortran 8x compiler. But I also don't doubt that it can be done. And I also don't doubt that it will be worth the work. We obnoxious (oops, I was hoping you wouldn't guess that :-)) users spend a lot more time using the compiler than it takes to develop it. I bet I could name (but I won't) some vendors that will make good Fortran 8x compilers, and I bet they will sell plenty of them. > of consequence. (In fact, several WG5 members literally threatened X3J3 > with a NO vote based on a single issue: removing MODULE/USE.) Instead, I guess it illustrates some of those differences between different users. Module/use is high on my list of important features. Not the absolute top (which is probably reserved for data structures), but its up there. > majority of American users. I also find disturbing the fact that many > users from U.S. Government labs and departments (including the U.S. Army) > expressed strong disapproval of this standard, yet ANSI seems intent on No question that many such users have expressed strong disapproval - and I'm not going to suggest that they are uninformed or any other such questionable generalization. I'm sure many of them have good reasons for their disapproval. But I'm also sure there are users in U.S. government labs that strongly approve of the standard (or at least enough of it that they are willing to accept the rest as a necessary compromise to get something out). I'm very sure of this because I am one such user. (Insert standard disclaimer about speaking only for myself). Richard Maine maine@elxsi.dfrf.nasa.gov
khb@chiba.Sun.COM (chiba) (04/19/89)
In article <44400035@hcx2> bill@hcx2.SSD.HARRIS.COM writes: > >Having been present at the X3J3 meetings over the past year when most of >the "WG5 vs. U.S." debate was going on, I will strongly differ with Keith >Bierman on what the major topic was. It was NOT, repeat NOT, pointers! >The _form_ of pointer was hotly debated, yes. But the major source of >contention was not what to ADD, it was what to DELETE from FORTRAN/8x. Upon reflection, I agree with Bill that this has been the key debate. I personally do not think there was anything in the proposal that could be usefully deleted. Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist -- I Voted for Bill & Opus | Languages and Performance Tools. (* strange as it may seem, I do more engineering now *)
khb%chiba@Sun.COM (Keith Bierman - SPD Languages Marketing -- MTS) (04/25/89)
In article <44400037@hcx2> it is written: > ....lots of stuff deleted >> the last 5 years or so, the language has seemed increasingly inadequate >> for many of the applications that arise. I've been driven to work >> in Pascal and c (and starting to be pushed into Ada). > >... more deleted > > I don't believe everyone should be put in the same cubbyhole and >forced to use one language. True, but everyone who is doing _primarily_ numeric computation (no matter what the application area (biology, physics, etc.) SHOULD be using the same langauge. We don't have _radically_ different matrix theory for each field.... (all the linear algebra holds, why shouldn't our libraries ?) Almost everyone has interlanguage horror stories.... simply asserting that we should have a large pool of "small" languages is not adequate for 90% of the folks _I_ deal with... > >But what about those users for whom performance is THE most important >feature? These folks really, really benefit big from good libraries. With easy to learn and use interfaces; with really ugly stuff hidden. The proposed standard has much to serve library writers....library users don't need to know how it is done, just that it is done well. >that met their needs. They (at least, many of them) ARE NOT willing to >give up performance. Again, you show a tendency to want to force everyone >to accept the same language, just because you think it is best. How would >you like it if someone else said, "You must eat nothing but wild porcupine, >because I like wild porcupine."? Or if someone told me I have to write every algorithm from Givens rotations to Singular value decompositions sixteen different ways for EACH machine ? >Many times I have heard the statement that "FORTRAN must evolve or die". >Rubbish. First, it presumes that FORTRAN dying is a bad thing; if no one >uses it, it certainly will die, but then, who will miss it? If many people >continue to use it, then it won't die. Second, it presumes that FORTRAN >must "compete" with other languages. Again, rubbish. Do hammers compete >with axes? No, but a hand____ does compete with an electric ____ (fill in one of the following: saw, drill, screwdriver, your favorite garage tool). > If someone complains that his axe doesn't make a very good >hammer, would you try to modify the axe? I hope not. Languages are tools; >they are invented because there is a need, and no other language serves >that need. I think the need for a language like FORTRAN/77 still exists, >and so that language should continue to exist. If there is a need for a >language like FORTRAN/8x, then by all means, let it be, but don't take away >a tool that is still very much needed. FORTRAN/8x should be treated like >any new language; it should stand or fall on its own merits. The lure of f8x is that it allows one to leverage the huge existing software base. An entirely new language could be cleaner, but much less useful. > >I personally applaud the approach taken by the PL/1 standards committee. >They said, in effect, "Standardize the language the first time, and revise >it once to correct any errors, then leave it alone." Good example. PL/1 cost implementors a bundle, and required a huge user investment...which is now mostly worthless. Let's try to _not_ emulate the mistakes of others. Cheers Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *)
khb%chiba@Sun.COM (Keith Bierman - SPD Languages Marketing -- MTS) (04/25/89)
In article <50500124@uxe.cso.uiuc.edu> it is written: > >As to your second sentence first, it appears that right now, after some >changes, that it is proposed to keep all of Fortran 77. HOWEVER, >in the draft that was sent out for comment, it was proposed that >all of Fortran 77 would be in F8x BUT that one would have had to >assume that a long list of things (like common, equivalence, and >ordinary do loops(!)) would disappear from F9x. No. What had been proposed was that certain features be labeled as CANDIATES for eventual removeal. The most aggressive schedule would be marked in f8x, moved to a seperate heap in f9x, and possibly deleted for real in f20xx. Since the actions of the current committee do not bind the future committees this could still happen, but without the extra decade of warning and debate (but it will be much harder for some features, because they have been closely integrated in with new features.. which would have been "cleaner" without the old baggage). Furthermore it was simply not possible for the current committee to ensure that the future committees would have _ever_ done the actual deletion. > >The problem with a gigantic language is that if one wants to write >efficient programs, one MUST understand not only the syntax of the >whole language, but also the relative efficiency of doing things >in different ways. It is just not realistic to propose that people >understand or use a subset. In fact, most people do just that. Once the efficient ways become known, and probably published in books by clever folks (say, for example, Metcalf, Brainard, Wagoner) many people will never learn all the sub-optimal ways one _could_ code. The reason that some folks argued for labeling things for eventual deletion is that there was/is a feeling that the "language is too large". One way to make is smaller is to leave out (arguably) needed features. Another is to remove old disused features. What seems to have upset many people is that features marked as _eventually_ removeable are currently in heavy use....but if the original schedule was followed the "dirty deed" would be a good thirty years off... now how many of us have codes which have NEVER been modified since 1959 ? Cheers. -- Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *) Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *)
mcdonald@uxe.cso.uiuc.edu (04/26/89)
>> >>But what about those users for whom performance is THE most important >>feature? >These folks really, really benefit big from good libraries. With easy >to learn and use interfaces; with really ugly stuff hidden. The >proposed standard has much to serve library writers....library users >don't need to know how it is done, just that it is done well. One cannot quibble with "Those folks really, really benefit from good libraries." Pray tell me, where can I find some of these? The only commercial or common public domain library routines I have found optimal for my use are the routines "tred2" and "tql2" from the EISPAC library. Can anyone recommend a library routine for integrating differential equations of the sort I use that is better than the sixth order hybrid Gear fixed step size integrator I now use? I haven't found one to date. (A typical use would be 24 coupled equations with the subroutine evaluating the derivatives filling 300 lines with exp's, sqrt's, and tanh's. The solutions are quasi-periodic.) Doug McDonald
khb@fatcity.Sun.COM (Keith Bierman Sun Tactical Engineering) (04/29/89)
In article <50500126@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > > >One cannot quibble with "Those folks really, really benefit from >good libraries." Pray tell me, where can I find some of these? IMSL and NAG are famous commercial libraries. QTC is good for those porting codes to/from array processors (but lacking in real math). NASA has several interesting libraries, JPL's MATH77LIB among others. BCSlib is quite good, and I can point those interested to a Kalman filter library. >The only commercial or common public domain library routines I have >found optimal for my use are the routines "tred2" and "tql2" from the >EISPAC library. Can anyone recommend a library routine for integrating >differential equations of the sort I use that is better than the >sixth order hybrid Gear fixed step size integrator I now use? Hopefully someone more involved with integration techniques can say something sensible. From a performance standpoint, EISPAC is very far from optimal. Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *)
esalbert@s3dawn.ARPA (Eric Salberta) (05/04/89)
In article <50500126@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >One cannot quibble with "Those folks really, really benefit from >good libraries." Pray tell me, where can I find some of these? >The only commercial or common public domain library routines I have >found optimal for my use are the routines "tred2" and "tql2" from the >EISPAC library. Can anyone recommend a library routine for integrating >differential equations of the sort I use that is better than the >sixth order hybrid Gear fixed step size integrator I now use? >I haven't found one to date. (A typical use would be 24 coupled equations >with the subroutine evaluating the derivatives filling 300 lines >with exp's, sqrt's, and tanh's. The solutions are quasi-periodic.) > >Doug McDonald One place that you might look is the book "Numerical Recipes: The Art of Scientific Computing" by W. H. Press, B. P. Flannery, S. A. Teukolsky, and W. T. Vetterling. This book has several coupled differential equation solvers, and while Gear is not one of them, they are (in general) not limited to fixed step sizes. I don't know if they would be better than Gear for your application, but it couldn't hurt to look. This book is very good at explaining the traps and pitfalls of different methods, and has become the first place that I look for many problems of this type. Hope this helps. Eric R. Salberta (esalbert@scubed.com)