🚀 go-pugleaf

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