Drew McCormack wrote:
> I have just spent 2 weeks rewriting about 1500 lines of legacy fortran.
> It was unavoidable, because it was poorly structured, and I needed to
> be able to access the code in a slightly different way than what was
> originally intended.
>
Similar anecdote to follow.
> I am also an OO advocate, and write in several languages other than
> fortran regularly, such as python and objective-C (the latter being a
> smalltalk-c mix). When I write in OO languages, I always use
> 'accessors', which are the set and get methods you refer to.
>
> For many years I also used this approach in Fortran 90. I wanted it to
> be more OO. But lately I've begun to question whether it is really
> worth all the trouble in Fortran.
>
I've always doubted this. Interoption to me is the way to go. My OS
has standard calling sequences that make this easier than other OS's.
F2003 should make this even easier.
> For example, my 1500 lines of fortran 77 quickly became 2500 lines of
> fortran 90, due to structuring of data and explicit typing, even
> without accessor methods. Luckily I found many cases of duplicated
> functionality which I could remove, meaning the fortran 90 was only a
> little longer than the f77. If I had added accessor methods, I think
> there would have been another 500 lines at least, and the code would
> have been slower.
>
Many years ago (prior to F90 on our syatem), we had a work-experience
undergraduate employed for 3 months. My then boss decided to give him
as a project to re-write a F66/F77 routine in totally structured code.
No GOTO's, DO/ENDDO and DO WHILE were available from our vendor.
The main subroutine involved was about 500 lines of code to work out
co-ordinates and to plot a graph of results from a transient stability
output. The student did what he was asked: do not change the code other
than to make it "structured". Some years afterwards I had to modify that
code; I could not fault what the student had done, he had done what he
was told. The routine was now about 2000 lines riddled with DO WHILEs
(which I have always abhored -- why were they ever put into F90 with the
infinite DO???), and variables like FOUND1 to FOUNDn and BREAK1 to BREAKn.
I rewrote the code in about 300/400 lines, but often found the
"structured" code so hard to follow with the plethora of DO WHILE
variables that I often had to resort to the original "spaghetti" code to
see what was intended.
> It is not easy to justify to skeptical fortran 77 programmers that
> their 1000 line program has become 2000 lines in fortran 90, and runs
> more slowly to boot!
>
Use of INTERFACE and MODULES excessively and over-zealously might
increase the code a bit. Use of the new intrinsics and array notation
which are normally a large part of Fortran programs should dramatically
decrease the size. My example above was not using F90.
Yes there was originally a slow down, since many (?, I know of one, but
anecdotally of others) vendors wrote F90 from scratch and compiler
techniques were being revisited. My experience over the past years is
that my vendor is getting to grips with this earlier defect.
> So, as much as I think data hiding is important, and useful in other
> languages, I have my doubts about fortran.
>
> Drew McCormack
***********************************************************************
"This electronic message and any attachments may contain privileged
and confidential information intended only for the use of the
addressees named above. If you are not the intended recipient of
this email, please delete the message and any attachment and advise
the sender. You are hereby notified that any use, dissemination,
distribution, reproduction of this email is prohibited.
If you have received the email in error, please notify TransGrid
immediately. Any views expressed in this email are those of the
individual sender except where the sender expressly and with
authority states them to be the views of TransGrid. TransGrid uses
virus scanning software but excludes any liability for viruses
contained in any attachment.
Please note the email address for TransGrid personnel is now
[log in to unmask]"
***********************************************************************
|