NOT Educating FORTRAN programmers to use C

[daniel mocsny]

In article <5303 at tekgen.BV.TEK.COM> kurtk at tekcae.CAX.TEK.COM (Kurt Krueger) writes:
>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 have seen FORTRAN "de-spaghetti-fier" utilities advertised, e.g.,
from Cobalt Blue. These programs purport to transform such FORTRAN
'crap' into cleanly structured (insofar as such is possible)
FORTRAN code. If these programs work, then it's never "too late" for 
the code with 200+ GOTO's.

Does anyone have experience with such programs?

Also, I think being unhappy with someone else's choice of language is
a problem the computer should be able to solve. I.e., we should find
ways to use computers as tools to allow each individual to structure
his/her own sensory environment to his/her liking, while still
retaining the ability to communicate coherently with people who choose
to structure their sensory environments in different ways. Obviously
we are a long way from being able to do that---we couldn't imagine
a big project getting too far off the ground if one programmer
thought/wrote in C, the next in Lisp, the next in Snobol, the next
in FORTRAN, etc. However, I think the programming community as a whole
has *vastly* overlooked the scope for using language translators to
assist the programmer in working with someone else's foreign code in
the way (s)he prefers.

Sorry for this slight detour from the proper domain of this newsgroup.
But when I see debates over which language programmers should use, I
wonder why the debaters automatically assume the errant programmers
must assume the entire burden for changing their ways. If constructs
in one language map 1:1 onto constructs in another, then who cares
which language a programmer prefers? If a project requires specific
language features that are outside of this directly-mappable core
subset, the programmers have to change. But even then, the best way to
get a feel for a new language is to take some familiar code you wrote
in your old language and see what it looks like in the new. 

Dan Mocsny
dmocsny at uceng.uc.edu