Path: utzoo!utgpu!watmath!att!dptg!rutgers!usc!ginosko!uunet!convex!mozart!psmith From: psmith@mozart.uucp (Presley Smith) Newsgroups: comp.lang.fortran Subject: Re: Two Fortran Standards Message-ID: <1631@convex.UUCP> Date: 30 Aug 89 20:20:27 GMT References: <282@unmvax.unm.edu> <303@unmvax.unm.edu> <1598@convex.UUCP> <123897@sun.Eng.Sun.COM> <1624@convex.UUCP> <123964@sun.Eng.Sun.COM> Sender: news@convex.UUCP Reply-To: psmith@convex.com (Presley Smith) Organization: Convex Computer Corporation, Richardson, Tx. Lines: 86 In article <123964@sun.Eng.Sun.COM> khb@sun.UUCP (road) writes: >In article <1624@convex.UUCP> psmith@convex.com (Presley Smith) writes: >> >> horror stories about using f8x with f77 existing code ... > I said: "To use the new facilities, YOU will have to modify and, in some cases, rewrite your code." I don't believe that translates to "horror stories about using f8x with f77 exiting code..." If you are going to respond to what I said, please at lease quote what I said correctly!!!! What I said corresponds very well with what you said: >The only changes necessary were to >the variable declarations. No changes to the body of the code was >required. You DID have to change the code! You did NOT have to rewrite the code. >I do not believe that it will be very difficult to move the vast >majority of existing codes to f8x ... I have only seen a few million >lines, so perhaps I am missing something. If you want to keep the code in FORTRAN 77 syntax, then there are NO changes to be made. If you want to use modules, array notation, pointers or many of the other 8x features, then YOU are going to have to rewrite at least portions of your code. Those are the facts. > >.... >>some are currently planning to rewrite their codes in C or Ada >>instead. > >Those of us who have tried the exercise see a good slowdown from 20% >to 500% depending on machine. > Sounds like you have a problem in your compilers. We see no slowdown on our machine in executable code that is well written in either C or Ada. We see a slowdown in compiler speed in Ada due to the dependent compilation model (similar to 8x modules) but again, no slowdown in the executable code. >> >>You should try Ada, Keith. You'd love it and it's available today. > >I have. I do not think it suitable for mathematical programming, such >as I used to specialize in. We have customers who are very successfully using Ada in "mathmetical programming." In fact Ada math libraries are available from several companies including QTC in Oregon that work quite well. >> >>Ada was DESIGNED to have all the capabilities you want in FORTRAN. > >Not by a long shot. Furthermore features that it should have for real >time programming simply don't work (try to write code which executes >every 100ms, say. Or take Guy Steele's old challenge to write a >correct device driver). I don't believe that Fortran 8x solves the realtime problems... What in Fortran 8x addresses the realtime problem? I certainly would NOT write a device driver in FORTRAN 77 or FORTRAN 8x. FORTRAN is NOT a language that is suited to writing device drivers. Most people write device drivers in C or assembly langauge. You just made the argument above the Ada was not suitable for mathematical programming... why do you think that Fortran, the FORmula TRANSlation language, is suitable for writing device drivers? Why would we WANT FORTRAN to be suitable for writing device drivers??? >>They were not ADDED ON as in Fortran 8x. In Ada, all the features are >>integrated and all work as one language. > >F8x as it existed in 1985 was much more suited to my needs. As it >stands it is still much better than Ada. My Ada group does not feel that Fortran 8x is better than Ada, but I guess that's getting into the area of religion. Everyone to their right to their own opinion on the subject. Keith, maybe you could implement that 1985 version of Fortran 8x and then you'd be happy...