gcglan@sdrc.UUCP (frank glandorf) (01/05/90)
Has anyone had any interesting experiences educating FORTRAN
programmers to use C? I recently had a chance to observe a system
which was built by persons who had taught themselves C and whose
previous programming experience was in FORTRAN only. An unusual
aspect of the system was caused by a coding requirement that the
-> operator was permitted to be used in one subsystem only. One
result was that one subsystem was rather large and monolithic.
Another result was the extensive use of macros to disguise the
use of the -> operator. For example, I would write the following
code fragment to walk a linked list (note that all the typedefs
and defines are in include files):
typedef struct list {
struct list *next_node;
int data;
} List;
List *search(List *first_node, int data) {
List *p;
for (p = first_node; p != NULL && p->data != data; p = p->next_node)
;
return p;
}
This system would have a coding style like:
#define NEXT_NODE(first, ptr) ((ptr) == NULL ? \
(first) : (ptr)->next_node)
#define DATA_NODE(ptr) (ptr)->data
List *search(List *first_node, int data) {
List *p;
p = NULL;
while (NEXT_NODE(first_node, p)) {
if (DATA_NODE(p) == data) break;
}
return p;
}
I am told the reason for this style is to ensure 'correct' access
to structure members. There are a number of modules which are
exempt from the -> rule. I think their existence should have told
the designers that there was something wrong with their method.
Another thing that strikes me about the code is its superficial
resemblence to FORTRAN. The structure references have been made
to look like FORTRAN array or function references. The designers
may have felt more comfortable with this style.
Frank Glandorf -- gcglan@sdrc.uu.net (513) 576-2061
"If the end of the world was annouced tomorrow, I'd move to Cincinnati
since everything happens there twenty years later" -- Samuel L. Clemenssullivan@aqdata.uucp (Michael T. Sullivan) (01/06/90)
From article <1016@sdrc.UUCP>, by gcglan@sdrc.UUCP (frank glandorf): > > Has anyone had any interesting experiences educating FORTRAN > programmers to use C? I recently had a chance to observe a system > which was built by persons who had taught themselves C and whose > previous programming experience was in FORTRAN only. An unusual Then there's that function I encountered whilst working for an unnamed defense contractor. It seems the person had no prior experience with C. Came back with a single function that had 263 (two hundred sixty three) GOTO's in it. I don't even know how many lines the function itself was but these gotos were coming about every other line. Good thing the function worked--I didn't have to touch the code. Funny thing was, they told me the program was object oriented when I came to this new group. I didn't know OOP meant so many goto's...:-) -- Michael Sullivan uunet!jarthur.uucp!aqdata!sullivan aQdata, Inc. San Dimas, CA
spabdul@sdrc.UUCP (abdul shammaa) (01/08/90)
> Then there's that function I encountered whilst working for an > unnamed defense contractor. It seems the person had no prior > experience with C. Came back with a single function that had > 263 (two hundred sixty three) GOTO's in it. I don't even know > how many lines the function itself was but these gotos were coming > about every other line. Good thing the function worked--I didn't > have to touch the code. > > Funny thing was, they told me the program was object oriented when > I came to this new group. I didn't know OOP meant so many goto's...:-) > -- > Michael Sullivan... > 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. You can't believe the pains that you have to go through just to allocate dynamic memory...(YUK!). 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. May be changing to "C", "C++", or any other civilized programming language is impossible at this stage of the game. Or, is it? What do you think? --------------------------------------------------------------------------- uunet!sdrc!spabdul
streich@boulder.Colorado.EDU (Mark Streich) (01/08/90)
In article <1024@sdrc.UUCP> spabdul@sdrc.UUCP (abdul shammaa) writes: >> -- >> Michael Sullivan... >> >May be changing to "C", "C++", or any other civilized programming language >is impossible at this stage of the game. Or, is it? What do you think? Maybe the compiler/translator world should start publicizing the fact that there are ways to automatically translate from one language to another. I'm not sure how good the results are, but the number of errors that would creep in by a human translator may be boundless...
sullivan@aqdata.uucp (Michael T. Sullivan) (01/09/90)
From article <1024@sdrc.UUCP>, by spabdul@sdrc.UUCP (abdul shammaa): >> [ stuff about a function with 263 goto's in it] > > 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 No, no, no. That WAS C code. It was written by FORTRAN/mainframe stuff programmer as his first C project. -- Michael Sullivan uunet!jarthur.uucp!aqdata!sullivan aQdata, Inc. San Dimas, CA
bright@Data-IO.COM (Walter Bright) (01/09/90)
In article <1016@sdrc.UUCP> gcglan@sdrc.UUCP (frank glandorf) writes:
<Has anyone had any interesting experiences educating FORTRAN
<programmers to use C?
Yeah. The result is amusing, the first programs they write looked like
Fortran! All integer variables were i,j,k,l,m,n, lots of gotos to L109,
L110, etc!.
I've also seen Pascal converts to C. Their code looks a lot like Pascal.
A typical thing is to not believe that the short circuit operators &&
and || are reliable, the Pascal state variable uglies appear everywhere
(to avoid using 'break' from a loop).
It's fun looking at other people's C code and guessing what language they
migrated from!
As time goes by, these anachronisms fade and the code looks more and more
like C.
I came to C with a background in Pascal, asm, and mostly Fortran. My first
major C program looked like Fortran. It did all static data allocation,
not a single pointer, tons of global data, etc! (I still use i,j for int
variables, and Lnnn for goto labels!)
<Another result was the extensive use of macros to disguise the
<use of the -> operator.
Sounds like you need C++.chris@metapyr.UUCP (Chris Collins) (01/09/90)
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 :-( ?! > Well, because as the upper managment puts it "Our software >has to run on so many hardware platforms". > >May be changing to "C", "C++", or any other civilized programming language >is impossible at this stage of the game. Or, is it? What do you think? > >--------------------------------------------------------------------------- >uunet!sdrc!spabdul 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. If you can, begin by converting only portions at a time. This was partially the approach we took, by first replacing underlying libraries, then moving on to application/user level code. We're by no means done, but once we got started, improvements began to be requested and made by management. We've made significant changes for the better in the philosophy of our software. Some of this was market driven, of course, but much of it was architecture/ease of development/taking advantage of C capabilities type stuff. For portability, C code can be easily be as portable as Fortran, and usually is much more portable. Our Fortran software contained it's own bootstrapped preprocessor, which was okay but not at all as powerful as the C preprocessor. You could also point out that the best programmers are not going to be interested in Fortran programmers, and it will drive away current employees (like yourself) too. Chris Collins
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
yahoo@unix.cis.pitt.edu (Kenneth L Moore) (01/14/90)
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 :-( ?! >uunet!sdrc!spabdul I can relate to this story. I used to design nuclear reactor fuel rods and all of our analysis codes were written in FORTRAN IV. However, you may be taking a microscopic (vs macroscopic) view of the problem. While C gives many advantages, the cost of retraining, the politics of change, and the cost of updating code might not be worth it. This was especially true in our case since all codes had to be NRC approved. (a very costly process) Watch your ass. I remember one arrogant new guy who thought we were all stupid for using FORTRAN. He claimed that Pascal was the only programming language that made sense. He looked like a jerk and made a lot of enemies. -- I don't yell and I don't tell and I'm grateful as hell: Benny Hill
DVL@PSUVM.BITNET (Roger Christman) (01/19/90)
In article <21604@unix.cis.pitt.edu>, yahoo@unix.cis.pitt.edu (Kenneth L Moore) says: >>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 :-( ?! > > .... While C gives many advantages, the cost of retraining, the >politics of change, and the cost of updating code might not be worth it. >approved. (a very costly process) > It so happens that at the moment I'm working on a project to do just that: Translate ancient FORTRAN 66 programs into some legible form of C. Neat, huh? If you can find it, I made a posting to this effect on December 7, 1989 on comp.lang.c and comp.lang.fortran. --------------------- DMSSIG002E File DVL SIGNATUR not found Ready(00028);