tneff@bfmny0.UU.NET (Tom Neff) (01/09/90)
[This is a .misc topic - followups directed there] In article <167@metapyr.UUCP> chris@metapyr.UUCP (Chris Collins) writes: >My organization is in the midst of going thourgh just this painful process, >of replacing our existing base of 500000 or so lines of Fortran with >C software. The only way to convince management was to keep pointing out >that the old software just can't be maintained or modified as easily as >C software. Eventually it will, if it hasn't already, hit them in the >pocketbook. Why, pray tell, is C inherently more modifiable[!] or maintainable than Fortran? It seems to me that what hurts maintainability is lack of documentation and lack of tools -- which can be equally true in either language. It also seems to me that what hurts portability is building in all sorts of messy assumptions about how one platform works for the sake of 'optimization' (perceived or real) so that you have to reinvent not just the wheel, but the paddlewheel steamer, anywhere you move. This too can be done equally thoroughly in either language. My shop has a zillion lines of Fortran, about 5% of which could profitably be rewritten in a more system-y language like C if we ported to a new platform, but the other 95% of which is doing its job just fine in Fortran and would be well advised to stay that way. (Fortran is available now and ain't going away.) -- To have a horror of the bourgeois (\( Tom Neff is bourgeois. -- Jules Renard )\) tneff@bfmny0.UU.NET
bet@orion.mc.duke.edu (Bennett Todd) (01/10/90)
In article <15078@bfmny0.UU.NET>, tneff@bfmny0 (Tom Neff) writes that
rewriting extant FORTRAN applications wholesale with C isn't necessarily
a good idea. I agree entirely. FORTRAN was designed to support numerical
programming well; it does this. It has a wealth of mathematical types
and functions defined into the language. In particular, basically much
of libm is known to the compiler, so a *good* implementation of FORTRAN
can code it all inline, and perform compile-time optimizations that
depend on knowing details about how functions are being called.
In C you can extend the language using structures (for the COMPLEX type,
for example) and subroutines to implement all the mathematical
operations. This doesn't read much worse than having the language
features directly available, though functional notation isn't as nice as
infix for the basic arithmetic operators as applied to complex (for
example). Unfortunately, for many applications it will be *drastically*
slower.
You can always tune the code by expanding out all the arithmetic in-line
and hand-tweaking it. Thanks anyway, I'd rather maintain the FORTRAN.
Much.
C++ offers the possibility of extending the language at compile time to
support numerical applications, retaining both a clean notation for
representing equations and the performance of allowing the compiler to
know the internals of the algorithm. A few months ago I posted an
example power() routine that allowed me to code
printf("%g", power(sin(atof(argv[1])), 2));
and upon examining the assembler produced by G++ I got
call atof;
call sin;
multiply the return value by itself;
call printf;
This is the kind of performance people expect good FORTRAN compilers to
produce. C can't do that without getting uglier to write and maintain
than the FORTRAN. C++ can.
As always, these are just my opinions. My experience with numerical
programming is reasonably limited; if I'm wrong please be kind enough to
explain why politely. Thank you.
-Bennett
bet@orion.mc.duke.edures@cbnewsc.ATT.COM (Rich Strebendt) (01/10/90)
Allow me to add some comments based on more years of programming experience than I like to admit to, in a whole lot of languages from machine code (the level below assembler!) through FORTRAN, PL/I, and SPITBOL and APL to C. In article <15078@bfmny0.UU.NET>, tneff@bfmny0.UU.NET (Tom Neff) writes: | [This is a .misc topic - followups directed there] | | In article <167@metapyr.UUCP> chris@metapyr.UUCP (Chris Collins) writes: | |My organization is in the midst of going thourgh just this painful process, | |of replacing our existing base of 500000 or so lines of Fortran with | |C software. The only way to convince management was to keep pointing out | |that the old software just can't be maintained or modified as easily as | |C software. Eventually it will, if it hasn't already, hit them in the | |pocketbook. | | Why, pray tell, is C inherently more modifiable[!] or maintainable than | Fortran? My experience has been that FORTRAN's control structures tend to encourage "spaghetti" code, while those in C tend to encourage more structured approaches to the code. Note that I DID NOT say that either language makes maintenance problems impossible to create!!! A language called RATFOR (RATional FORtran) was an attempt to correct this sort of deficiency in FORTRAN. I do not know how widely this language caught on, though. | It seems to me that what hurts maintainability is lack of documentation | and lack of tools -- which can be equally true in either language. Programs in C tend, also, to be written with variables whose names are meaningful, rather than the cryptic variables that tend to be used with FORTRAN to try to ensure that the code can be run on machines with, say, 6 character symbol length limits. This helps make the C code somewhat more self documenting. Of course, the choice of short cryptic variable names can still be made in C also, but the language does not encourage it. Also, because of the control structures, the part of the code that does the work does not so easily get lost in the control structures in which it is embedded. | It also seems to me that what hurts portability is building in all sorts | of messy assumptions about how one platform works for the sake of | 'optimization' (perceived or real) so that you have to reinvent not | just the wheel, but the paddlewheel steamer, anywhere you move. This | too can be done equally thoroughly in either language. True. However, the ability to #define and #ifdef portions of the code to allow for different platforms in C helps to reduce this hurt somewhat. True, 9-bit bytes and 48-bit integers can foil a programmer who thinks that the world is composed solely of 8-bit bytes and 32-bit integers, but no language can cure naivety. | My shop has a zillion lines of Fortran, about 5% of which could | profitably be rewritten in a more system-y language like C if we ported | to a new platform, but the other 95% of which is doing its job just fine | in Fortran and would be well advised to stay that way. (Fortran is | available now and ain't going away.) As long as that code is doing its job and continues to do so with only minor tweekings and tunings, you would be foolish to convert it unless you had to do so anyway in order to move to a platform that did not support your current dialect of FORTRAN. If performance or some other consideration forces a redo of the 5%, then you would be wise to look into alternative languages, C among them, to see if one of them is a better choice FOR THAT JOB than FORTRAN. It is very important that we not lose sight of an important point: For each problem, use the best tool to solve that problem; for a different problem, a different tool may yield a better solution. Programming languages are TOOLS we use to attain the ends toward which we strive -- they are not the ends themselves. In this regard, consider COBOL. It is antiquated, ugly, and certainly not comp-sci-ish. Why would any one program in COBOL? Because it gets the job done in the domain for which it was designed: bashing record oriented data in a business data processing environment. Or, consider LISP. I think it is ugly, counter-intuitive, and a waste of intellectual talent -- yet for AI programming it is a real winner and is extremely valuable in that domain (among others). So, for a given problem there is probably a language which is "beautiful" for developing the solution. There are others which are "ugly". For a different problem it is quite possible that they can change roles. Rich Strebendt ...!att!ihlpb!res
chris@metapyr.UUCP (Chris Collins) (01/10/90)
In article <15078@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: > >In article <167@metapyr.UUCP> chris@metapyr.UUCP (Chris Collins) writes: >>My organization is in the midst of going thourgh just this painful process, >>of replacing our existing base of 500000 or so lines of Fortran with >>C software. > >Why, pray tell, is C inherently more modifiable[!] or maintainable than >Fortran? > Your points are well taken, but remember here that we are talking about Fortran 4, which is at least being "deprecated". We've had more than one platform require special modifications because Fortran 4 was not supported anymore. Also, we've found that it's faster to write C than to write Fortran 4, for our programmers. Even the "hard-liners", of which I was/am includec, found that we could be as productive in C quite quickly. Our other major reason for changing is that it was clear that we had to add major functional changes, and these required several architecture changes to the whole system. Chris Collins chris@metapyr
daniels@teklds.WR.TEK.COM (Scott Daniels) (01/11/90)
In article <16717@duke.cs.duke.edu> bet@orion.mc.duke.edu (Bennett Todd) writes: >In article <15078@bfmny0.UU.NET>, tneff@bfmny0 (Tom Neff) writes that >rewriting extant FORTRAN applications wholesale with C isn't necessarily >a good idea. I agree entirely. FORTRAN was designed to support numerical >programming well; it does this. It has a wealth of mathematical types >and functions defined into the language. In particular, basically much >of libm is known to the compiler, so a *good* implementation of FORTRAN >can code it all inline, and perform compile-time optimizations that >depend on knowing details about how functions are being called. This has been one of the problems for C that the ANSI standard addresses. Original C was required to treat all library functions by invokation, just in case the user decided to write his own function by the same name. So much for compile-time evaluation of the library. Now the standard provides a clear way for the compilers to know whether the library function will be invoked, so look for the top of the line new ANSI C compilers to start doing the kind of aggressive unfolding and reorganizing that was previously only available to Fortran. There were battles with the numerical analysts (unary plus, respect all parens, ...) precisely because they believe that there will be C compilers capable of supporting optimizations that will allow C compiler to compete with or at least approach the speed of FORTRAN programs. >C++ offers the possibility of extending the language at compile time to >support numerical applications. This is true, neither FORTRAN nor C provide the capability of extending the language with a set of user functions which can get the same kind of analysis as the system functions. C++ provides some of this (much more than most languages), but the functional languages (I am particularly thinking of lml here) get closer to what you'd like than any of the more traditional languages. The really impressive optimizations will probably come from some system that allows properties of the resulting abstractions to be defined (as in Goguen's work on attaching theories to views). This work may eventually lead to a system which can attain (on a user type) the fabled optimization (which knocked out a benchmark on a FORTRAN compiler): for i = 1,90 V = V + sin( PI / i ) ** 2 + cos( PI / i ) ** 2 became V = V + 90.0 since the compiler knew (heavens knows why) that sin(x)**2 + cos(x)**2 = 1. -Scott Daniels daniels@teklds.wr.tek.com
khb@chiba.kbierman@sun.com (Keith Bierman - SPD Advanced Languages) (01/16/90)
In article <1298@wrgate.WR.TEK.COM> daniels@teklds.WR.TEK.COM (Scott Daniels) writes:
....This has been one of the problems for C that the ANSI standard addresses.
Original C was required to treat all library functions by invokation, just
....
look for the top of the line new ANSI C compilers to start doing the kind of
aggressive unfolding and reorganizing that was previously only available to
Fortran......
Actually enough errno nonsense and stuff was added so that SVID, ANSI,
POSIX are all modestly different .... and none as optimizable as
Fortran.
NCEG is working to rationalize matters.
...
or at least approach the speed of FORTRAN programs.
Aliasing takes care of that. On any given machine, with equal efforts
given to the optimizer technology ... Fortran wins. The only way for C
to break even or win (on large application programs) is for the
compiler writers to avoid doing the best they can for Fortran, and
work overtime to fixup C.
....
of analysis
as the system functions. C++ provides some of this (much more than most
languages), but the functional languages (I am particularly thinking of lml
here) get closer to what you'd like than any of the more traditional languages.
Fortran 90 (as just renamed by X3J3) does about as good a job as C++,
or better in some ways. Still not the same as building the rules into
the compiler, of course.
--
Keith H. Bierman |*My thoughts are my own. !! kbierman@sun.com
It's Not My Fault | MTS --Only my work belongs to Sun*
I Voted for Bill & | Advanced Languages/Floating Point Group
Opus | "When the going gets Weird .. the Weird turn PRO"
"There is NO defense against the attack of the KILLER MICROS!"
Eugene Brooks