Re: Fortran vs. C: quick thought

[wetmore : at : theochem.waterloo.edu (Ross W. Wetmore)]

> [...]  Why must we, as developers and programmers, (1) take our
 > equations which are often formulated in terms of matrix and vector
 > operations, (2) convert them to loop-based code (an error-prone
 > process that usually requires much more debugging than coding), and
 > (3) cross our fingers and hope that the compiler "recognizes" it
 and
 > turns it back into the original matrix expression?  We shouldn't, and
 > with Fortran 90, we finally, after 15 years, have a language that
 > allows us to turn our equations directly into code.  In this respect,
 > the only remaining question is how well the vendors are going to
 > support this capability.
 >
 > What does this have to do with Fortran and C?  Fortran 90 puts C TWO
 > generations behind instead of just one.  If it took us 15 years to
 > finally get array syntax standardized in Fortran, how much longer
 > would it take us to get it, along with variable-dimensioned arrays and
 > user-defined subscript ranges, into C?
 > -ron shepard
 > shepard : at : tcg.anl.gov
   I don't want to add fuel to such an explosive topic, but just a quickie
 thought on a thread that seems to run through the above.
   The thread is the lament at the time it seems to take to see improvements
 in some areas of compiler technology. It should be noted that numerical
 computation is relatively straightforward and not one of the cutting edges
 of compiler research. Commercial development can provide some added value
 and thus advantage in selling new hardware, but the scientific/computational
 niche is not the largest nor most lucrative segment of the market. On the
 other side, there are a growing number of computational scientists, and a
 growing awareness of the need to both learn more about and interact more
 with some of the source disciplines that provide this technology to them,
 but there is still a lot of reluctance to get really involved.
   To the computer scientist, FORTRAN is an incredibly ad hoc language that
 is incredibly difficult to parse, has very poor structural basis and
 consequently lends itself very poorly to a lot of the structural analyses
 and safety net features that are taken as fundamental truths. It is not
 likely that there will be much common ground found with them in discussions
 of how to extend FORTRAN, especially when issues of backwards compatibility
 are raised.
   There has been some mention of C++ by a few posters, and while I don't
 want to suggest anything particular about this name (it could be F++ for
 all I really care), there are a couple useful advances in compiler technology
 that it brings out. The first is an easy (for the skeptical, would you accept
 easier) way to provide reusability of code through its concepts of Classes
 and sub-Classes and the methods or operations that each Class is capable of
 performing. It is very much possible to provide libraries of understandable
 syntax tailored functions and novel data types that are built on layers of
 previous, but simpler or more elementary components. The second is the
 degree to which these additions interact and become a part of the compiler
 technology itself - in essence the developer of a Class library is able
 to redesign the language for those who would make use of such extensions.
   Converting old codes is largely a waste of time if they run fine and do
 the job that they were designed to do. But computational scientists that
 are developing new applications, or new methods might be best served if
 they took a quick look at some of the new toys that computer scientists
 are busy experimenting with and tried to enlist some cooperation in seeing
 just how they might be applied. It is just possible that encapsulating a
 lot of old code and algorithms with a thin wrapper of some of the latest
 and greatest technology could result in a best of both worlds scenario where
 new development could take off from a structurally sound and aesthetically
 pleasing (to some) base, while retaining much of the computational efficiency
 and known quality of the existing numerical software. One of the beauties
 of some of the new ways is that well designed interfaces hide and isolate a
 lot of the nitty gritty and thus make possible the replacement of large
 amounts of underlying structure without anyone being the wiser. A gradual
 replacement and enhancement policy is a viable approach in such an environment.
 Moreover, it is an approach that does not impede real use of the system
 during the process.
   I guess this got a little longer than expected, but rather than stirring
 up old fires of whose native language is better, if both start learning a
 little computer esperanto for public discourse, and reserve their native
 tongue for use at home, there are a lot of interesting possibilities.
 Ross W. Wetmore                 | wetmore : at : theochem.waterloo.edu
 Waterloo, Ontario               | {backbone}!watmath!rwwetmor