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."

Comments

Better than Java?

[eklitzke]

From the article: "Guy Steele leads a small team of researchers in Burlington, Massachusetts, who are taking on an enormous challenge -- create a programming language better than Java." I tried to think of a witty aside, but I realized I didn't have to.

Re:Better than Java?

[Decaff]

I know java and use it where it's approiate but I can't understand why people think it's such an amazing language. I understand it's merits but it's still a normal programming language.

There are many reasons why Java is an important programming language. (1) It is probably the first really mainstream general-purpose widely-used language with garbage collection. (2) It was specifically designed for safety at the start, with things like exception handling, bytecode validation and security managers. (3) It is the first mainstream language to run mostly on a VM, so you get portability not just at the source code level, but at the level of compiled programs. (4) It was designed from the start to handle multiple threads safely.

Java is certainly not the most exciting language for developers to use, but that is not its point. Java is not a language of clever tricks and obscure code, like C++ can be. However, it is a very practical language that has learned from many of the mistakes of earlier designs.

If you have been developing for decades like me, switching to Java and finding the ability to write a program, compile it and then decide where it should be deployed (and have this work almost perfectly most of the time) is pretty amazing.

Re:Better than Java?

[SnowZero]

There are also reasons why Java its over-hyped:

(1) You give up speed for a marginal increase in features. (1b) If speed is not a factor, languages such as OCaml have many more features suitable for high-level programming. OCaml is also slightly faster than Java in general. Thus Java is both more primitive and slower than a language that came out in a similar time frame.

(2) You give up source portability for binary portability. Almost every platform has an ansi-C compiler, yet only a handful support Java, especially if you use a recent library. There are more platforms that support OpenGL than Java3D, for example.

(3) A company controls your language. The future of Java is at the whim of a single for-profit entity. Furthermore, this entity has displayed that it wants to control the Java language and the Java platform to the greatest extent possible.

(4) It's one of the most difficult languages to interface with C, and it pushes 100% of the glue required to the native language. It is easier to interface Lisp and Haskell with C than Java to C through JNI. Given the large difference between the former pairs, and the small differences between the latter pair, this is pretty ironic.

Re:Better than Java?

[Anonymous Brave Guy]

Recent Linpack benchmarks have shown Java can match C/C++ in terms of math performance in many benchmarks. There is no speed disadvantage for this kind of work.

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.

'do for Fortran what Java did for C.'

[compm375]

I don't think I want to learn this language...

Math++

[Doc Ruby]

I thought Mathematica was the successor to Fortran. Why don't they just improve the Mathematica calc engine for parallel/distributed supercomputing?

Worst language ever?!

[Anonymous Brave Guy]

Worst language ever. Period

Hardly. In fact, as I read the introductory sections of the spec, I found a lot of it was exactly the ideas I would have designed into a language myself, as someone who writes mathematical code for a living.

I took a bit of a sideswipe at the whitespace rules in a post below, but aside from those (which I think will die long before the final language is released, "natural" notation or not) a lot of the features look good. Things like first order functions and multiple dispatch suggest much stronger handling of functions than any mainstream language today, which is always good for a language that's going to talk about maths seriously. The consideration given to issues of parallel processing is also well beyond anything else in common usage at present, and that's surely one of the key directions serious programming languages are going to go in over the next decade as hardware becomes more and more about multi-processing rather than just Bigger And Faster(TM).

I must admit, though, that I did start to get bogged down towards the end of the section on the basics, and found it difficult to get stuck into the more advanced stuff at all, even with my CS language theory hat on.

In my opinion

[Umbral Blot]

From skimming the language spec I saw a couple cool features. One is support for multiple return values, which I love. I also liked the fobid clause, which throws an unchecked exception on certain conditions. Forbid, along with several other run-time checks in the language spec. will give fortress developers an easier time debugging code. The downside to this language however is that it tries to imitate java. Constantly the language spec compares fortress to java. I don't think Java is a bad language, however we only need one language. It would have been better if Fortress had tried to be different than Java, and explore problem domains that Java is weak in solving.

Fortran's Longevity

[Noksagt]

Fortran's longevity has come because it compiles fast programs & there have already been a ton of subroutine libraries to draw from, that have been built up over time by many coders. It is also an open standard with MANY compilers for most platforms. Will Sun work on all of this? They didn't think it was important enough to do with Java.

I think it will be hard for a single company to generate a successor & sincerely hope Sun will realize that for languages with no VM, early success will depend on openness. I also think a lot of what peopl want to do is already being done with python + modules compiled from C or Fortran.

Optimisation and community, perhaps?

[Anonymous Brave Guy]

Why do pipe stress freaks and crystalography weenies prefer Fortran?

I suspect it's mostly because FORTRAN has a lot of things built right into the language, rather than added in libraries and such. That means code can be reasonably tidy, but still leave a lot of scope for optimisation. This is particularly true when compared with the state of the art in optimising for difficult languages like C, where even today relatively simple optimisations can be difficult because of aliasing issues and the like.

It's also worth noting that when most of a serious community use the same tool(s), a lot of new work will be done using those tools simply because of familiarity, community and support issues.

So they finally admit Java was broken?

[synthespian]

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?

Re:Dear God

[linguae]

I wouldn't call Fortan the worst programming language ever; COBOL takes the cake (all of those long words for everything, geez!). It's actually still used heavily in scientific computing, and even though it started out like something that looks like the monostrities of COBOL and BASIC (such as goto statements everywhere, forced indentation, verbosity, and other stuff), the lastest standards of Fortran look decent and have a lot of features that languages such as C has and looks like it has became a much better language. For example, Fortran now supports dynamic memory allocation, structure (such as if...else statements and looping), recursion, arrays, operator overloading, records, and more. The features of the language aren't bad.

Fortran's niche is in scientific computing and numerical computing, since not too many languages come close. It's not the best language for every application, but it works well for scientists and mathematicians.

illogical name

[jjeffries]

One would assume that the successor to Fortran would be called either Nextran or Fivetran.

Re:Please Explain

[Jrod5000 at RPI]

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

Re:Please Explain

[ikekrull]

As far as I understand it, it is due to the inability of a compiler to optimise execution flow where pointers are involved.

With C etc. you cannot know at compile time how much space the data referred to by a pointer will consume, or what it will be. This makes optimising certain routines w/regard to data alignment and packing difficult or impossible compared to FORTRAN.

Various mathematical routines run a hell of a lot faster under FORTRAN than they do under C becauase the FORTRAN compiler knows ahead of time exactly 'what it is getting', and can thus make a decision as to how to feed that data to the CPU to take advantage of its register, cache and instruction scheduling characteristics but sacrifices the flexibility of the 'data structure languages' like C.

Implementing complex, dynamic structures of arbitary 'objects' is childs play with C but something that would drive you batsh*t crazy using FORTRAN.

Re:Please Explain

[NoOneInParticular]

Fortran has bounds checking and doesn't have pointers. The last part is important, because it means that the compiler can do a much better job at optimization. Look at the following C-snippet:

void f(double *a, double *b, int sz) {
int i;
for (i=0; i < sz; ++i) {
*(a+i) = *(a+i) + *(b+i);
}
}

Having only this information, the compiler has no way of knowing that 'a' and 'b' do or do not point to the same piece of memory, and thus it cannot optimize this loop (as b might point to a-1 for instance). In Fortran the compiler does have this information and can optimize accordingly. Note that this is only a problem with C, not with Pascal. Pascal can in principle run as fast as Fortran, but is probably even more annoying.

Interestingly enough, C++ should be able to reach Fortran speeds when the C++ compiler writers would finally use the leanage they've gotten for optimizing the hell out of 'valarray'. This class doesn't have aliasing problems and can be used in the same way as Fortran arrays.

For the rest, the freaks and weenies have simply been brought up with Fortran and therefore prefer it.

Do they understand why Fortran is liked ?

[aepervius]

I am seeing the first page of the draft and already I see talk about objects... Man.... Do they understand that *WE* do use fortran because of the mathematical bibliothek, the extremly well optimised high performance generated code even massive parallel calculation code ? If this things doesn't have the same performance as fortran *AND* is backward compatible with existing fortran programs it is dead in the water. Why do they think that most scientific out there I know of are still using fortran for ? Do they really think we need abstract stuff with object ? If we did we would use a c++ code+compiler, not fortran

Indeed a search of the spec says "no attempt at backward compatibility/this is a new language with little relation to fortran".

Nothing to see here. Somebody with new idea he thinks are nifty , and forgot from sight why fortran is still used now.

Re:Please Explain

[Rakshasa Taisab]

For C this is true, but C++ has gained alot of ground on Fortran through the use of templates and template metaprogramming.

Blitz++ performs very close to or better than Fortran on many numerical calculations.

'do for Fortran what Java did for C.'

[forgoil]

First of all, shouldn't it be "what Java did for C++", and second of all the answer to the question in the subject is:

"Fuck it up."

Couldn't help but notice

[theguyfromsaturn]

that Guy Steele has no beard. According to a previous article (can't seem to be able to find it) on Slashdot, this means that this programming language will never become mainstream. When will new language designers realize that they need a beard to break through?

Re:Please no...

[dhakbar]

b******s?

biscuits?

Re:Matlab

[Illserve]

You don't understand matlab, it runs slowly only because your coders don't know the features of Matlab that they must stay away from.

Think of it like this:

C lets you do X, very fast.
Matlab lets you do X very fast, and Y fairly slowly.

Inclusion of any elements of Y into a predominantly X piece of code will bring the whole lot down to Y speed.

There's no inherent advantage of C (as far as I can tell and I've got years of experience in both), it's just that people tend to roll X and Y together in a Matlab program.

Admittedly, this is the fault of Matlab, in letting you do this without warnings, but there is documentation provided that tells you what the set of Y is and gives some hints for recoding bits of Y as X.

So basically, people who program in C are denying themselves the joys of MATLAB's high-level functionality, and in return are still having to code everything in terms of X.

I have given up on C completely, if I can't write it in MATLAB and have it run fast, it means I don't understand the algorithm well enough and should get back to the drawing board.

Btw, your attempt to divide programming into categories of "serious" and not is laughable.

If anybody can do in Fortran, it's Guy Steele

[alispguru]

Guy Steele is relatively unknown outside the Common Lisp and Scheme communities, and he's overshadowed in the Java pantheon by Gosling, but he's had more influence on more programming languages used by more people than anyone else I can think of:

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.

Give it up, Java Weenies!

[Frumious Wombat]

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.