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."
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.
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.
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
In my earlier post I may have come off as a troll, but really, this is just absurd. Sun cranks out tons "alternative" methods of getting things done in hope that one of them will catch on. Java caught on, so, they have decided to just keep trying to do things the way they came up with Java: "Better" another product and make the required amount of changes to avoid any patent or property disputes. To me, Java was unbearable. Reading Java code is like attempting to find a needle in a haystack and then to volentairly stab yourself in the eye with it....repeadedly. Java is the messiest language that has ever become mainstream. Java is essentially C without any order. It gave C somewhat of a bad rap because of the relation of the two languages. I really dont want to see this happen with Fortran, as it is a pleasure to write. Sun will once again destroy a once monolithic language.
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.
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.
"...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.
As a computational scientist I assure you it does not work well for me. My Boss...he is a die hard FORTRAN coder and we bicker back and forth. Yeah he may compile a small program to run faster than my C++. However when the project goes from 100-1000 lines of code to 10000 lines and up he can't even come close in time to code and speed of execution. But I must admit I have a rant against FORTAN code because I have had to debug some of my bosses and he is a horrible coder at best.
You're wrong; the actual controversial rule is the use of whitespace to represent multiplication. YES, just like in that "overloading the whitespace operator in C++" april fool's we saw a few years back, but this time for real:will do the same thing asin Fortress.
Could be... uh... fun to use.
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.
Lol. Funny, but really Sun's point of view is quite off. I really take heart to issues involving the merits of java. I'm in my senior year of high school right now. For the past 3 years our school has taught programming in nothing besides java. There are plenty of java zelots at our school (including the programming teacher *pulls out hair*) that insist that soon everything will be done in java, that C, C++, and perl are dead languages. Oddly enough our computer club does computer related fundraisers (for example we offer a matchmaking services to the students called computerdate). This year I rewrote all the old Pascal programs that we use for them in VB. We've sent teams to 8 or 9 programming contests, 4 or 5 of them we've won using Python where allowed and C++ the other times while the java teams consistantly placed last. The three of us that know C++ (we have about 40 kids in our computer club) even won a java triva contest. 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.
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.
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.
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.
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.
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.
From skimming the language spec I saw a couple cool features. One is support for multiple return values, which I love
Ohh, you mean like Perl?
I also liked the fobid clause
Ohh, you mean like Perl?
Java runs in a VM, has garbage collection... you mean like Perl. But did you say Java isn't open source? Too bad it's not like Perl!
If you call slow and prone to crash "almost pefectly", then I agree with you. It's becoming tiring to encounter what should be a full-fledged Windows or Mac program coded in Java because a software-maker was too stingy to develop a proper application. Remember -- programming is for users, not for developers, and if to users your program hampers productivity and feels wrong, then it is wrong.
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.
Strangely enough, Matlab is written in Java and its port to Solaris is SLOOOOW as hell. Literally, it's 10x slower on a Sunblade 1000 than an equivalent x86.
/w Linux are cheaper than Sun hardware /w Solaris.
You'd think Sun would have a good JVM on their own hardware, but the reality is that it sucks.
My research group is switching to Linux because 1) the software runs faster and 2) PCs
Favorite
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.
Been teaching some supercomputer things to kids at a local college. All they know are C++ and Java. Its pathetic. But thats besides the point.
Fortran, contrary to these folks understanding, is not broken. It is not in need of fixing. Some other language is (cough cough) horribly broken (specifically in numerical areas, raw performance, readability, etc)
Fortran is pass by reference, makes lots of things very easy. Fortress is java like, as pass by value. Looking over the spec, it is fairly obvious to me that the folks who designed it are not Fortran users, programmers.
They should go back to the over-caffinated land they came from.
and their lack of memory management and safety
People don't pay me because I do something easy and safe. They pay me because I do something that most people cannot do, no matter how much time they may dedicate to it.
Progressively easier and safer languages will bring "toy" coding closer to the mainstream (though never quite to the mainstream, since coding takes some real thought, and people dislike having to think). But forcing people who can actually code to use castrated languages just wastes time and resources. You want a cute webpage, use a safe language; You want an OS, use C. You want MS Paint, use a safe language; you want The GIMP, use C.
Computers "speak" machine language. Assembly gives a near 1:1 translation of that, but takes too much work to maintain (and I'll admit that even as someone who likes asm and doesn't hesitate to use it sparingly when platform independance doesn't matter). As long as our computers have a CPU even remotely like what we currently have available, C provides a near perfect balance of closeness to the CPU (with some care, you can translate most C to ML almost directly) with human readability and structural ease of maintenance.
I'm sure a large number of Fortran developers would be very interested, even if you aren't.
You want Windows' Calculator, use a safe language. You want high performance code that runs natively on just about any supercomputer, use HPF (Fortran). "Interest", perhaps. But if Fortress provides its "ease" and "safety" the same way Java supposedly did the same for C++, it will have marketing droids as its only fans.
No you don't. 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.
No, there is no speed disadvantage, there is, however, a programming disadvantage: in order to get speed in Java, you can't use any abstractions. Java is a less convenient language for numerical programming than C or Fortran 66.
And (surprise) that's why Sun has been working on Fortress.
On the contrary, almost everything about the development of Java has been handed over to the Java Community Process.
Yes, they handed over almost everything, except for their ownership of Java. Worse, almost everything new that comes out of the JCP ends up effectively being owned by Sun. So, yes, you do have a bunch of dopes that are working for free for Sun and getting less out of it than even your typical corporate researcher; at least those still get paid.
Which is nothing compared to the disasters that have resulted from the use of C and C++ over 20 years.
Don't blame the hammer when the homeowner insists you finish the job in half the time and under budget, then the house falls down a few years later.
And if you believe the same (via different mechanisms) won't happen under Java, or Fortress, or any supposedly "safe" language - I have a bridge to sell you. Buffer overruns occur because of sloppy coding - In 90% of cases I've personally had to deal with, simply using snprintf() rather than sprintf() (or some comparable pair of "dumb" and "length specified" functions) would solve the problem. Do you really think that similar oversights won't affect Java in some way?
I think you need to take a look at the real world, where Java is the most widely used language.
Your source for that factoid? I communicate with quite a lot of real-world programmers, and although I wouldn't discount the number doing Java (mostly not by their choice), when it comes to getting actual work done, almost everyone chooses C or C++.