Date: Sun, 17 Feb 2002 15:29:07 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: "Gary W. Swearingen" <swear@blarg.net> Cc: Brett Glass <brett@lariat.org>, "freebsd-chat@FreeBSD.ORG" <freebsd-chat@FreeBSD.ORG> Subject: Re: Fortran (was Re: Why is Python slower on FreeBSD than Windows?) Message-ID: <3C703CC3.84C65471@mindspring.com> References: <20020215145841.O33755-100000@resnet.uoregon.edu> <3C6D22C2.268E6915@pythonemproject.com> <20020215145841.O33755-100000@resnet.uoregon.edu> <4.3.2.7.2.20020216134025.01cfd980@localhost> <xcwuxceygz.uxc@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
"Gary W. Swearingen" wrote: > Brett Glass <brett@lariat.org> writes: > > And now the punch line: the code they'd ported had been used in > > the design of nuclear weapons. > > > > I trust neither FORTRAN nor C to this day. > > As someone with lots of FORTRAN experience, some with old FORTRAN and > porting, it's easy to guess that the FORTRAN-to-Algol porters failed to > understand what was going on in the FORTRAN program. Genius (and other) > level scientists and engineers, working to deadlines in environments > that placed no merit on readability or any other "good" coding standards, > can generate FORTRAN that nobody but them can understand before the need > has passed. And these guys were usually smart enough to check their > work for reasonableness (eg, with sliderules) or by other methods. I've > checked old code by eye and with analysers and found lots of problems > and a lot more things that looked like problems until closer examination > revealed them to not be errors or to not matter much. With one big > port (between CPUs and FORTRAN versions), the stuff was just so full of > horrors that I knew I couldn't understand it well enough to maintain it > and was allowed to redevelop most of it from scratch, getting a new > program that produced essentially the same results as the old. > > No doubt much such coding was full of real, significant errors, but it > usually takes a great deal of work to prove that one way or the other. In the relatavistically invariant particle collision code I worked on for pair production simulations, there were intentional overflows used as part of the random sequence generation. In other words, this "bug" was intentional, and not a bug. > Surely better languages and code design/coding practices would have > helped, but I (and other several other engineers I've known) have come > to believe that the old timers knew the math and physics of what they > were doing better than us youngsters who tend to spend too much of our > efforts worring about programming issues. Yep. I'm of the same opinion. I had one professor who would not accept the results of an integration that had an equation "+ C", unless you could tell him what the value of the constant of integration was. He also insisted that you know the answer you expected before you ran your equations, so you would recognize a result that was incorrect vs. one that was correct, but unexpected. His PhD thesis at Utah State University predicted the W particle energy range to 5 significant digits ~1968, from a theoretical basis. This man has more physics in his pinky than the rest of us... well, you get the idea 8-). > The trustworthiness of the developers can be more important than the > trustworthiness of the language they use. Both are important. Yep. Hence my response: "Did they work anyway?". 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C703CC3.84C65471>