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."
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.
#include ".signature"
Also at least one whitespace rule that will make Python's syntax look uncontroversial. ;-)
<Obligatory> Don't you just hate getting a story rejected and then seeing it posted from an AC several days later? :-( </Obligatory>
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I don't think I want to learn this language...
I thought Mathematica was the successor to Fortran. Why don't they just improve the Mathematica calc engine for parallel/distributed supercomputing?
--
make install -not war
Alright everybody. Man your Fortress!
Is Sun evil? I don't really think so. I think they're just misguided, and I really hope Fortress doesn't become prevalent in an area that I have to work in. I don't see this turning out well. Lots of good ideas making a good thing worse.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
Philosophy.
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.
Well, it seems to me that 90% of scientific computation today is done with Matlab and similar languages/environments (well, mostly Matlab).
Based upon my experiences, within universities, ONLY in CS departments Matlab is NOT (yet ?) the de facto standard (but it is still tought and used anyways, along with java and some C++).
We learn from history that we learn nothing from history - Tom Veneziano
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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
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.
its specification allows for more aggressive compiler optimizations than C. fewer aliasing issues for example.
One would assume that the successor to Fortran would be called either Nextran or Fivetran.
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
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.
I gots ta ding a ding dang my dang a long ling long
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.
Times change. Fortresses fall. The fortress of FORTRAN must fall too. Let us weep for it.
APL was far more powerful for array handling than FORTRAN. APL is like Matlab, only with a much more powerful syntax for handling n-dimensional arrays of numbers. Want to add 5 to every element of array, X? Then just say 5+X. No DO loops, no indexing through all the elements, just one simple statement. It doesn't even matter is X is a vector, 2-D array, 3-D array, or whatever. Need an 3-D finite difference gas diffusion simulation for N different gases? Just create a 4-D array and a program of under half-dozen lines handles the core diffusion estimation process (with no awful nested loops). Because APL is inherently array-oriented, most statements can be vectorized automatically very easily.
I'm not saying that APL does not have its faults (the original version was weak on control structures and data structures other than arrays), but it's core syntax and native handling of multi-dimensional arrays make it idea for scientific computing.
Two wrongs don't make a right, but three lefts do.
Please modify parent -1 "Should have googled obvious question". The Fortran FAQ answers: http://www.faqs.org/faqs/fortran-faq/
Advice: on VPS providers
"...programming language notation is different from the working notations of mathematicians and physicists and chemists. Why can't we bring them close together? That's one of the conjectures we have in Fortress. What if we tried really hard to make the mathematical parts of a program look like mathematics?" he adds.
This is simply not a problem most mathematicians, phyicists or chemists have. I've never said, "Damnit, why doesn't the FORTRAN code for this thing look more like mathematics!?" Neither has anyone I know.
The best high-level mathematical language in the world--Mathematica--has input that looks very little like mathematics. Integral[Exp[x],{x,0,1}] expresses the mathematics very elegantly in a pure ASCII, standard, portable, form. But it looks nothing like what you'd write on a piece of paper, if that's what "looking like mathematics" means.
Furthermore, there has been a language that looks a great deal like (parts of) mathematics: APL. No one uses it, and part of the reason is that the statements are far too compact--i.e. "mathematics like"--to be readable.
And finally, what does "mathematics" look like? Different fields use radically different notations and conventions. This is particularly true when you start looking across math, engineering and physics. Even different branches of physics are apt to use different notations for the same thing, and worse yet the notation changes over time--go look at any pre-war book on quantum mechanics and you'll see all these "Sp" things where today you'll see "Tr". And things like vectors are typically typeset in bold, but have over-scored arrows when you write them by hand. Which of these "looks like mathematics"?
Locking any of this down in a programming language is just not useful.
--Tom
Blasphemy is a human right. Blasphemophobia kills.
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.
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
No, I'm afraid it's worse than that.
They use a series of identifiers separated by spaces to represent either function calls or multiplication, depending on context. The dependence is relatively subtle, too: uses of () for function calls seem to depend on how many parameters the function takes, for example...
Unlike the April Fool proposal for C++, this is actually, serious BTW.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
- These characters were randomly selected.
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."
Having loops be parallel by default, on the other hand, is going to explode a lot of heads. Can you imagine what it will be like to write a loop which doesn't depend on the effects of any previous iteration?
Granted, this has existed in various supercomputing languages and VLIW/vector processing assembly since the 80s, but trying to push this out to the masses is pretty revolutionary. A lot of people are going to see it as a serious drawback, and either shy away from Fortress or ask for sequential loops explicitly everywhere, unless they can be taught how to parallelize, which is often a very difficult task for all but the simplest loop side-effects. Sometime's it's just hard, and sometimes it's NP-hard, depending on the details of the algorithm considered for parallelization.
Frankly, given that functional style is much less of a stretch from ordinary procedural programming, and given how slowly ML variants and things like Haskell have been catching on, I guess Fortess is destined for permanent niche status, and not even math typography will save it from consignment to the high-preist class of supercomuter programmers. In fact, that may be a disadvantage, because the scientists writing the formulae aren't the engineers translating those formulae for parallel processing, in most cases.
Besides, as the "Real Programmers" phrase goes: "Real Programmers can program FORTRAN in any language."
(I've always liked that; I prefer FORTRAN to other high level languages. But then, I am a dinosaur....)
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?
I like my dinosaurs feathery, and my pterosaurs hairy (or is it pycnofibery?)
b******s?
biscuits?
This programming language's name is obviously derived from my Slashdot nick. My SWAT team of highly-paid lawyers is examining a satellite photo of Sun's corporate headquarters, planning their legal assault.
MATLAB started as a Fortran library it seems. As handy as it is, MATLAB has some dire limitations: its performance and syntax. While certain vectorized operations can be speedy, many folks I know end up recoding in C because MATLAB just crawls for everything else. On top of this the language itself is just plain ugly. It's reminicent of BASIC with random bits of bash scripting and other oddities thrown in to make a patois that is decidedly disgusting.
I myself have switched over to using R for statistical computing mainly because it's nicer to look at than matlab and has some really great statistical facilities built right in. For more analytical stuff, Mathematica or its open source cousin Maxima are definitely a better choice.
What excites me about Fortress is that it's both cleaner looking than MATLAB and has some neat features like traits. I'll be curious to see how it pans out.
You mean they are going to castrate Fortran such that idiots can use it, and only idiots will want to use it? We don't need Java, we need people to f$cking learn to program. You get payed decent money for programming don't you have the responsibility to actually learn your profession, rather than depending on castrated tools to prevent you from getting into trouble?
Unicode operators aren't just for math heads. If there were more characters on the keyboard one could imagine a more reasonable solution to the = vs == problem.
The Perl 6 "spec" calls for at least one unicode operator, as a way of wading into those waters for more general purpose use.
"Why do pipe stress freaks and crystalography weenies prefer Fortran?"
One simple answer is We're not writing a F'ing application!!
A great deal of scientific programming done by scientists and engineerse is NOT to develop an application with a nice gui and users manual - it to solve a complex problem ONCE for him/herself ONLY and get data/results that can be processed by other std application. Rude, crude, and vulgar - tha't is just fine! I write BASIC, Fortran (for 30 years) and C#, assembler, (all of the above) etc, and find that when I want to solve a problem, the last thing I want to pgm in is Cxx. I have watched sw programming change over the years from an emphasis on problem-solving to applications, applications, applications. Not everyone wants, needs, or has time to write an "application" package, Just give me my answer.
Cloned foods give the statement "We had that last week!" a whole new meaning.
C++ has gained alot of ground ... through the use of templates and template metaprogramming
The phrase "phyrrhic victory" comes to mind.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Anyhow here's a few of the cool things. First all variable transactions will be atomic so that you can write parallel code with no locking or syncroization.
Parallelism is in it from the start. The assumption will be thousands of threads running on multiple processors. All loops will be done in parallel--you actaully will have to request serial loop order execution if you want it.
data types can be contain distributed data. this fits the multi-processor design.
It's more than unicode they are talking about. The IDE will support full 2-dimensional mathematical notation. That is it will look like TeX mathematics. If you write a Summation from 1 to N then it will display a summation symbol with I = 1 on the bottom and N on the top. Likewise division will have a numerator with a line under it and a denominnator below it. Ifwrite a matrix traspose the thre will be a matrix symbol with a superscripted T. Also there will not be any Asterix to denot multiplications. Mathematicians dont use these. If two variables are adjacent it means multiply.
Now the cool thing is all those will be due to the IDE not the language. if you open it in emacs it will stillbe editable in ascii.
The point of the excersize is that the code should look like the pseudo-code you find in a mathematics journals. The examples they give comapare a math journal spec to the real code and to code from a non-mathematcal language like C++. There is huge difference in readability. Any mathematician coud debug it without knowing the language.
Optimization will emphasize allowing one to work with objects without losing the speed of primitives.
The language syntax will be extensible not frozen by the complier.
Some drink at the fountain of knowledge. Others just gargle.
To those people who detest using Fortran, check out http://www.scipy.org/ .All these libraries are based on the same dependant Fortran code.
For signal,image processing and more, in a nice python syntax. Nice readable code, no learning curve!
From the website:
SciPy is an open source library of scientific tools for Python. SciPy supplements the popular Numeric module, gathering a variety of high level science and engineering modules together as a single package.
SciPy includes modules for graphics and plotting, optimization, integration, special functions, signal and image processing, genetic algorithms, ODE solvers, and others.
SciPy is developed concurrently on both Linux and Windows. It has also been compiled successfully on Sun and Mac, and should port to most other platforms where Python is available.
Yes, and so does C++. What are Fortran's advantages? In the days of the VAX, Fortran compilers often generated faster code than C compilers, but this advantage of Fortran for numerical computation disappeared long ago.
OTOH, C and C++ have a cleaner syntax, no need for line labels, no need to start on column 6 or end in column 72, no need to use an * for continuing lines, etc. Oh, neither does Fortran anymore? So they acknowledge that Fortran *did* have an extremely messy syntax and tried to improve it, did they? Then why not do the right thing and improve it all the way to C/C++ syntax? Most of the improvements people have done to Fortran in the last 25 years, including the ones I quoted from your post, have been done to get Fortran closer to C, by adding features that C had and Fortran didn't.
And when you get down to numerical computation, including parallel computers, the optimization is done at a very low level, where the language syntax is irrelevant. There's nothing magic about Fortran for scientific and numerical computing. In some cases the opposite is true, C allows for better hand optimization. A competent programmer has better control of a C program, because the relationship from high-level code to machine code is clearer and easier to control in C. People often berate C for having pointers, but in Fortran *everything* is passed as pointers, as anyone who ever called Fortran functions from C programs knows.
Java is not a language of clever tricks and obscure code, like C++ can be.
Java does have some extremely clever tricks, and I'm surprised that more beople don't use them.
The primary one I have used is reflection. You can use it to navigate class strcuctures in clever ways, search for methods by pattern matching etc.For instance, I have used this as a report generator to generate reports based upon C/C++ structures exposed to Java.
Another one is NIO byte buffers I have used this to import C++ structures into Java effieciently, without any communication with C++ code.
I hope this new language has provided some equally clever tricks for the scientific community to do their computing
So, you're a better C coder than he is a Fortran coder, so Fortran must be bad? Interesting conclusion.
It's official. Most of you are morons.
Sun is not to be trusted when it comes to programming languages as far as I'm concerned. They had promised to have Java standardized by a standards body and instead withdrew and are keeping tight control of the language. They will likely do the same thing again, all in the name of "ensuring compatibility", of course.
Blitz++'s templates are so convoluted that they cause the compiler to spit out impossible-to-read error messages when something goes wrong during the template instantiation, due to a type mismatch or such. Compare this to Fortran, which gives you a nice one-line error messsage, and it should be obvious why Fortran is still the language of choice for scientific computing.
We tried. Despite our best efforts, our conclusion is that Blitz++ may be fast, but ultimately constitutes an academic exercise that demonstrates the expressive power of templates, which has nothing to do with being usable. We ended up using MTL instead, and eventually replaced that with a mixture of Lapack and our own in-house vector and matrix classes. These perhaps do not reach the speed of Blitz++, but are easier to use, and most important, a hundred times easier to debug.
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.
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
Sun's not the only one working on a language to better support HPC (i.e. massively parallel) programming. IBM's working on a language called X10, and Cray is working on one called Chapel. All three companies are being funded by the DARPA High Productivity Computing Systems project.
Will any of these replace the dreaded MPI+(C/Fortran)? Only time will tell...
What are Fortran's advantages?
Use the best tool for the job?
Fortran == Formula Translation, not general purpose bloated compiler. It's meant to convert mathematical operations to machine code as efficiently as possible. It just gives us a portable way to do more abacus/slide rule/calculator operations than assembly.
You can put a new marketing spin on anything. The point of the matter is that Fortran has evolved to suit coding mathematical systems, not to design applications. The mythical CS land where all languages are fully optimized and portable doesn't exist, at least yet anyway. If that were so people would just use symbolic math programs!
As far as syntax, I don't see how C is cleaner than Fortran. When you solve mathematical problems in physics, you always present it as a block structured set of equations. At that point, it's just a balance between how many keystrokes I have to make and how long it takes to compile/run. So why is something like exp(x,2) better than x**2?
Finally, I point to the following:
Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.
(from Revised Report on Scheme, 1991)
We don't need fortran compilers that make for easier debugging, we need bug free fortran compilers. But that is a different story...
UBU
Actually, I think we need more people to learn that programming is only a part of the job, and worrying more about doing what needs to be done and less about how l33t they are.
Personally, I think I have better things to do than chase down memory leaks. Java (for example; not my favourite language) saves me from worrying about that and allows me to concentrate on the important things.
Of course, I don't get to go wakka wakka wakka on slashdot about how cool I am because I used Duff's device in hand coded assembly because I didn't like how to the compiler optimized my code. I also don't have a manual choke in my car, do my laundry on a washboard, sparge my own malts, or still use an email bang-path from ihpn4!... anymore.
And when you get down to numerical computation, including parallel computers, the optimization is done at a very low level, where the language syntax is irrelevant.
I can't let you get away with that. Fortran was designed to have a language syntax and structure that makes compiler optimisation easy. 'WHERE' loops can be parallelised, pointer aliasing is tightly controlled (unlike C/C++), etc. It does make a difference.