Fortran Vs C, C++, C#
in [Fortran]
|
Prev: practice online trading. platinum online trading. online trading worldwide. online trading which is best
Next: variant data type
From: Richard Maine on 14 Jul 2010 13:34 <nmm1(a)cam.ac.uk> wrote: > In article <i1knum$p0s$1(a)news.eternal-september.org>, > Lynn McGuire <lmc(a)winsim.com> wrote: > >> Fortran does not go in for mandatory enforcement of programming style by > >> the language spec. It is much more about providing the programmer with > >> options. Many of those style options can be verified/enforced if that is > >> one's inclination. > > > >One area where we have had many problems is with programmers > >failing to declare variables. I also believe that the mandatory > >enforcement of variable typing in C++ is a big plus. > > That's essentially trivial to enforce in Fortran, provided that you > have adequate project management. That was the point I was trying to make - that Fortran doesn't itself mandate style, but that some style elements are easy enough to enforce. Of course, if you want a style to be enforced but you don't have management backing to do the enforcement, then maybe the lack of options might be considered a plus in a way... until the lack of options forces you into some choice that isn't one of the ones you wanted. For example, I like many things about the F subset, but I find other parts of it so annoying as to be unacceptable. As far as I can tell, that's a fairly common reaction to F, with different people reacting to different parts. In many ways, the F subset is just enforcement of a particular set of style choices, with the enforcement built into a compiler. I'm of the opinion that looking to a language spec to make up for management failures is not likely to work out well. I think of language specs as facilitators rather than as straightjackets. They can facilitate making the straightjacket if you want. I find it slightly ironic, but then also understandable, that Lynn seems to favor what I'd consider as having mandatory style enforcement built into the language, yet the code that he (my short-term memory does still sometimes work) works with seems to be full of things I would have been most adamant about disallowing. This might plausibly be related in that he gets to see a lot of the resulting problems and perhaps wishes that there had been a way to keep that kind of mess from developing. Just speculation on my part, but it seems a likely one. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Giorgio Pastore on 14 Jul 2010 13:59 Lynn McGuire wrote: .... > So, yes, I think that strong variable types and interfaces (function > prototypes) should be mandatory in a computer language. I would be realistic and I would consider separately what the standard allows/forbids and what an efficient programming style should/shouldn't enforce. In different ways standards of C, C++ and Fortran are not completely rigid as far as strong typing is concerned. But standards have to take care of the whole history of a language. Specific, efficient and up-to-date programming styles are different things. No one of my students faces problems with types or wrong number/type of arguments, once I require the presence of "implicit none" in every program and module subprograms only. Giorgio
From: dpb on 14 Jul 2010 14:47 Richard Maine wrote: .... > I find it slightly ironic, but then also understandable, that Lynn seems > to favor what I'd consider as having mandatory style enforcement built > into the language, yet the code that he (my short-term memory does still > sometimes work) works with seems to be full of things I would have been > most adamant about disallowing. This might plausibly be related in that > he gets to see a lot of the resulting problems and perhaps wishes that > there had been a way to keep that kind of mess from developing. Just > speculation on my part, but it seems a likely one. In Lynn's defense, I think most of the code that has such severe problems is _very_ old and the code base they currently have has "just growed" w/ time. I do tend to agree, however, that it does seem that the fact that they have been constrained to the F77 dialect they have been/currently are owing to the idiosyncrasies of a particular compiler for the PC market (if not some of the other targets for which it builds; that I don't know about) has tended to keep his mindset that "Fortran" means that particular set of features. While I know from other conversations over several years he is aware of F90+, I get the impression that it hasn't been anything he's used extensively and it isn't used elsewhere either (again I presume to keep code base at least reasonably consistent across platforms). Consequently, I think that he has familiarity and has used C++ those features seem natural but since hasn't done extensive coding nor does there code use them, the similar features and advantages/disadvantages of current Fortran don't have the same level of intuitive cognizance. _IF_ (the proverbial "big if") he can ever get the zero-init and SAVE issue resolved so this code will compile and run successfully on a modern Fortran compiler, _then_ I think if they will give it a fair chance they would discover much to be liked very much that would give C++ a run for its money. Whether it will get that chance against corporate decree given my experience I don't know or feel much confidence about, though. :( --
From: Lynn McGuire on 14 Jul 2010 15:16 > In Lynn's defense, I think most of the code that has such severe problems is _very_ old and the code base they currently have has > "just growed" w/ time. Only since 1965 <g>. As I've mentioned before, we have dragged it to many platforms. For instance, we only started using "implicit none" and character strings a couple of years ago. > I do tend to agree, however, that it does seem that the fact that they have been constrained to the F77 dialect they have > been/currently are owing to the idiosyncrasies of a particular compiler for the PC market (if not some of the other targets for which > it builds; that I don't know about) has tended to keep his mindset that "Fortran" means that particular set of features. While I know > from other conversations over several years he is aware of F90+, I get the impression that it hasn't been anything he's used > extensively and it isn't used elsewhere either (again I presume to keep code base at least reasonably consistent across platforms). > Consequently, I think that he has familiarity and has used C++ those features seem natural but since hasn't done extensive coding nor > does there code use them, the similar features and advantages/disadvantages of current Fortran don't have the same level of intuitive > cognizance. BTW, I have a lot of gripes and learning curve with C++ also. You'll see me frequently complaining over at comp.lang.c++. > _IF_ (the proverbial "big if") he can ever get the zero-init and SAVE issue resolved so this code will compile and run successfully > on a modern Fortran compiler, _then_ I think if they will give it a fair chance they would discover much to be liked very much that > would give C++ a run for its money. Whether it will get that chance against corporate decree given my experience I don't know or feel > much confidence about, though. :( My "intern" is going to start working on the /save problem in a month or two. We are going to try the brute force approach of initializing all local variables to zero using execution statements, not data statements. Thanks, Lynn
From: dpb on 14 Jul 2010 18:06
dpb wrote: > Lynn McGuire wrote: .... >> However, we got nailed recently by a 0 in a call to a sub with a >> double argument. Replacing that with a 0.0 solved the crash. .... BTW, that really should be 0.0D0 (as I'm sure you're aware) but just in case one might consider going back to the offending point and making sure rather than relying on a compiler switch to promote single/double. -- |