Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!tekgen!tekcae!kurtk From: kurtk@tekcae.CAX.TEK.COM (Kurt Krueger) Newsgroups: comp.lang.c Subject: NOT Educating FORTRAN programmers to use C Message-ID: <5303@tekgen.BV.TEK.COM> Date: 8 Jan 90 18:41:55 GMT References: <1016@sdrc.UUCP> <1990Jan6.003158.2039@aqdata.uucp> <1024@sdrc.UUCP> Sender: nobody@tekgen.BV.TEK.COM Reply-To: kurtk@tekcae.CAX.TEK.COM (Kurt Krueger) Distribution: na Organization: Tektronix, Inc., Beaverton, OR. Lines: 60 In article <1024@sdrc.UUCP> spabdul@sdrc.UUCP (abdul shammaa) writes: > How do you convince your managment that it's time to throw away the > ancient FORTRAN 4 when there are thousands and thousands of lines of that > crap :-( ?! To make matters worse, most to the developers are those who > fear "C" or just don't want to change. I am getting sick and tired of > looking at variable names that look like: I1, I2, KK, IKK, RR etc.. and > at GOTO statments that you have to use in FORTRAN 4. You may be asking > why FORTRAN 4? Well, because as the upper managment puts it "Our software > has to run on so many hardware platforms". That's true, BUT, I don't > believe that that reason should keep up in the middle ages of software > technology. > ... Mind you these are CAE applications which are > complex by nature. So one need not the added burden and limitations of > the programming language itself. That is probably the BEST argument to keep the implementation in Fortran. CAE applications are complex and tend to require a lot of the processor. With the exception of UNIX, you tend to get the best performance with the Fortran compiler. Your management is no dummy. I know you don't like this, but these are current time facts of life. Most of your definition of 'crap' in Fortran is the style of the programmer. I can generate 4x that type of 'crap' in C. Fortunately, the SCIENCE of computer programming was upon us before C became popular, it was entirely an ART when Fortran came about. Thus 'crap' was acceptable in Fortran 4, but not so in C. It is not acceptable in f77 (but that doesn't stop anyone). It might enlighten you to read a book by Kernighan (THE K in K&R) and Plauger called "The Elements of Programming Style". It's about (GASP!) Fortran. Shows the difference between good Fortran and 'crap'. Too late for the ignorant type who used 200+ GOTO's. If the dyed-in-the-wool Fortran programmers in you organization haven't read it, they should. I'm still a firm believer that if you want performance on multiple platforms, Fortran (but f77 PLEASE!) is still the way to go. Fortran does some things real nice (try passing a variable dimensioned 3-d array into a C function - UGH!, or dealing with COMPLEX variables), and some things are ugly (f77 does not support dynamic memory allocation or pointers, but all argument passing is by pointers, and it does support pointers to functions (via EXTERNAL)). The optimizers are generally VERY good at turning array reference operations into the equivalent C pointer reference. This argument will weaken as years go by, but it could very well be a different language than C that we will be discussing. I guarantee that Fortran will still be the 'other' language discussed. One last question - are you sure that you don't fear Fortran and don't want to change? (My credentials - 15 years Fortran on CDC equipment (excellent Fortran, no C) 3 years C on Unix. Language of choice - DEPENDS ON THE APPLICATION. When it's a push, I'll use C. If it's bsd Unix, I do my best to avoid f77) _______________________________________________________________________________ --- Lively discussion welcomed, personal attacks to /dev/null