Slashdot Mirror
Fortress: The Successor to Fortran?
An anonymous reader writes "A draft specification of the Fortress language was recently released. Developed by Sun Microsystems as part of a DARPA-funded supercomputing initiative, Fortress is intended to be a successor to Fortran. Guy Steele, a co-author of Java and member of the Fortress development team, hopes that Fortress will to 'do for Fortran what Java did for C.' Steele admits that Java isn't probably the best choice for numerical computing, and that 'it's a mistake to try to make a programming language that is all things to all people... because the needs are so diverse.' Fortress has a number of interesting features, including support for Unicode characters in code, enabling code to look more like formal mathematical expressions. More information about Fortress is given in interview with Steele, and in a talk by Steele. There's also some interesting commentary on Fortress, including some commentary by a member of the Fortress development team, in response to two stories at the programming languages weblog Lambda the Ultimate."
Fortress development team, hopes that Fortress will to 'do for Fortran what Java did for C.' Steele admits that Java isn't probably the best choice for numerical computing
So they finally admit that what Java did was break the IEEE floating-point specification, that was correct in C, as Professor William Kahan, of Berkeley (see How JAVA's Floating-Point Hurts Everyone Everywhere), had been shouting to deaf ears all this time?
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
From the FORTRAN FAQ (http://www.faqs.org/faqs/fortran-faq/) :
FORTRAN and C have different semantics. A FORTRAN optimizer knows more about aliasing, function interactions, and I/O. A C optimizer has to infer or compute such information. C bigots typically have neither written such optimizers nor worked with folks who do it for a living, and are prone to dismiss such arguments as being petty and neolithic. FORTRAN programmers are often a bit more in touch with high performance computing, and are unwilling to bet that heavily on compiler wizardry.
There is a vast body of existing FORTRAN code (much of which is publically available and of high quality). Numerical codes are particularly difficult to "vet", scientific establishments usually do not have large otherwise idle programming staffs, etc. so massive recoding into any new language is typically resisted quite strongly.
Fortran tends to meet some of the needs of scientists better. Most notably, it has built in support for: - variable dimension array arguments in subroutines - a compiler-supported infix exponentiation operator which is generic with respect to both precision and type, *and* which is generally handled very efficiently or the commonly occuring special case floating-point**small-integer - complex arithmetic - generic-precision intrinsic functions
Primary author of Common Lisp the Language, the community-generated pre-spec for Common Lisp
The other half of Steele and Sussman, co-inventors of Scheme
Co-author of The C Programming Language by Harbison and Steele, which codified many of the techniques that made portable C code possible
As co-author of The Java Programming Language Specification, he reportedly brokered many design compromises between Bill Joy and James Gosling
Given his track record, I wouldn't bet against him if he says he's going to create a worthy successor to Fortran.
To a Lisp hacker, XML is S-expressions in drag.
Do we really, really have to go over this well-trodden ground again?
OK, here's the short version:
If you write your Java like C, restricting the functionality you use to almost entirely low-level operations on primitives, then you'll probably get comparable performance, modulo a bit of range-checking on arrays and the like. That's not surprising, and should be true in most programming languages; any language that doesn't ultimately generate basically the same machine code to execute in this case is seriously deficient in performance terms.
Now try writing anything beyond a relatively contrived and self-contained benchmark in Java -- something that uses more involved data types than built-in doubles and arrays where bounds checking can mostly be optimised away, for example -- and see how far you get.
Sorry, JIT really helps and modern Java implementations do have some pretty good optimisations, but the design of Java fundamentally means that it will only ever approach the performance of elementary C or C++ as a limit, and there will always be a certain amount of overhead at some stage in the proceedings. You simply cannot avoid this, while still having the bounds checking, still missing value types, etc.
You could encounter an exceptionally fortunate set of conditions, such that Java has a chance of outperforming C or C++ code. You'd probably need code that ran often enough with similar enough data for dynamic optimisation by the VM to make up for the overhead of monitoring run-time performance in the first place, and then to generate better performing code on that sort of data than C or C++ code run through a good optimiser/profiler combination to produce generic output. Yes, it's theoretically possible. No, I've never, ever seen it.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
The successor to Fortran, is Fortran.
Specifically, it's F77 -> F90 -> F95 -> F2K. There have been enough attempts to replace Fortran, and the only result so far is that it's kept computer scientists entertained. All of these ideas are driven by one common thread; formally trained computer scientists can't stand Fortran 77's control structures, non-dynamic memory, etc, and demand that it must be replaced for religious reasons. F90/F95 have already fixed those problems, but it's still called Fortran, and so it simply *MUST* be replaced.
Let's see, we had PL/I (a merger of Fortran, COBOL, and Algol), RATFOR, Ada, Matlab, C++, and the late, and rather lamented, Sather. None of them has the performance of Fortran, the ease of programming, the extensive and validated libraries, complex numbers as a fundamental data type, or the solidity of compilers.
It's the cockroach of computer languages; you can keep spraying, and it will keep sneakout out at night.
the more accurate the calculations became, the more the concepts tended to vanish into thin air. R. S. Mulliken