Well, many scientists and engineers don't have the time, motivation or ability to master the intricacies of recent fortran vintages either. That's the problem.
Very large codes written by teams of software engineers for well-delimited application spaces will continue to be written in some version of Fortran. I hope the follwoing will explain why this causes me difficulty. Toy codes will probably move from Matlab to Python soon enough, if only because Python, iPython and Matplotlib are free. It's the middle ground, large codes as modified by single researchers, where much of the real work of research gets done, and the infrastructure for this use case is abysmal. The near-term solution I'm coming to is code generation. As much as possible I intend to present a clean Python interface to the scientist and generate efficient compilable code behind their back. Among the questions I'm trying to address is whether Python can or will ever be so efficient that much of my work in this direction will be abandoned. In that case, I can focus on the expression side, and leave the efficiency question alone in the expectation that PyPy (or something) will take care of it someday. Another question is which language I should use as the back end. C or even F77 can be coupled into the interactive environment on the fly. Actual production work, of course, gains nothing from interactivity, but we are still envisioning a significant scientist/developer use case; in fact, that's the point. Whether I like it or not, the group I work with is interested in is in F90 source. (CCSM) This has proven awkward to integrate into Python, though not impossible for some compilers thanks to the work of the Babel and Chasm groups. In practice, had the professional coders developing CCSM used C++ rather than Fortran90 (or even had they stuck to F77), we would be in a better position to expose a well-defined low-complexity high-efficiency layer to the non-CS specialist physical scientist. That's a mouthful, I admit, but (trust me) the world would be a better place if it were done. So such advantages as do exist for a professional full-time computational science group in developing CCSM in F90 have ended up as a hindrance to what my constituency regards as the most important use case. Beliavsky's summary of what is available is a taxonomy of distinct islands of production with tenuous connections between them. I don't want quick-code slow-run "alternatives" to slow-code high-performance production codes. I want, and my users need, a unified scientific software environment which provides powerful expression without sacrificing performance or interoperability. Do I expect Fortran to go away? Not anytime soon. Do I expect an alternative to emerge? Indeed I do, and I hope to be part of said emergence. In fact, I don't know what the high-performance scientific computer language of the year 2020 will look like, but I, for one, would like it to be called "Python". mt -- http://mail.python.org/mailman/listinfo/python-list
