Beta

Slashdot: News for Nerds

×

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Sun Releases Fortran Replacement as OSS

ScuttleMonkey posted more than 7 years ago | from the going-backward-while-moving-forward dept.

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

cancel ×

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

Doesn't make a difference. (2, Funny)

gardyloo (512791) | more than 7 years ago | (#17618922)

In a hundred years, programmers will be using a language that's completely unrecognizable to modern users -- and it will be called "Fortran".

Re:Doesn't make a difference. (4, Interesting)

Harmonious Botch (921977) | more than 7 years ago | (#17618970)

Yep, programming languages advance by evolution, not intelligent design.

Re:Doesn't make a difference. (3, Funny)

celardore (844933) | more than 7 years ago | (#17619120)

Yep, programming languages advance by evolution, not intelligent design.

Thanks for shattering my illusions. I thought programming languages were as they were, are, and always will be. I'm going to sue you.

Re:Doesn't make a difference. (1)

soliptic (665417) | more than 7 years ago | (#17620698)

Offtopic: Brilliant sig :)

Fortran has some coolness (3, Interesting)

EmbeddedJanitor (597831) | more than 7 years ago | (#17619152)

I used fortran quite a lot around 25 years ago. Sure it had some oddball limitations and wierdness, but it is damn fast and quite efficient for some coding purposes.

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.

Re:Fortran has some coolness (4, Insightful)

mhore (582354) | more than 7 years ago | (#17619234)

I used fortran quite a lot around 25 years ago. Sure it had some oddball limitations and wierdness, but it is damn fast and quite efficient for some coding purposes.

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.

It shouldn't surprise you... but I use fortran quite a lot today. A lot of the oddball limitations and weirdness are gone in Fortran 90/95... though I still use Fortran 77. It is still an amazingly useful and fast language to code numerical stuff in. Yes indeed. No need for any math.h in this programmer's world! I just hope this Fortress business is just as fast as fortran, because if it's not... you won't see many fortran guys switching over. The main reason (as far as I'm concerned) that we're still using it is that it is fast, and simple. OOP belongs in business... not in Molecular Dynamics.

Mike.

Re:Fortran has some coolness (0)

Anonymous Coward | more than 7 years ago | (#17619350)

How are you going with threads? NOT AT ALL!

Re:Fortran has some coolness (1)

mhore (582354) | more than 7 years ago | (#17619428)

How do I handle threads? I use OpenMP.

Mike.

Re:Fortran has some coolness (1)

Just Some Guy (3352) | more than 7 years ago | (#17619736)

OOP belongs in business... not in Molecular Dynamics.

Yes, because in physics, nothing is like anything else. (rolls eyes)

Re:Fortran has some coolness (2, Insightful)

mhore (582354) | more than 7 years ago | (#17619844)

OOP belongs in business... not in Molecular Dynamics.

Yes, because in physics, nothing is like anything else. (rolls eyes)

Nah, that's not what I'm saying. It's just that OOP can sometimes obscure what's going on and just add unneeded complexity to a program. I had a friend do some Monte Carlo stuff, and he used all kinds of OOP in his code, and it was done in a sane way. But trying to debug that code was hell. There's a place for everything, and I'm not convinced that simulations are the place for it.

Mike.

Simulations (1)

Ardanwen (746930) | more than 7 years ago | (#17620236)

Depends on your simulation. I'm pairing 1000 hosts with 10 virus quasispecies for a few million years, and objects seem to be just the way to program that. You did get me interested in Fortress / Fortran though :), as Ruby isn't the fastest of languages.. but then, when were phd's ever stressed for time?

$hosts << Host.new([1,2],HOST_POP,nil) VIR_FAM.times {|family|$virii << Virus.new(nil,family,VIR_POP) }

$hosts.each {|host| host.fitness = host.paths.inject(0) {|sum,path| sum + path.fitness} /$virii.size.to_f}

Year 1025 (41)
Host_10+14 : freq 403, fitness: 44 specificity: 0.042 0.038
Host_10+10 : freq 261, fitness: 39 specificity: 0.038 0.038
Host_14+14 : freq 162, fitness: 49 specificity: 0.042 0.042
Host_0+10 : freq 86, fitness: 23 specificity: 0.038 0.011
Host_0+14 : freq 73, fitness: 28 specificity: 0.011 0.042
Host_14+28 : freq 6, fitness: 53 specificity: 0.042 0.035
Host_10+28 : freq 5, fitness: 48 specificity: 0.038 0.035
Host_0+0 : freq 4, fitness: 6 specificity: 0.011 0.011
Allele count: 4
---------
Year 1050 (42)
Host_10+14 : freq 436, fitness: 44 specificity: 0.042 0.038
Host_10+10 : freq 258, fitness: 39 specificity: 0.038 0.038
Host_14+14 : freq 163, fitness: 49 specificity: 0.042 0.042
Host_0+10 : freq 69, fitness: 22 specificity: 0.038 0.011
Host_0+14 : freq 58, fitness: 27 specificity: 0.011 0.042
Host_10+28 : freq 6, fitness: 48 specificity: 0.038 0.035
Host_14+28 : freq 5, fitness: 53 specificity: 0.042 0.035
Host_0+0 : freq 4, fitness: 6 specificity: 0.011 0.011
Host_0+28 : freq 1, fitness: 32 specificity: 0.035 0.011
Allele count: 4

Re:Fortran has some coolness (2, Insightful)

morgan_greywolf (835522) | more than 7 years ago | (#17620334)

An OOP program that follows good object-oriented design principles will actually be very easy to debug.

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:Fortran has some coolness (1)

infofc (979172) | more than 7 years ago | (#17621002)

I beg to differ. OOP is a way to structure the concepts in an application. OOP does not specify that you have to split an isolated concept into a multitude of classes if that goes contrary to the goal for performance reasons. A good architect will have no problem doing a solid object model during analysis and modify part of it to accomodate performance requirements. Especially if you use something like C++ you know perfectly well how the resulting code will behave. That being said, there is indeed a place for everything.

Re:Fortran has some coolness (1)

Chris Mattern (191822) | more than 7 years ago | (#17620366)

> OOP belongs in business... not in Molecular Dynamics.

Because Molecular Dynamics doesn't deal at all with self-contained interacting entities!

Chris Mattern

Fortran aint that fast... (3, Interesting)

spagetti_code (773137) | more than 7 years ago | (#17620532)

I know that Fortran has a good reputation for speed...

But when I was postgrad at university, I helped a Math mate recode some department apps used in his thesis from Fortran into 'C'.

The end result is the damn stuff ran faster. I looked into it more deeply to try to understand the difference - was it that I (comp-sci major) was coding the apps more cleanly than the original math majors?

Details are lost - it was a while ago - but I do recall that the 'C' libs were doing most floating point operations faster than fortran. Not just the low level co-processor stuff, but also the more complex operations.

Surprised the heck out of both of us. I suspected at the time that it was just the variant of fortran we were running on Vax's, but didn't bother checking further.

Something short and useful in a modern language (1)

scwizard (941758) | more than 7 years ago | (#17619298)

boss <('_'<) UseAttack() <('_'<) "Die ^.^"
platform (>'_')> Jump(HIGH) (>'_')> level.end
<(^_^)>

Re:Fortran has some coolness (3, Insightful)

Stephen Williams (23750) | more than 7 years ago | (#17619402)

Try do anything useful in 57 lines with today's languages.

Given that DeCSS can be written in six lines of illegible Perl [cmu.edu] , I shudder to think of what a Perl coder could accomplish with 57 lines...

-Stephen

Re:Fortran has some coolness (1)

cp.tar (871488) | more than 7 years ago | (#17619676)

Maybe... an OS?

And it would still be easier to debug than Windows.

Re:Fortran has some coolness (1)

PhunkySchtuff (208108) | more than 7 years ago | (#17619466)

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.

You've never tried to write anything in Perl, have you?

Re:Fortran has some coolness (1)

repvik (96666) | more than 7 years ago | (#17620098)

Pah! That's nothing. You didn't put any limitations on linelength, so a perl one-liner can do pretty damn much ;-)

Wellllllll... (2, Interesting)

SatanicPuppy (611928) | more than 7 years ago | (#17618948)

Much as I like Java, I'm not exactly sure how much a fortran-esqe language is going to "benefit from the lesson's learned with Java". It's apples to oranges, because of fortran's narrow focus, and equally narrow deployment base. Java's primary schtick is in the exact opposite direction, with wide focus, and deployment on a large number of systems.

I suppose increased multi-processor support would be nice. It'll all depend on performance.

Re:Wellllllll... (2, Funny)

metamatic (202216) | more than 7 years ago | (#17619238)

Perhaps by benefiting from the lessons learned with Java, they mean they're going to plan ahead and have just the one implementation of each major data structure, rather than (for example) 4 different array implementations.

Re:Wellllllll... (1)

MikkoApo (854304) | more than 7 years ago | (#17620716)

Do you mean arraylist, vector, arrays and such? Different implementations are supposed to be used in different scenarios.

arrays = non-dynamic, very fast insertion & seek
ArrayList = dynamic, moderate memory usage, quick seek, possibly slow remove & insertion
LinkedList = dynamic, quick remove & insertion, slow seek & uses more memory than arraylist

There's also different algorithms & implementations for different concurrency needs & so on.

Having abstract interfaces to different implementations & algorithms is definitely a nice thing. You can implement your code by using the any implementations. You need to worry about the different implementations only if your code is not efficient enough and based on profiling and analysis you should be able to determine which implementation(s) should be used.

Re:Wellllllll... (1)

drgonzo59 (747139) | more than 7 years ago | (#17619242)

It's not really a Fortran-esque language. If you would have clicked the link to the project page you would have noticed that...

The language tries to mimic mathematical notation and thus it wants to appeal to scientists more than anyone else. You if you are a regular programmer that does web development or database or anything except scientific computing, there is nothing for you to see here, move along. You can still safely continue using Java or C++.

Re:Wellllllll... (2, Interesting)

geoff lane (93738) | more than 7 years ago | (#17619248)

Fortress doesn't look anything like Fortran.

The source form looks more like Algol60 printed on a flexowriter (all aged programmers will recognise this blast from the past.) There is some resemblence to BCPL. But the language is much more complex than anything most people will be familiar with.

Re:Wellllllll... (1)

Lawrence_Bird (67278) | more than 7 years ago | (#17620130)

actually seems more APL like than Algol like to me but I don't pretend to be more than
a minor hack in either.

What's it look like? (1)

The MAZZTer (911996) | more than 7 years ago | (#17618960)

Anyone wanna post a sample "Hello World" program or something? I don't see any code samples printed on the site. I wanna see what this looks like!

symbolset (646467) | more than 7 years ago | (#17619016)

The FAQ [sun.com] gives this pdf example [sun.com]

This one looks like a winner.

Yold (473518) | more than 7 years ago | (#17619170)

Looks sort of like Maple...

I am wondering, as a college student who is beginning to get into a financial profession typically dealing with immense datasets, how much value will this be to scientists/mathematicians/statisticians? Wouldn't it make more sense to prototype something in Maple, PERL, etc... and hand it off to programmers to implement a full model at top speed? In other words, is there any value to learning FORTRESS analagously to the value of learning FORTRAN in the 70s-80s? Haven't advances in computing rendered these languages obscure?

Anyone doing modeling with extremely large datasets wish to comment? Should I bother to pursue low-level programming languages?

LWATCDR (28044) | more than 7 years ago | (#17619482)

"FORTRESS analagously to the value of learning FORTRAN in the 70s-80s? Haven't advances in computing rendered these languages obscure?"
Yes and yes but obscure doesn't mean usless.

I don't know about Fortress but Fortran is still used because it is the best tool for the job. If you have are really large dataset program that you hand off to a programmer he or she may use Fortran for that program.
Why is Fortran still a good solution?
1. It is really easy to optimize.
2. It has a lot of very useful and tested libraries available.

Without looking at Fortress I don't know if these strengths will carry over.
"Wouldn't it make more sense to prototype something in Maple, PERL, etc... "
Why code it more than once. Fortress is going to handle all the math notion that Maple does so Maple may not be any easier to use. And for love of GOD don't prototype anything in PERL!
Perl has it's uses but their are much better languages to prototype in.

mhore (582354) | more than 7 years ago | (#17619686)

Looks sort of like Maple...

I am wondering, as a college student who is beginning to get into a financial profession typically dealing with immense datasets, how much value will this be to scientists/mathematicians/statisticians? Wouldn't it make more sense to prototype something in Maple, PERL, etc... and hand it off to programmers to implement a full model at top speed? In other words, is there any value to learning FORTRESS analagously to the value of learning FORTRAN in the 70s-80s? Haven't advances in computing rendered these languages obscure?

Anyone doing modeling with extremely large datasets wish to comment? Should I bother to pursue low-level programming languages?

Looks a lot like Pascal, too.

Let me speak as a scientist. Looking at the example in Fortress, this is beneficial for some of my colleagues who are not programmers per se. It allows them to maybe focus on the math instead of the logic and overhead (small as it is) of actually writing a code. Somethings cannot be modeled in Maple, for example, and then handed off to programmers to implement. Secondly, there is the chance not all programmers would understand the underlying science that would allow them to make sure their implementation is producing correct results. If one were to prototype something in Perl... well, you may as well just use C (though I prefer Fortran! ;) ) and write the program since the syntax is so similar.

I model large datasets -- sometimes with 15 million "particles" (which corresponds to a lot of data... that would be 45 million coordinates, 45 million forces, 45 million velocities, etc.). Fortran is very fast. I couldn't use Mathematica or Maple for what I'm doing, and for my particular task, a C implementation had noticeable slower performance (and yucky syntax when it came to doing mathematical stuff).

I think it is definitely in your best interest to learn a low-level language -- and I would readily recommend either C or Fortran, since a lot of the high-performance libraries out there mainly support these languages only (e.g., IMSL from Visual Numerics, FFTW, and friends). Fortran is easier to start off with. C is arguably more powerful overall.

Mike.

Coryoth (254751) | more than 7 years ago | (#17619720)

I am wondering, as a college student who is beginning to get into a financial profession typically dealing with immense datasets, how much value will this be to scientists/mathematicians/statisticians? Wouldn't it make more sense to prototype something in Maple, PERL, etc... and hand it off to programmers to implement a full model at top speed?

The aim is that mathematicians can simply write it in Fortress and get a full model at top speed. Fortress is designed to be able top do high performance computing. For loops are inherently parallel and so are array operations etc. Try actually skimming through bthe spec to see what it is and what it can do - it looks like a fantastic language to me (real math notation, design by contract, traits and properties, type inference etc.)

Daniel Dvorkin (106857) | more than 7 years ago | (#17619236)

So they're going to include, what, a LaTeX implementation so programmers can make their symbols look right?

msuzio (3104) | more than 7 years ago | (#17619370)

Actually, yes, that's exactly how they are doing the mathematical notations inside the source code. I thought that actually quite clever!

Coryoth (254751) | more than 7 years ago | (#17619542)

So they're going to include, what, a LaTeX implementation so programmers can make their symbols look right?
In a sense, yes. The real question, however, is why this wasn't done earlier? Sure we have to type in code in ASCII because we're stuck with keyboards to enter it with, but that doesn't mean the default view has to be ASCII. Really, why not let your IDE render it into proper mathematical symbols for you? As a mathematician it looks damn appealing to me.

glwtta (532858) | more than 7 years ago | (#17620572)

Really, why not let your IDE render it into proper mathematical symbols for you? As a mathematician it looks damn appealing to me.

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.

Coryoth (254751) | more than 7 years ago | (#17620884)

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.

I was rather expecting the IDE to render it on the fly as you enter it, which, really, makes it no harder to deal with that mistyping a variable name (easier, in fact, given that if mistyped it won't render to the appropriate symbol). You can even expect automatic completion of symbols if you want. I would also expect a simple view toggle to let you see and edit the raw ASCII if that's what floats your boat.

Re:What's it look like? (3, Funny)

gardyloo (512791) | more than 7 years ago | (#17619020)

program Hello_world

### The following is the canonical 'Hello World' program implemented in fortress ###

print *,"Hello World"

fortress.obfuscate

end program Hello_world

Re:What's it look like? (0)

Anonymous Coward | more than 7 years ago | (#17619160)

You forgot to format it in the proper columns.

Re:What's it look like? (4, Interesting)

nuzak (959558) | more than 7 years ago | (#17619044)

http://research.sun.com/projects/plrg/PLDITutorial Slides9Jun2006.pdf [sun.com]

Fortress uses a lot of unicode mathematical operators, which slashdot will quite pitifully fail to display.

Re:What's it look like? (2, Insightful)

Anonymous Brave Guy (457657) | more than 7 years ago | (#17619492)

Fortress uses a lot of unicode mathematical operators, which slashdot will quite pitifully fail to display.

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:What's it look like? (3, Funny)

Goaway (82658) | more than 7 years ago | (#17619732)

And most monitors will fail to display unambiguously, in any straightforward and reliable way.

You may not have noticed, but cutting-edge monitors nowadays are capable of displaying graphics, and not just text.

Re:What's it look like? (1)

Coryoth (254751) | more than 7 years ago | (#17619944)

And most keyboards will pitifully fail to type, in any straightforward and reliable way.

They did think of that you know. They provide ASCII equivalents, akin to TeX, that let you type stuff in, and then it gets rendered to the appropriate symbol.

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 (,
Well that's really up to the IDE, and to be honest entering mathematics in TeX is straightforward if you have much practice with it at all. As a mathematician who needs to do programming this language looks fantastic. It isn't a language designed for general purpose programming, it's a language designed for mathematicians and scientists to code high performance software with. I expect most people in the target demographic (you, apparently, are an exception) would welcome decent mathematical typesetting when coding, especially if it is similar to TeX. As to the display issue - surely that's a matter for the IDE rendering the code. Presumably it isn't that hard to provide something that actually displays things properly (just include appropriate fonts in the package).

Re:What's it look like? (2, Insightful)

aztektum (170569) | more than 7 years ago | (#17620342)

Coming from someone who hasn't written more than a couple shell and Python scripts, why does it feel like there is nothing but resistance from the "seasoned" IT crowd over new ways of trying to do things? I'm not saying either way is better or worse, but suggesting a new method, and from my already admittedly newbie viewpoint, more "human readable" methods (in this case assuming one is a pure math junkie), for coding would seem far more natural and easy to accomplish tasks in. Inevitably though, someone always tries to cut if off at the knees as "not as good as what we already have." Is that really the case? Is it resistance to change? I guess what I'm trying to say is, without even giving something "new" a chance it's derided as a flawed product.

Re:What's it look like? (2, Funny)

glwtta (532858) | more than 7 years ago | (#17620188)

Fortress uses a lot of unicode mathematical operators

This is also something I'm really looking forward to in Perl 6; I'm guessing the conversation went like this:

Guy: "Here's an idea - let's require the coders to use a lot of characters that aren't on the keyboard!"
Other Guy: "Brilliant!"

I'm sure productivity will skyrocket with this invention.

They also seem to have jumped on the (to me) unfathomable "using braces to clearly delineate code blocks is evil!" bandwagon. I guess it's what all the cool kids are doing these days.

Other than that, it looks really neat!

This is fake... (5, Insightful)

Anonymous Coward | more than 7 years ago | (#17619060)

All they do release under an OSS license is an *interpreter* of the language. This is completely worthless for high-end number crunching. Wake me up when they open source a good optimising *compiler*.

Bah... Slashvertisement...

Re:This is fake... (0)

Anonymous Coward | more than 7 years ago | (#17620118)

Man the losers on here really amaze me sometimes. This might be something, you know, interesting to learn as they develop the language, perhaps?

Re:This is fake... (0)

Anonymous Coward | more than 7 years ago | (#17620608)

So what? Just don't lie about it in the headline making Sun look nicer than they are.

APL (2, Insightful)

RAMMS+EIN (578166) | more than 7 years ago | (#17619082)

FTFA:

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:APL (2, Informative)

Coryoth (254751) | more than 7 years ago | (#17619352)

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.

I think that depends on what you mean by mathematical notation and symbols. In the case of Fortress that means Unicode input and the ability to actually render code, thus x^2 gets rendered with a proper superscript 2, array indexes a[i] get rendered to appropriate subscripts, and you have access to other nice symbols - for instance the floating point type is denoted by a blackboard bold R (as in the usual symbol mathematicians use to denote the reals) which you can enter as RR in ascii. The result is that you can enter mathematics via the keyboard and have it rendered in code with captial sigma for sums, standard arrows and cartesian product symbols to denote function signatures, actual square root symbols etc. Think of it as enriching the symbols available to be closer to the full set symbols mathematicians expect: it doesn't result in the horribly obfuscated look of APL, but is more akin to what one would see printed in a math textbook. Read through section 2.4 of the spec (PDF) [sun.com] to get the idea.

Re:APL (1)

RAMMS+EIN (578166) | more than 7 years ago | (#17619532)

for instance the floating point type is denoted by a blackboard bold R (as in the usual symbol mathematicians use to denote the reals)''

I'm not sure that's a good idea, either, since reals and floats are different things. Reals have infinite precision, whereas precision is finite for floats.

The result is that you can enter mathematics via the keyboard and have it rendered in code with captial sigma for sums, standard arrows and cartesian product symbols to denote function signatures, actual square root symbols etc.''

Yes, that's what I imagined it would be like. I also imagine actually _typing_ something that looks a lot more like regular program code, so that you still have to learn an alternative to math notation. Also, the result will look like what one would see printed in a math textbook, as you said which is (1) not what the programmer typed, and (2) horribly obfuscated to me (which is a personal thing, but applies to many people).

Re:APL (3, Interesting)

Coryoth (254751) | more than 7 years ago | (#17620124)

I'm not sure that's a good idea, either, since reals and floats are different things. Reals have infinite precision, whereas precision is finite for floats.

In Fortress the basic types ZZ and RR provide arbitrary preceision integers and floats. If you want a specfied precision then you need, say, ZZ32 or RR64 etc. So in fact it is the correct notation.

Yes, that's what I imagined it would be like. I also imagine actually _typing_ something that looks a lot more like regular program code, so that you still have to learn an alternative to math notation.

Yes, but it is well documented and, if you are at all familiar with mathematics, straightforward to learn (indeed, you almost don't need to learn - instinctually typing in whatever you would say works for most symbols. It is no harder to learn than TeX - easier if you already know TeX in fact.

Also, the result will look like what one would see printed in a math textbook, as you said which is (1) not what the programmer typed, and (2) horribly obfuscated to me (which is a personal thing, but applies to many people).

Sure, it applies to many people. None of them are in the target market for Fortess though. Fortress is aimed at mathematicians and scientists - the sort of people who are still using Fortran - and for them the math notation makes the whole thing much, much easier to read. It all depends on what you're used to. If you're a programmer who reads C and Java all day then that probably looks good to you. If you spend much of your time reading math papers, however, then mathematical syntax looks far more natural the the elaborate and obfuscated look of C. Congratulations, you're not the target market for the language - that doesn't mean it isn't a great idea that will be of great value to many other people.

Re:APL (0)

Anonymous Coward | more than 7 years ago | (#17619704)

the horribly obfuscated look of APL
Oh yeah? Well, suck my quote-quad, buddy!

Re:APL (1)

exp(pi*sqrt(163)) (613870) | more than 7 years ago | (#17619384)

"However, I still think this is a really bad idea."
Persisting in using an argument, despite the fact that you yourself have demolished its validity, is also a bad idea.

Cue Fortrain Jokes (5, Funny)

locokamil (850008) | more than 7 years ago | (#17619118)

"God is REAL unless declared INTEGER"

"Q: What will the scientific programming language of 2050 look like? A: No one knows, but it will be called FORTRAN."

"CS without FORTRAN and COBOL is like birthday cake without ketchup and mustard."

"Consistently separating words by spaces became a general custom about the tenth century A.D., and lasted until about 1957, when FORTRAN abandoned the practice."

"The primary purpose of the DATA statement is to give names to constants; instead of referring to pi as 3.141592653589793 at every appearance, the variable PI can be given that value with a DATA statement and used instead of the longer form of the constant. This also simplifies modifying the program, should the value of pi change."

I'd actually venture that FORTRAN has more jokes about it than C. I for one welcome our FORTRESS-joke-making overlords.

Ambituous (0)

RAMMS+EIN (578166) | more than 7 years ago | (#17619126)

So, Sun sets out to do what programming languages designed since the 1960s have tried and failed. Ambitious...

Re:Ambituous (1)

Coryoth (254751) | more than 7 years ago | (#17619182)

I would suggest it is worth the time to have a look at the Fortress spec - it actually looks like a very interesting language, and is actually a worthy fortran replacement. Of course being worthy and actually managing to overcome the inertia and actually replace fortran is another thing. Still, I would gladly use Fortress.

Re:Ambitious (1)

RAMMS+EIN (578166) | more than 7 years ago | (#17619190)

I do apologize for my mangling of the spelling of 'ambitious'. My browser went berserk and, somehow, I submitted the post while trying to correct the spelling...

C didn't fail... (1)

mangu (126918) | more than 7 years ago | (#17619804)

programming languages designed since the 1960s have tried and failed

A good substitute for FORTRAN is C. From the (very little) information one gets from the article, this Fortress will have ways for the programmer to select which loops will run serial and which will run in parallel. This could be done very easily with the current standard C, that's why #pragma exists.

I think people are rather overdoing this trend for creating new languages. I still have doubts whether it's better to use Perl or Python or Ruby or Lisp or PHP, each and every language has fans and detractors, each has advantages and disadvantages, depending on the application. Perhaps it would be wiser to let creation of new languages to one day when we may have a more objective way of doing it, when we have an analysis tool that will let one optimize a language design by choosing which parameters to maximize or minimize.

Re:C didn't fail... (1)

RAMMS+EIN (578166) | more than 7 years ago | (#17620510)

A good substitute for FORTRAN is C.''

So you say, but it has still not superseded FORTRAN. Also, correct me if I'm wrong, but I think there are still issues in C that prevent C code from being as heavily optimized as FORTRAN (pointer aliasing, perhaps?).

I think people are rather overdoing this trend for creating new languages. I still have doubts whether it's better to use Perl or Python or Ruby or Lisp or PHP, each and every language has fans and detractors, each has advantages and disadvantages, depending on the application.''

This is exactly why Lispers opposed Unix's idea of many little languages: you will end up with a plethora of different languages to learn, and still end up in situations where none do everything you need well. Instead, the argument was, you should build your domain specific languages on top of Lisp, using functions and macros, so that the resulting languages are all still Lisp. This allows you to use all the power of Lisp and all your DSLs all at the same time.

People laugh at Lisp these days, and say it is slow and has a horrible syntax, but Common Lisp is actually a very powerful language with a very simple (but also flexible and extensible) syntax. Performance has, at various points in time, paralleled that of FORTRAN or C. However, I believe this is not one of such times, despite having just read How to make Lisp go faster than C (PDF) [epita.fr] , which claims CMUCL 19c produces code as fast or even faster than GCC 4.

Another winner from Guy Steele (4, Interesting)

msuzio (3104) | more than 7 years ago | (#17619130)

For those who won't bother to read the article, Fortress was designed by Guy Steele [wikipedia.org] , which gives it a good pedigree in my book. I heard his talk at OOPSLA 2006 on the language design decisions they made for Fortress, and although my Fortran (and math) experience is too shallow to fully appreciate it, I found it fascinating nonetheless.

At the very least, Sun has given people something to think about.

Re:Another winner from Guy Steele (0)

Anonymous Coward | more than 7 years ago | (#17619246)

Sorry, but this loser [sun.com] doesn't even have a beard.

Re:Another winner from Guy Steele (0)

Anonymous Coward | more than 7 years ago | (#17619400)

Maybe he has a wife instead.

Re:Another winner from Guy Steele (2, Insightful)

Coryoth (254751) | more than 7 years ago | (#17619438)

I heard his talk at OOPSLA 2006 on the language design decisions they made for Fortress, and although my Fortran (and math) experience is too shallow to fully appreciate it, I found it fascinating nonetheless.

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:Another winner from Guy Steele (1)

plopez (54068) | more than 7 years ago | (#17619566)

Steele.... Fortress.... nice....

Re:Another winner from Guy Steele (1)

thechao (466986) | more than 7 years ago | (#17620398)

(Also saw the talk at OOPSLA) I think they should have spent more time to fix the F-bounded polymorphism problem---there are good solutions out there, other than using the CRTP as a built-in facility. I think the nutty thing is the typographic layout, I can't *possibly* type it here, but variables are not only case-sensitive, but font-sensive, e.g. /m/ (italic 'm') is different from /m (slant 'm') and _m_ (underline 'm'), bold 'm', ams 'm', etc. etc. The compiler accepts unicode, so you can have variables like the Greek rho; hell, you can even have subscripts \rho{}_{0} is a different variable from \rho etc. etc. He actually suggested in the talk using LaTeX to do the layout.

The actual language is being designed to support built-in multithread/process primitives. It's one of three gov't sponsored languages, one of the others is X10, and I can't remember the third.

Another thing kind of "unique" to Fortress is that it doesn't define primitives like 'addition' or 'subtraction'. Instead it supports register-level addressing to 'pattern transformations' and fixed length bit-arrays (and patterns thereof). The result is that there are libraries that support 'int', 'float', etc. without loss of efficiency.

Multi-core? (2, Insightful)

Nasarius (593729) | more than 7 years ago | (#17619262)

What does "designed specifically for multi-core processors" mean? Has something radically changed about SMP and multithreading since Intel and AMD decided to put two CPUs into one package? I suppose there are some cache differences, but that's about it. What is it with people who have apparently never heard of any computer hardware outside the home desktop, now excitedly babbling about "multicore" software?

Re:Multi-core? (3, Insightful)

IvyKing (732111) | more than 7 years ago | (#17619356)

Not sure if you're being sarcastic or ignorant. One of Sun's latest jewels is the 8 core Niagara and it behooves them to come up with ways of keeping all 8 cores going on a processor.

Re:Multi-core? (1)

DrDitto (962751) | more than 7 years ago | (#17619860)

Not sure if you're being sarcastic or ignorant. One of Sun's latest jewels is the 8 core Niagara and it behooves them to come up with ways of keeping all 8 cores going on a processor.

And Sun's latest 8-core jewel, the Niagara T1000, has a _single_ floating-point unit shared by all eight cores. Running scientific codes on the Niagara is not a good way with keeping all 8 cores busy!

Re:Multi-core? (1)

P Fayers (470140) | more than 7 years ago | (#17620138)

Niagara-II will have a floating-point unit for each core. Sun's Rock is expected to have 16 cores when it arrives in 2008. Intel is working on CPUs with 64+ cores, etc. etc. Sun would be somewhat stupid to embark on designing a new programming language targetted at only the chips which are available today.

Re:Multi-core? (1)

Nasarius (593729) | more than 7 years ago | (#17620004)

And it differs from 8-way multiprocessor systems how? Did you even read my post?

Re:Multi-core? (0)

Anonymous Coward | more than 7 years ago | (#17620212)

The Sun Niagra is a multi core chip with each chip running 4 or 8 threads, I can't remember which. The theory is that by switching between the multiple threads, you can keep processing data, while in a conventional processor, the processor may go idle while it is fetching code from memory. The current chip has a memory controller for each core and the multiple cores share a single floating point processor. Sun itself recognises that this chip is not going to be good for all workloads, but has offered tools to tell how well a workload would run on it. The Niagra 2 chip is supposed to increase the number of cores and have a floating point unit per core. While the Niagra chips are meant for low end workloads, Sun is supposed to introduce a higher end version early next year to replace the Sparc IV. If you are really interested, you can go to Suns we site or look at www.opensparc.com.

Steve

Re:Multi-core? (4, Informative)

Cassini2 (956052) | more than 7 years ago | (#17619618)

Multi-processor programming is becoming a real force / nightmare. Dual-core is only the beginning. At the rate AMD and Intel are moving, we will have Niagara like chips in our home PCs. Already, AMD and Intel have quad-core processors, and are talking about dual quad core (8 core) computers. The average program just can't scale well to 8 cores. Most programs, programming languages, and algorithms don't scale well with increasing the number of cores.

Fortress is proposing a language to automate that scaling. They are discussing language features to deal with multi-CPU systems, where multiple memory banks are present. AMD's multi-CPU system's (Opteron) with HyperTransport each have a separate memory banks for each processor. It makes sense to allocate the half of the array used by CPU #1 in CPU #1's memory bank, and the other half used by CPU #2 in CPU #2's memory bank. Then the threads should be split so first pair of cores on CPU #1 work in the first half of the array, and the second pair of cores on CPU #2 work on the activities related to CPU #2. Currently, all these multi-processor mapping activities happens manually, and it really sucks. It would be wonderful if programming languages supported this activity automatically.

I don't know if Fortress is the answer to the multi-core / multi-CPU problem. I hope something is. The computing world needs a solution.

Re:Multi-core? (1)

RAMMS+EIN (578166) | more than 7 years ago | (#17619776)

What does "designed specifically for multi-core processors" mean?''

I assume they really mean multiple cores, whether they are on a single CPU or not. As far as that goes, there is a lot to gain over languages in common use today, as these typically express algorithms in an imperative fashion where only one thing happens at a time.

Re:Multi-core? (1)

iluvcapra (782887) | more than 7 years ago | (#17619880)

Please read about parallelization [wikipedia.org] and how many algorithms, particularly ones that act over sets of data, can be broken into "parallel" and "serial" elements. If your language implies the two and provides syntax to richly describe these, the compiler can smartly break your program down into threads (or procs or distributed procs) and make the parallel ops magically happen at once, without the programmer dealing with threading or synchronization or any of that other junk (and getting a huge boost in performance on a distributed processors).

It's not just about multi-cores, it's about 1000 CPU clusters. In such languages, as a trivial example, you can write a one-liner that will take every integer from 1 to 1,000,000,000,000,000 and sieve out the primes, and the language can implicitly give integers 1-100,000 to one CPU, 100,001-200,000 to the next, and so on.

Re:Multi-core? (1)

P Fayers (470140) | more than 7 years ago | (#17620000)

Multicore does bring new challenges. In terms of parallel programming you might get more performance from a dual socket, dual core system if you treat it as 2 SMP machines connected by a high speed interconnect. Once you get to 8 core CPUs which each have 4 independant memory controllers which communicate over a switched interconnect in each node of a parallel cluster it gets even more complex and so someone is going to have to build the primitives into a programming language to help you deal with such situations.

Fortress is just one of a number of parallel languages which are under development.

Re:Multi-core? (1)

Nasarius (593729) | more than 7 years ago | (#17620088)

Ah, finally a relevant response. BTW, Fortran already has parallelization extensions [co-array.org] . I've used it for some scientific calculations.

My memories of Fortran (1)

UnknowingFool (672806) | more than 7 years ago | (#17619264)

[Rocking back and forth and mumbling]
Find a happy place.
Find a happy place.

I don't see anyone trying to give credit where due (4, Insightful)

zappepcs (820751) | more than 7 years ago | (#17619318)

In recent times, we've seen all kinds of credit given to companies that have nothing more than vaporware (I don't dare mention anything from Apple here or I'll get modded as troll) and yet Sun, like them or not, is giving back. Perhaps they are not giving back things that you will immediately use or notice, but they are giving back, making it open source, working to stay relevant. That last phrase was on purpose.

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.

i totally agree... (2, Informative)

andyr0ck (847274) | more than 7 years ago | (#17620522)

...all i've seen Sun do over the last few years is open more things up. Solaris used to cost us money for disks; now it's free (and there's an open source version), same for Java, now it's GPL'd. Anyone like open source chips? [sunsource.net]

don't get me wrong, i don't think the sun (not much pun intended) shines out of their collective behind. there's still some stuff that grates; service plans just to get the 'recommended' patch clusters. they are moving in the right direction, as parent said.

Intellectual Fortress Commentary (5, Informative)

namtro (22488) | more than 7 years ago | (#17619362)

Robert O'Callahan (a core Mozilla developer) had some fairly insightful comments [mozillazine.org] on Fortress a couple of days ago I personally found interesting...

dozens have tried before (1)

LM741N (258038) | more than 7 years ago | (#17619474)

Gee, how many languages now have been designed to replace FORTRAN? 10? 20? And its still due for replacement as of today!!

Principal Investigator: Guy L. Steele, Jr. (0, Redundant)

imbaczek (690596) | more than 7 years ago | (#17619634)

With this guy [wikipedia.org] as project lead, you can't fail in this domain.

Nothing like FORTRAN (1)

gregor-e (136142) | more than 7 years ago | (#17619642)

Their FAQ answers questions like "Is Fortress intended as a replacement for Java?" (ans: NO) But nowhere do they even mention FORTRAN. From the example code, it looks a whole lot more like APL to me.

From the specification, it is Ugly (5, Interesting)

XPulga (1242) | more than 7 years ago | (#17619766)

I've seen this a couple of days before and bothered to skim through the specifications carefully hidden in the depths of Sun's site. I am not pleased with what I saw. Summarizing:

It seems that the only Fortran-esque side of Fortress is that it is aimed at scientific computing and number-crunching. Other than that, the programming paradigm of Fortress is based on object orientation and programming-by-contract. If Java smelled like Smalltalk, Fortress smells like Eiffel.

Fortress has focus on three basic things:

1) programming by contract (pre-conditions and post-conditions of a method)
2) Numerical and dimensional correctness
3) Keeping the programming language as close to mathematical notation as possible.

1) means that people will write more to achieve the same thing with some guarantee of correctness. Much like Java's enforcement of exception handling, an be easily misused.

2) means that Sun bothered to include kelvin, Pascal, meter, second, Newton and every Physical unit you can think of as language keywords, that all parameters should specify what unit they're in, and that the language will do some effort to prevent errors arising from adding oranges and bananas, or precision errors from summing milligrams to some hundreds of kilograms.

3) means that Fortress will make Perl look readable. Good part of the language specification deals on how the editor should render the source code onscreen. The logical AND operator is the upward-pointing wedge symbol of math. The logical OR operator is the downward-poiting wedge symbol. The Integer type is that special-font Z, and a real is that special-font R. The specification deals on how to represent these in an ASCII file, using a meta-language similar to TeX (but incompatible with).

Programming Fortress on anything other than Sun's own IDE will most likely be unfeasible. Think of every math operator you've seen. If you have experience with TeX/LaTeX, think of those 4 pages from symbols.dvi with all symbols you could use. Those are the Fortress operators. Sun has finally come with something mor unreadable and with more operators than Perl. And the operators aren't even ASCII, they're untypeable. The bitwise AND and OR operators are a weird thing I had never seen before (after 5 years of engineering, and 5 years as graduate student in CompSci).

That said, Fortress may even succeed as a niche programming language. But I still have two concerns left:

How will non-scientific code look on it ? Surely Fortress programs will want to open windows, and dialog boxes, access files and the network. The math-oriented syntax has all it takes to make UI programming uglier than C+Xlib.

Sun claims that Fortress is aimed at High Performance Computing. Sun released an alpha interpreter of Fortress, which is written in Java. What kind of sick language designer writes an interpreter in Java to demonstrate something related to High Performance computing ?

Re:From the specification, it is Ugly (5, Insightful)

Coryoth (254751) | more than 7 years ago | (#17620768)

It seems that the only Fortran-esque side of Fortress is that it is aimed at scientific computing and number-crunching.

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

Other than that, the programming paradigm of Fortress is based on object orientation and programming-by-contract. If Java smelled like Smalltalk, Fortress smells like Eiffel.

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.

means that people will write more to achieve the same thing with some guarantee of correctness.

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.

means that Sun bothered to include kelvin, Pascal, meter, second, Newton and every Physical unit you can think of as language keywords, that all parameters should specify what unit they're in, and that the language will do some effort to prevent errors arising from adding oranges and bananas, or precision errors from summing milligrams to some hundreds of kilograms.

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.

means that Fortress will make Perl look readable. Good part of the language specification deals on how the editor should render the source code onscreen. The logical AND operator is the upward-pointing wedge symbol of math. The logical OR operator is the downward-poiting wedge symbol. The Integer type is that special-font Z, and a real is that special-font R. The specification deals on how to represent these in an ASCII file, using a meta-language similar to TeX (but incompatible with).

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 entering them is done in a way that is easy to learn because you already know the names of most of the symbols anyway.

Programming Fortress on anything other than Sun's own IDE will most likely be unfeasible. Think of every math operator you've seen. If you have experience with TeX/LaTeX, think of those 4 pages from symbols.dvi with all symbols you could use.

Indeed, it's quite enticing to a mathematician. Of course there are a lot of symbols you could use, but most of them won't be required. The standard ones should be straightforward to remember for anyone that knows TeX/LaTeX. To be honest I could probably cover about 2 of those 4 pages right now, and that easily covers all the symbols in common use. Again, just because you're not in the target audience doesn't mean the language sucks - it just sucks for you.

How will non-scientific code look on it ? Surely Fortress programs will want to open windows, and dialog boxes, access files and the network. The math-oriented syntax has all it takes to make UI programming uglier than C+Xlib.

Well given that it implements standard OO syntax as well as all the lovely mathematical sugar, I expect it will look not all that disimilar to file access, GUI, and network code in other languages like Java and Eiffel. I'm not sure I see the problem - you don't have to write everything with fancy mathematical operators, and it is easy enough to have standard libraries for this functionality that look essentially the same as Java.

Sun claims that Fortress is aimed at High Performance Computing. Sun released an alpha interpreter of Fortress, which is written in Java. What kind of sick language designer writes an interpreter in Java to demonstrate something related to High Performance computing?

Well given that a large chunk of the HPC aspect is in parallelism, and that Fortess is designed to do as much of that as transparently and easily as possible - again, I'm not sure I see the problem. Sure it's not going to be as fast as it could in theory be, but these days Java isn't that much slower. Beisdes, the important thing in the parallelism and being easily scalable to multicore processors like Suns Niagara. You can test that just as well in Java as any other language.

Re:From the specification, it is Ugly (1)

Bromskloss (750445) | more than 7 years ago | (#17620814)

2) means that Sun bothered to include kelvin, Pascal, meter, second, Newton and every Physical unit you can think of as language keywords, that all parameters should specify what unit they're in, and that the language will do some effort to prevent errors arising from adding oranges and bananas, or precision errors from summing milligrams to some hundreds of kilograms.
Cool! Should you or I tell NASA?

Re:From the specification, it is Ugly (1, Interesting)

Anonymous Coward | more than 7 years ago | (#17620864)

Damn, I was all ready to completely agree with you (bobblehead style), and then you had to go and stick your food in your mouth at the very end:

What kind of sick language designer writes an interpreter in Java to demonstrate something related to High Performance computing ?
Ok. Step away from the crack pipe. I'm no fan of Java either, but let's not bash this just because he used Java, Mmmmmkay? Prototypes are just that -- prototypes. Also, keep in mind that it's possible to write a compiler in any language (n.b. whether you can actually execute the resulting binary on the same platform is an another issue). And also keep in mind that Java server is no slouch when it comes to performance.

Good News, but work is still needed (3, Informative)

deadline (14171) | more than 7 years ago | (#17619794)

This announcement is great news because the parallel programming problem is quite difficult and is becoming more important as multi-core systems emerge. One important distinction that is often not made, is the difference between concurrency and parallel execution. (although the article does touch on it)

Basically, determining whether a program or algorithm is concurrent (parts can computed independently) is possible but can be difficult in some cases. Many people think that is the essence of parallel computing. It is not.

Once you have the concurrent parts, the questions becomes "whether they should be executed in parallel". The answer depends upon the ratio of computation to communication (parallel overhead). All parallel computers (and clusters) have different ratios and therefore, something that runs well in parallel on one machine, may run poorly on another.

Having a language where concurrency can be expressed and controlled, allows researchers to investigate the second issue (parallel scheduling).

If you want to read more about this kind of thing (and some other parallel programing ideas) take a look at some of the Cluster Programming [clustermonkey.net] articles on ClusterMonkey.

as opposed to pgfortran? (2, Insightful)

Anonymous Admin (304403) | more than 7 years ago | (#17619916)

pgfortran produces highly optimized parallel code for running on multi processor machines and clusters. It has for years. CF90 produces highly optimized code for running on 1024 processor machines, and has for years. Neither one is an interpreter. If you want fast parallel math code, get a good compiler. There are plenty of them available, including many free ones.

Re:as opposed to pgfortran? (0)

Anonymous Coward | more than 7 years ago | (#17620484)

Throughout the 6 years in which I have been doing geophysical programming, I have been looking forward to a tool that uses UTF instead of ASCII to make equations more readable. Our programs consist mostly of equations, and all the stuff is highly parallelizable. I can't wait for a compiler (and a suitable text editor!) to try this out. It will probably take a decade for this to trickle into mainstream scientific programming.

Welcome FORTRESS (1)

echusarcana (832151) | more than 7 years ago | (#17620178)

FORTRAN is still commonly used for scientific applications such as aircraft and nuclear simulation. The simple reason is having a COMPLEX data type built into the language: it is essential for doing physics. Shared memory also works much more nicely with COMMON blocks rather than as C data structures (remember that a physicist or engineer wants to worry about the physics, not the coding).

We have a couple million lines of physics implemented in FORTRAN. It is an exaggeration to actually describe this as "software" in the modern sense - it is physics equations. FORTRAN has never been a well standardized language (e.g. F77, vs. many vendor extensions) and legacy techniques like "byte-parallel" coding were once commonly used but cause platform dependencies (I'm told by friends in the database realm that COBOL has analogous problems). gcc/f77 support for FORTRAN is also fading and gcc/f77 has always compiled FORTRAN at a snail's pace.

I would welcome a new option if the porting is easy. Because of the computer horsepower today, even for real-time usage, an interpreted language would work fine if callable from a C wrapper.

INCONCEIVABLE (1, Interesting)

OpenSourced (323149) | more than 7 years ago | (#17620378)

...and is published under the BSD license.

-...You keep using that license. I do not think it means what you think it means [slashdot.org] .

Re:INCONCEIVABLE (1)

Aladrin (926209) | more than 7 years ago | (#17620718)

I don't have any mod points, so I'm going to express my regard in text.

Excellent reference!

Make it LaTeX compatible! (0)

inverselimit (900794) | more than 7 years ago | (#17620492)

What is it with people reinventing the wheel when it comes to entering mathematical notation? Every serious mathematician, and many in CS, Physics, etc. (can't say for sure because they aren't my fields) uses Latex to write papers and communicate math in ascii. As far as I know, exactly noone uses unicode. If they are interested in adoption, why on earth not use Latex notation instead of untypeable unicode or their ascii version of it? Latex is the standard. Unicode will never be flexible enough to be as dominant. Use a subset of Latex, or any goal of making it easier for math folk to write these programs is lost.

Re:Make it LaTeX compatible! (1)

Bromskloss (750445) | more than 7 years ago | (#17620944)

LaTeX is the one that should change, imho.

You will never replace Fortran (1)

vm370guy (810619) | more than 7 years ago | (#17620552)

Never. To say as such is heresy, HERESY!!! Besides this 'replacement' (I use the term laughably) bears as much in common with Fortran as PCs do with real computers and Windows does with 'operating system'. Computers should weigh at least six tons, have massive water-cooling systems and be programmed using dumb terminals with a CLI interface.

mritunjai (518932) | more than 7 years ago | (#17620938)

Folks,

This language is unfortunately advertised as "FORTRAN replacement" though probably the only thing it shares with FORTRAN is that it is targetted at scientific computing. But that's about it!

Secondly, there is a different between language specification and implementation! The "interpreter" is just proof of concept and a fast way of giving means to people to play with it so that you can ot just try to express your computation in it, but also see it running in flesh! Though, it is primarily of interest to language designers to find out implementation quirks and iron them out as the language design evolves. A compiler is usually the final outcome, but is not the goal. The goal of language design is to address the problems in the domain it is targetted to, effectively.

I have been following the developments in Fortress community for a while and it is a very peculiar one in its own regard. Guy Steele has bettered himself again and has set some of the firsts-

1. Integration with typography system. The programs are not just typed, but typed well. You can typeset your equations. The primary symbol set is unicode (with ASCII symbols for lagacy compatibility).

2. Full support for closures, mixins etc with multi-paradigm programming support.

3. The language specification implies parallelism by default! loops are parallel, unless specified serial.

4. Units are included in the language type system. So the compiler can not just check whether you're using the right storage type (int, real etc), but also whether the calculation you're coding actually makes sense!

and many more. It is a great read for anyone remotely interested in computing, languages and software enginnering and development.

Thanks
Slashdot Account

Need an Account?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

• b
• i
• p
• br
• a
• ol
• ul
• li
• dl
• dt
• dd
• em
• strong
• tt
• blockquote
• div
• quote
• ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>