Learning Fortran
in [Matlab]
|
From: TideMan on 20 May 2010 22:36 On May 21, 1:46 pm, Greg Heath <he...(a)alumni.brown.edu> wrote: > On May 20, 8:18 am, Rune Allnor <all...(a)tele.ntnu.no> wrote: > > > > > On 20 Mai, 13:37, "Baalzamon " <baalzamon_mori...(a)yahoo.com> wrote: > > > > I am attempting to convert some old fortran codes and becoming somewhat annoyed by the apparent jumping of code. > > > The infamous spaghetti style coding > > >http://en.wikipedia.org/wiki/Spaghetti_code > > > is the main reason why you ought not learn fortran at all. > > It was obsolete 40 years ago. The only reason it remains > > in use is the vast amount of legacy code present. > > > > WOuld I be correct in assuming that the code is read top to bottom and in line number order? > > > No. It *starts* that way, but from the first jump / break / > > continue / > > goto statement you are on your own with respect to untangling program > > flow. Hence the spaghetti metafor. > > > > If so where does the do label numbers figure into this scheme? > > > They are the spots at which a jump / break / continue / goto might > > refer. One serious problem with fortran is that there is no > > convenient > > way to find out where the jump that landed on the label was made. > > > > Any advice from fortan programmers would be appreciated. To be explicit I think the coxde was written in F77... > > > Don't write fortran. It might be more cost effective to find > > out what the program is supposed to do, and then develop and > > code the algorithm from scratch in matlab, C, C++ or Java. > > > No kidding. > > I have had the pleasure of disentangling a FORTRAN > numerical optimization program that used a plethora of > subroutines and goto/contimue statements. When finished, > the FORTRAN code was not dissimilar to that used in > MATLAB. However, I had no incentive to convert it to > MATLAB because I didn't know how to compile MATLAB > to make it run as fast. > > A lot depends on how comfortable you are with FORTRAN, > what you plan to do with the program in the futire, and how > much time you can spare. > > Hope this helps. > > Greg Yes, I agree, Greg. Mostly, I develop algorithms in Matlab, then translate into Fortran 95 for speed and for distribution. My clients compile and link my code on their machines (either Windows or Linux) and away they go. No expensive Matlab compiler required. No cross-platform difficulties. And gfortran is free. I wouldn't worry about old Rune's comments. He's just trying to wind people up. He's like a broken record. He says the same thing everytime this comes up.
From: Rune Allnor on 21 May 2010 05:34 On 21 Mai, 03:46, Greg Heath <he...(a)alumni.brown.edu> wrote: > On May 20, 8:18 am, Rune Allnor <all...(a)tele.ntnu.no> wrote: > > > > > > > On 20 Mai, 13:37, "Baalzamon " <baalzamon_mori...(a)yahoo.com> wrote: > > > > I am attempting to convert some old fortran codes and becoming somewhat annoyed by the apparent jumping of code. > > > The infamous spaghetti style coding > > >http://en.wikipedia.org/wiki/Spaghetti_code > > > is the main reason why you ought not learn fortran at all. > > It was obsolete 40 years ago. The only reason it remains > > in use is the vast amount of legacy code present. > > > > WOuld I be correct in assuming that the code is read top to bottom and in line number order? > > > No. It *starts* that way, but from the first jump / break / > > continue / > > goto statement you are on your own with respect to untangling program > > flow. Hence the spaghetti metafor. > > > > If so where does the do label numbers figure into this scheme? > > > They are the spots at which a jump / break / continue / goto might > > refer. One serious problem with fortran is that there is no > > convenient > > way to find out where the jump that landed on the label was made. > > > > Any advice from fortan programmers would be appreciated. To be explicit I think the coxde was written in F77... > > > Don't write fortran. It might be more cost effective to find > > out what the program is supposed to do, and then develop and > > code the algorithm from scratch in matlab, C, C++ or Java. > > > No kidding. > > I have had the pleasure of disentangling a FORTRAN > numerical optimization program that used a plethora of > subroutines and goto/contimue statements. You're into the S&M scene, then? > When finished, > the FORTRAN code was not dissimilar to that used in > MATLAB. What, exactly, do you mean by 'disentangling' fortran? Understand what's going on? Re-write the mess? > However, I had no incentive to convert it to > MATLAB because I didn't know how to compile MATLAB > to make it run as fast. Use C or C++ instead. > A lot depends on how comfortable you are with FORTRAN, There is no reason why anywone would want to let a half-century-old seriously flawed programming language guide your day. Fortran was among the first high-level programming languages around, and a number of serious mistakes were made that designers of later languages have made more or less successful attempts to rectify. 'Structured programming' of the early '70s represented a revolution by breaking code up in individually easily understandable functions. Object oriented programming of the late '70s took that a lightyear further. > what you plan to do with the program in the futire, I don't mind if *you* have no other ambitions than messing around on your own. Just don't rely on - expect, even - others to have as unassuming ambitions as yourself. > and how > much time you can spare. No. How much time you, the fortram programmer, wastes on the subsequent maintaner's behalf. Again, I don't mind you wasting your own time. I *do* mind you wasting somebody else's. Particularly mine. Rune
From: Rune Allnor on 21 May 2010 05:48 On 21 Mai, 04:36, TideMan <mul...(a)gmail.com> wrote: > I wouldn't worry about old Rune's comments. Well, am am actually young enough never to have to had to learn fortran. The old people here are those who are so stuck in their old habits, unable to learn the methods that actually work. > He's just trying to wind people up. No. I am trying to guide youngsters and novices away from the pitfalls that have been known for decades already. Read the opening sentence of the classic paper Go To Statement Considered Harmful Commmunications of the ACM VoL11 (2), 1968 pp. 147-148 Edsger W. Dijkstra: "For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce." I couldn't agree more. > He's like a broken record. If so, it is because the same old farts and amateurs are guiding the youngsters and novices into the same well-known traps. As I said to somebody else, I don't mind you wasting your *own* time, but I do mind you wasting *other* people's time. These things aren't difficult to get right. It's only a matter of letting go of the time of *your* youth. > He says the same thing everytime this comes up. Of course. As long as fortran is around and being discussed, its flaws must be addressed. Rune
From: Steve Amphlett on 21 May 2010 06:13 Rune Allnor <allnor(a)tele.ntnu.no> wrote in message <1a16015e-0539-442e-bb29-958448ed6972(a)y21g2000vba.googlegroups.com>... > On 21 Mai, 04:36, TideMan <mul...(a)gmail.com> wrote: > > > I wouldn't worry about old Rune's comments. > > Well, am am actually young enough never to have to had to learn > fortran. The old people here are those who are so stuck in their > old habits, unable to learn the methods that actually work. > > > He's just trying to wind people up. > > No. I am trying to guide youngsters and novices away from the > pitfalls that have been known for decades already. Read the > opening sentence of the classic paper > > Go To Statement Considered Harmful > Commmunications of the ACM VoL11 (2), 1968 pp. 147-148 > Edsger W. Dijkstra: > > "For a number of years I have been familiar with the observation > that the quality of programmers is a decreasing function of the > density of go to statements in the programs they produce." > > I couldn't agree more. > > > He's like a broken record. > > If so, it is because the same old farts and amateurs are guiding the > youngsters and novices into the same well-known traps. As I said to > somebody else, I don't mind you wasting your *own* time, but I > do mind you wasting *other* people's time. > > These things aren't difficult to get right. It's only a matter of > letting go of the time of *your* youth. > > > He says the same thing everytime this comes up. > > Of course. As long as fortran is around and being discussed, its > flaws must be addressed. > > Rune I really enjoy reading the anti-FORTRAN flame wars here. Of the FORTRAN being written today, I wonder how much of it is simply adding features to legacy code and how much of it is new code, using all the bells and whistles added to it over the years to keep the name alive?
From: Rune Allnor on 21 May 2010 06:45
On 21 Mai, 12:13, "Steve Amphlett" <Firstname.Lastn...(a)Where-I- Work.com> wrote: > Rune Allnor <all...(a)tele.ntnu.no> wrote in message <1a16015e-0539-442e-bb29-958448ed6...(a)y21g2000vba.googlegroups.com>... > > On 21 Mai, 04:36, TideMan <mul...(a)gmail.com> wrote: > > > > I wouldn't worry about old Rune's comments. > > > Well, am am actually young enough never to have to had to learn > > fortran. The old people here are those who are so stuck in their > > old habits, unable to learn the methods that actually work. > > > > He's just trying to wind people up. > > > No. I am trying to guide youngsters and novices away from the > > pitfalls that have been known for decades already. Read the > > opening sentence of the classic paper > > > Go To Statement Considered Harmful > > Commmunications of the ACM VoL11 (2), 1968 pp. 147-148 > > Edsger W. Dijkstra: > > > "For a number of years I have been familiar with the observation > > that the quality of programmers is a decreasing function of the > > density of go to statements in the programs they produce." > > > I couldn't agree more. > > > > He's like a broken record. > > > If so, it is because the same old farts and amateurs are guiding the > > youngsters and novices into the same well-known traps. As I said to > > somebody else, I don't mind you wasting your *own* time, but I > > do mind you wasting *other* people's time. > > > These things aren't difficult to get right. It's only a matter of > > letting go of the time of *your* youth. > > > > He says the same thing everytime this comes up. > > > Of course. As long as fortran is around and being discussed, its > > flaws must be addressed. > > > Rune > > I really enjoy reading the anti-FORTRAN flame wars here. No flames in the anti-fortran discussions from my side. It's usually enough to point out the facts. Suffice it to say that such an obvious feature as dynamic memory handling wasn't added to the language until the mid '90s, some 40 years after the language was first developed. Any flaming usually begins when some retired oldster who has all the time in the world on his hand to mess around with GOTO and hand 'optimization', and is too lazy to learn what has been around since 1970, chimes in in order to maintain his 'cool', 'youthful' self image for a nother few weeks... Talking about fortran today is like talking about steam engines to a mechanical engineer: It has a huge historical significance, and might be worth being aware of for educational and legacy purposes, but no one in their right mind would even dream of basing a carreer on them. Or guide others in that direction. > Of the FORTRAN being written today, I wonder how much of it is simply adding features to legacy code and how much of it is new code, using all the bells and whistles added to it over the years to keep the name alive? There are only two reasons to *code* fortran today: 1) Maintain legacy code 2) Because one is too lazy / outdated to know anything else Rune |