Sun Releases Fortran Replacement as OSS 233
sproketboy writes "Sun Microsystems has released an alpha version of a new programming language called Fortress to eventually replace Fortran for high performance scientific computing tasks. Fortress was designed specifically for multi-core processors and is published under the BSD license."
This is fake... (Score:5, Insightful)
Bah... Slashvertisement...
APL (Score:3, Insightful)
``Mathematical notation: We would like to reduce the time it takes for a domain expert to turn a mathematical specification into a working high-performance program. We are examining language changes which would enable computations to be written in a more mathematical format.''
So does this mean they will bring back APL?
Personally, I find functional notation and names much easier to understand than mathematical notation and symbols. Of course, I'm not a mathematician, so I guess I'm not the target audience for this project. However, I still think this is a really bad idea.
Re:Fortran has some coolness (Score:5, Insightful)
I wrote a Fortran program that printed out a calendar with the year in a banner font at the top. It took 57 cards (no library calls etc, beyound PRINT). Try do anything useful in 57 lines with today's languages.
Mike.
Multi-core? (Score:3, Insightful)
I don't see anyone trying to give credit where due (Score:5, Insightful)
They are doing this in complete (nearly) opposition to the position that MS takes. I think Sun deserves a little credit. The did (sort of) open some of the hardware as well, and while that may not fall into hobbyists hands soon, it is a start. Opening (in any meaningful fashion) some high end hardware is a big thing.
No, I don't have tons of Sun hardware or software at home, but I do use it at work, and its incredibly stable, if not super easy to administrate.
Re:Multi-core? (Score:4, Insightful)
Comment removed (Score:3, Insightful)
Re:Another winner from Guy Steele (Score:3, Insightful)
I lack the fortran experience (I've only done the bare minimum of fortran programming), but I do have the math, and from my perspective, having read through the fortress spec (PDF) [sun.com] (okay, I skimmed it - it's huge) it looks like an excellent language for any mathematics intensive work (and indeed physics too, with its support for dimension and unit annotations). There's a great deal to like about the language. I hope it is successful.
Re:What's it look like? (Score:3, Insightful)
And most keyboards will pitifully fail to type, in any straightforward and reliable way.
And most monitors will fail to display unambiguously, in any straightforward and reliable way.
Programming should be based on mathematics, not written in it -- and that's from someone who writes specialist mathematical libraries for a living. Seriously, if TeX is the least friendly programming environment I have ever encountered in serious use, and the average programming font has trouble distinguishing (, <, { and [ characters, making code look more like typeset mathematics is not the way forward.
Re:Fortran has some coolness (Score:2, Insightful)
Yes, because in physics, nothing is like anything else. (rolls eyes)
Mike.
as opposed to pgfortran? (Score:3, Insightful)
Re:Fortran has some coolness (Score:3, Insightful)
Naturally in many types of scientific programming, object-oriened design isn't strictly necessary and can get in your way. Most of these programs are simple programs designed to do one task -- calculate this or simulate that. But as you get more and more complex, with lots of little discrete parts that need to interact in specific ways, object-oriented design is, IMHO, the only way to go.
The problem with most OOP programmers is that they fail to understand object-oriented design. I think it can best be compared with the UNIX philosophy of (in this case) each object doing one thing and doing it well.
All this being said, you're right when you say that OOP is geared as business programming and business logic. OOP is a perfect match for relational databases, for example. It's also a very good match for GUI development, since you have all of these compartmentalized pieces (widgets) that need to work together in a specific way (like when I click on the checkbox, this button needs to become activated, for example). If you don't have all of these compartmentalized pieces, then, yes, I agree that OOP just gets in the way.
Re:What's it look like? (Score:3, Insightful)
Re:Read the FAQ (Score:3, Insightful)
Because as programmers, we'd rather not have what essentially is a whole new edit-compile-debug cycle just to type the damn code. IDEs are great, and they vastly improve productivity, but they start to hurt productivity if they are required to do something with your code.
Re:From the specification, it is Ugly (Score:5, Insightful)
Which is to say, its aimed at the niche that Fortran, despite how old and creaky it is, still rules. The world of programming has come a long way since Fortran, but nothing matches it for scientific computing and number crunching. To be honest that's about the only aspect of Fortran worth keeping...
You say that like it's a bad thing! Eiffel is, surprisingly enough, a very nice language to work in. I'd be very happy with a language targetted toward numerics (And with real math style notation to boot!) that was as pleasant to work with as Eiffel. Design by contract is a good thing, and importantly it is optional. You can specify a contract or property for a function, but you don't have to. The ability to flesh out an API with contracts and properties is a damn good thing - something far too many languages lack.
Contracts and properties are optional. If you don't want correctness guarantees then don't use them. On the other hand if you would like a little more insurance... well then they're very useful indeed.
Again, specification of units is optional. If you don't want to worry about units then don't use them. Then again if you're writing some physics code then having the sanity check of unit analysis to make sure everything is working properly is a damn useful thing to have available. Having dimensions and units as not more onerous than having types - it is simply another level of checking available; the benefit here is that the units are optional: if you don't want the extra checks, don't use them.
Well that depends on who you are really: Fortress looks incredibly readable to me. Then again I am a mathematician and look at math, formatted in exactly that way, all the time. If you spend all day looking at Java and C code then sure, it's going to look unfamiliar to you. Then again, you probably aren't in the target market for a language aimed specifically at scientific computing. To me a lot of C looks awful and can be hard to read because of its requirement that you pound everything into basic ASCII. It really all depends on what you're used to. As to how easy it is to enter - sure it would be nice if it was straight TeX - but then it is so similar that there is really no problem learning it. If you actually do a lot of math then you can name all those symbols straight away, and what you have to type in to get the symbol is simply it's name. Again, not ideal for people who don't do a lot of math, but then that isn't the target audience. If you do much math then the symbols look right instead of being the ugly ASCII kluges of other languages, and
Re:Multi-core? (Score:3, Insightful)
I beg your pardon, if we need to use and learn a specific language to take advantage of the multicore technology, it is mainly because it is not automatic.
So, I guess learning the language itself is only part of the problem. The other one will be to be able to identify by hand what can take advantage of the multi-cores and how.
I don't see were there is a big advantage to use this language for the users, maybe Sun is seeing much advantages to it for writing a backend, but right now it's only smoke.
Not at all (Score:1, Insightful)
It's a "draft specification" -- calm down. And an interpreter is a great first step: it makes it easy to play with the language.
If you've ever written a compiler, you know that an interpreter is just a compiler that calls eval() on the nodes of the AST, instead of emit() to generate opcodes. It's half a compiler, and arguably the more useful half.
They could have waited until they had the opcode generation and optimization working, but what would be the purpose of that? It's useful today, even if it's not super fast. Premature optimization, you know -- better to get lots of feedback about the language before you spend a bunch of time tweaking your optimizers.
woo...hoo... (Score:1, Insightful)
http://it.slashdot.org/article.pl?sid=06/11/22/20
Perhaps deriving "integer" from "commutative ring" made people think Sun went a little overboard with the OO.
Re:Wellllllll... (Score:3, Insightful)
You may as well say the STL is bad because it gives you multiple data structures!
Only the basic array is part of the Java language, all the other structures are library based (exactly like C++ with STL!)
Talk about FUD
Re:Fortran aint that fast... (Score:4, Insightful)
Fortran (and Ada) are languages that understand arrays.
In C, an array is a pointer, an offset, and a prayer.
Re:Fortran has some coolness (Score:3, Insightful)
Re:Fortran has some coolness (Score:3, Insightful)
If debugging is hard it can be for a couple of different reasons. You may have poor debugging tools. Or the object abstractions used in the program may not be very conceptually clear and well-designed. Or maybe as a Fortran 77 programmer you're just used to seeing 500 lines of code all straight in one function modifying global variables and find it hard to step into lots of function calls, whereas on the other hand OOP programmers would feel lost in a massive 500-line function that modifies global variables and are more comfortable stepping into well-named functions with clearly defined inputs and outputs for which you can write clear, low-level unit tests.
What OOP is not generally good for, however, is speed and performance. The function calls are intended to mask the irrelevant details of how things are computed, but they end up also masking how long a computation takes and hide opportunities to eliminate redundant computations. The OOP community talks about optimizing compilers and function inlining, but in C++ anyway the problems of separate unit compilations and header file dependencies make these solutions nasty and suboptimal, and most other OOP languages have overheads that are even worse. It will be interesting to see how Fortress addresses these problems, with so many languages to learn from and no need for backwards compatibility they should be free to come up with something that enables the best of both worlds.