Sun Releases Fortran Replacement as OSS

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

Comments

Doesn't make a difference.

[gardyloo]

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.

[Harmonious Botch]

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

Re:Doesn't make a difference.

[celardore]

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.

[soliptic]

Offtopic: Brilliant sig :)

Re:Doesn't make a difference.

[Mister Whirly]

"And on the 7th day God created Cobol, when he should have been resting..."

Re:Doesn't make a difference.

[geekoid]

If it wasn't for the fact that COBOL rocks at what it was designed to do, you might have been funny.

Re:Doesn't make a difference.

[Mister Whirly]

I agree. But it sucks to program in, and sucks even worse to debug. Any modern database blows it away. I still say I retain my funny, all points considered.

Wellllllll...

[SatanicPuppy]

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

[metamatic]

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

[drgonzo59]

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

[geoff lane]

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

[Lawrence_Bird]

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

Re:Wellllllll...

[MikkoApo]

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

[metamatic]

Yes, I was talking about array/Array/ArrayList/Vector, I hadn't even considered LinkedList. I'd be more inclined to believe it was cleverness rather than lack of foresight if they had compatible interfaces and the names actually reflected their properties (e.g. ThreadSafeArray or SynchronizedArray). And then there's generics...

Plenty of languages--including FORTRAN, which is the language this new one is intending to replace--make do with just the one array implementation. If you're going to be doing anything time-intensive you're almost certainly going to be using something like BLAS instead of the language-provided array objects anyway.

Re:Wellllllll...

[twiddlingbits]

APL? Gag..I remember that... IIRC, Algol60 was the first block structured language? Been about 28 yrs since Programming Languages class...

Re:Wellllllll...

[kaffiene]

WTF?

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

[Anonymous Coward]

A billion years ago in college I knew a student who wrote a primitive text editor in APL, on a Data General MV10000.

Re:Wellllllll...

[try_anything]

Neither is Java a C++-esque language, but that's what the Sun marketeers fooled a lot of people into thinking. You can't establish a new language without getting enough people to buy in and commit to the language, and you can't get enough people to buy in and commit to the language without making the conservative crowd think it's a just a cleaner, spiffier version of something they already know.

Sun did a good job of simultaneously pitching Java to forward thinkers and to conservatives. If they're doing the same thing with Fortress, then I predict that some of the best and ultimately most important features of Fortress are being downplayed to avoid spooking the uber-conservative Fortran crowd.

Re:Wellllllll...

[MikkoApo]

ArrayList, LinkedList and Vector implement the List interface. Collections.synchronizedList(List list) returns a synchronized (thread-safe) list backed by the specified list, so there's also a generic way of "making" synchronized lists. The same method (Collections.synchronized*) is also implemented for maps & sets.

Imo the array primitive type could have been an object instead of the current primitive type implementation but I don't see what's wrong with using the ArrayList, since it's pretty close to an Array object anyway. You just don't get to use array's syntax which isn't that big of a thing with modern IDEs.

With Java's lists, sets and maps you aren't using just "language-provided array objects", the class names reflect the way the objects function. I haven't used BLAS (or FORTRAN) but according to google it's "A high quality "building block" routines for performing basic vector and matrix operations." where at least the vector part sounds awfully close to ArrayList and its kind ;)

Re:Wellllllll...

[Anonymous Brave Guy]

But the language is much more complex than anything most people will be familiar with.

You mean it makes things like C++ and Perl look simple? WE'RE ALL DOOOOOMED!

Re:Wellllllll...

[metamatic]

BLAS is a library of common mathematical operations needed in sciences, 3D geometry and the like. It's designed so that the implementation can make use of vector hardware. For example, on the Mac, you can call Apple's CBLAS library and if the Mac has no vector processing (G3) you get a C implementation, otherwise you get the operation performed by the native hardware. Almost anyone doing serious number crunching in FORTRAN will be using BLAS or something similar, like the NAG libraries.

Re:Wellllllll...

[metamatic]

All the other structures I mentioned are part of the core Java platform, J2SE.

If the additional complexity was part of special purpose libraries for those who need all those choices, I wouldn't have an issue. Somewhere along the way the idea of Java being simple was lost.

Re:Wellllllll...

[kaffiene]

All of those structures you mentioned are part of the Collections API, which is clearly the equivallent of the STL having exactly the same purpose. Noone says the STL is a bad idea (badly implemented, maybe) and Collections is likewise not a bad idea.

Christ, I can't believe I'm having to post on /. to say that having the right data structure for the job is a good idea- I thought that was fairly fundamental. What are they teaching you lot these days?

Re:Wellllllll...

[metamatic]

I said that having an extensive library of specialist data structures is a good idea. What's a bad idea is not naming them clearly, and stuffing them all in the core API instead of in separate specialist libraries.

It's much better to have performance-oriented special purpose stuff in separate libraries, like BLAS or NAG. Keep the complexity of core Java down, make it more manageable for newcomers, reduce platform bloat, and so on. There's a reason why C has CBLAS, GMP and so on, rather than stuffing it all in libc.

If Sun had kept the core libraries down to size they might not have had to go rip it all out again to define J2ME. And it's not like they've done a good job of making J2SE include everything you need, either, stuffing in specialist data structures and leaving it to projects like Log4j and JUnit to implement things that would be much more useful to most people.

Re:Wellllllll...

[drgonzo59]

You are correct, from a marketing perspective it makes total sense.

What's it look like?

[The MAZZTer]

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!

Re:What's it look like?

[gardyloo]

program Hello_world

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

load fortran77
      print *,"Hello World"

fortress.obfuscate

end program Hello_world

Re:What's it look like?

[nuzak]

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

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

Re:What's it look like?

[Anonymous Coward]

You forgot to format it in the proper columns.

Re:What's it look like?

[rrohbeck]

From The Fortress Language Specification, version 1.0alpha:

component HelloWorld
export Executable
run(args) = print "Hello, world!"
end

Re:What's it look like?

[Anonymous Brave Guy]

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?

[Goaway]

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?

[Coryoth]

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?

[glwtta]

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!

Re:What's it look like?

[aztektum]

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?

[Livius]

My God! It's full of APL!

Re:What's it look like?

[renoX]

>I'm sure productivity will skyrocket with this invention.

Note that I would say that more time is spent reading code than writing code, so if those funky operators helps reading the code, it may truly increase productivity, even though a little time is lost writing code.

Re:What's it look like?

[ThePhilips]

That's actually not funny.

Prof from my University after moving to modern DTP facilities had found that several formulas in his book had mistyped index: i v. j. Fine print was barely readable and few people noticed. 21" TFT display, Acrobat Reader, zoom 400% - ZOMG!!! - all editions have the same copy-pasted mistake.

And not that you can proof that closely everything you type. Convert that to source code - and you have bug already. In fine print.

IOW, think twice before bringing to programming the most popular legal advice - "read fine print carefully".

Re:What's it look like?

[Anonymous Brave Guy]

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?

That would be a fair comment if this were a new issue, but it's not. I'm not sure I'd use the word "resistance", but the scepticism, at least in my case and to this particular subject, is born of experience. Manipulating equations in their natural form is cumbersome on a computer, because they are hard to type and navigate on a keyboard and hard to view on low-resolution screens.

Someone else already pointed out that you can overcome the difficulties in typing the symbols by providing "text-only" versions that are keyboard friendly. This is, of course, what we already do in most programming languages anyway.

A related issue is navigation, in the sense of moving a cursor around the source code to edit it. What does it mean to press the up or right arrow in the middle of an equation? Is it simple to navigate around them? How do I copy part of an equation and paste it elsewhere when I'm refactoring my code? Again, we need only look at things like Equation Editor to see what a nightmare WYSIWYG interfaces to equation editing can be. Everything I think of as successful in this area -- from Wordperfect's equation editor, through typesetting tools based on TeX, to specialist maths software like Matlab -- uses an essentially line-based input format. If Fortress works on the same principle, that's fine, but again we're back to the display being nothing but a pretty-printer for the kind of code we write in other languages today.

That leaves the display issue. As anyone who's tried reading mathematical papers on-line can tell you, the sort of typesetting that works neatly for high-resolution printers on paper needs zooming in a lot for most people to read clearly on-screen. Even then, remember that Knuth designed his own set of typefaces for use with TeX, and one of his concerns was legibility when printed at small sizes, for example when used in super- or subscripts. Most people, even mathematicians, don't appreciate quite how smart he was in recognising this, but they would surely notice if papers suddenly started appearing in Times and using Times Italic for the maths instead.

Perhaps I would be less sceptical on this point if there were widely available fonts designed with similar care for rendering maths on-screen, but as yet, it seems most efforts are either based on Knuth's Computer Modern (which wasn't designed for that medium, and sometimes it shows) or some nasty, amateurish effort that isn't worth the trouble (as any sample paper that was written using Word's Equation Editor will probably demonstrate pretty quickly). I do notice that Micorosft's new font set contains Cambria Math, which I haven't looked at but may be a step in the right direction.

There will be interesting questions connected with debugging math-style code as well, but perhaps the Fortress guys have interesting answers to match. I don't know, so I offer no opinion on this one. As far as the typing and displaying issues go, though, please understand that this is neither a knee-jerk reaction nor instinctive resistance to change; rather, it is the considered opinion of someone with an extensive background in both mathematics and programming who has seen similar things before, and remains to be convinced about why things will be different this time.

Re:What's it look like?

[TheRaven64]

And most keyboards will pitifully fail to type, in any straightforward and reliable way. Under OS X, the alt key is used as a modifier providing a range of alternative symbols depending on your configured keymap. I use this quite a lot to type trademark and ellipsis symbols, greek letters, etc. Most terminals these days can display unicode and handle UTF-8, and so can Vim, so it's hardly a huge limitation.

Re:What's it look like?

[DragonWriter]

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

Fortress is not, from the description, a "programming language for the masses", but rather one designed for a specialized scientific user-base.

So, it requires either a special keyboard or special input method to use effectively. So what?

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

The monitor is not the issue, the font is. OTOH, specialized fonts that make the distinctions necessary for unambiguously representing complex mathematical notation are hardly unknown, particularly among the target user base of Fortress.

Programming should be based on mathematics, not written in it

That's a nice theory, and maybe that's the best way for some programming. Maybe its not the best way for others.

Seriously, if TeX is the least friendly programming environment I have ever encountered in serious use, and the average programming font has trouble distinguishing (,

So long as you are doing it with TeX as your programming environment, and using the average programming font, your logic here is sound.

OTOH, I expect that Fortress environments will not be TeX environments (at least not typical ones), nor will they prefer the use of "the average programming font", whatever that is.

Re:What's it look like?

[Anonymous Brave Guy]

So, it requires either a special keyboard or special input method to use effectively. So what?

So that's a major inconvenience, which will inevitably impede its adoption.

The monitor is not the issue, the font is.

How can the monitor possibly not be an issue? Even with all the latest "high resolution" screens and sub-pixel anti-aliasing in font rendering, ultimately the screens on desktops today are around 100dpi, while the sorts of printers where things like TeX output look nice are more like 600dpi as a minimum. Much higher resolution screens are in the research labs, but it will be years before they're on developer desktops as a matter of routine.

OTOH, specialized fonts that make the distinctions necessary for unambiguously representing complex mathematical notation are hardly unknown, particularly among the target user base of Fortress.

Really? Can you name any typeface that is screen-optimised, designed with maths in mind, and widely available?

Re:What's it look like?

[DragonWriter]

How can the monitor possibly not be an issue? Even with all the latest "high resolution" screens and sub-pixel anti-aliasing in font rendering, ultimately the screens on desktops today are around 100dpi, while the sorts of printers where things like TeX output look nice are more like 600dpi as a minimum.

Because at screen resolutions, many fonts designed for math use make the relevant symbols quite clearly distinguishable. Sure, they "look nice" at higher resolutions. That's not the issue.

Re:What's it look like?

[Anonymous Brave Guy]

Because at screen resolutions, many fonts designed for math use make the relevant symbols quite clearly distinguishable.

And which fonts would those be? It's taken me years just to find a monospace font for code that I'm really happy with. I've never seen a really good font for rendering serious maths on-screen.

Read the FAQ

[symbolset]

The FAQ gives this pdf example

This one looks like a winner.

Re:Read the FAQ

[Yold]

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?

Re:Read the FAQ

[Daniel Dvorkin]

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

Re:Read the FAQ

[msuzio]

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

Re:Read the FAQ

[LWATCDR]

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

Re:Read the FAQ

[Coryoth]

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.

Re:Read the FAQ

[mhore]

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.

Re:Read the FAQ

[Coryoth]

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

Re:Read the FAQ

[glwtta]

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.

Re:Read the FAQ

[Coryoth]

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:Read the FAQ

[owlstead]

Hopefully with some kind of wysiwyg kind of IDE, because the main reasons of the mathematical notation of source code is for the programmers themselves. If they are staring at tagged ASCII or Unicode, it doesn't make much sense. Allthough checking the correct working of the code would be interesting.

Re:Read the FAQ

[Anonymous Coward]

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

Uh ? This is exactly what Mathematica have been doing since middle of the 90's...

Re:Read the FAQ

[zsau]

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.

Nonsense. My keyboard at home can type in Latin (including accented and non-standard letters), Cyrillic and IPA (phonetic) symbols and a vast array of real punctuation. It doesn't type many more mathematical symbols than yours does (or, probably it does, but I've never wanted to type the union symbol so I've never tried). And everything is typed in the obvious way. I can type an esh or a theta as quickly as a capital s or t on IM to linguist friends, or modifying Wikipedia articles, or writing Uni assignments/notes to myself.

People who have special needs should have special keyboard layouts to accomodate them. It's not like we don't have the disk space to include a few dozen augmented layouts so that mathematicians can type maths on linguists' computers if they need to.

I think getting programming languages away from ASCII and into formatted Unicode is an exellent idea, even though I'm not a mathematician so I'm not really in Fortress's target market --- but even tho I'm a programmer, I definitely think mathematical notation is a lot easier and more convenient to read that C/Java style syntax.

My only fear is that wasn't LISP originally meant to have a fancy formatted view as well (M-expressions, I think?), and the many brackets and S-expressions were only meant for the computer?

As for the rest of the language ... I'll have to skim the spec later :)

Re:Read the FAQ

[ThePhilips]

You can even expect automatic completion of symbols if you want.

In my experience, people who need visual help like that are normally poor programmers.

I would also expect a simple view toggle to let you see and edit the raw ASCII if that's what floats your boat.

Couple of N-week sessions looking for obscure bug hiding in syntax (or math fine print: i v. j) would make you love ASCII - once and forever. (*) If you have never experienced that - that means you never really coded anything seriously. No offense is meant.

I'm coding for a decade and I already lost count of number of such sessions. Not funny to find that release dead-line was pushed by mistyped semicolon. Dumber syntax - better. Because dumb syntax is less error prone. (Beaten example of C++ template syntax is omitted. I wish GCC had as much warnings as Perl has for suspicious syntax constructs.)

(*) That's actually why native-language translations of Pascal/Cobol/Lisp/etc all failed in past and never were reborn again.

Re:Read the FAQ

[TheRaven64]

Smalltalk does this to a very limited degree. Return statements in Smalltalk are '^value' and most Smalltalk implementations will turn the caret in to an up-arrow.

Re:Read the FAQ

[Anonymous Brave Guy]

I think getting programming languages away from ASCII and into formatted Unicode is an exellent idea, even though I'm not a mathematician so I'm not really in Fortress's target market --- but even tho I'm a programmer, I definitely think mathematical notation is a lot easier and more convenient to read that C/Java style syntax.

Out of curiosity, how many different types of bracket pair do you think are defined in Unicode?

Re:Read the FAQ

[zsau]

I don't have a clue, but certainly more than I'm likely to use... I'm also not entirely sure why you're asking.

Re:Read the FAQ

[Anonymous Brave Guy]

I'm asking because on a low-resolution computer screen, probably using anti-aliasing these days too, the typical angle brackets used for certain products look a lot like less-than and greater-than signs, all the double-bar and double-square bracket symbols look awfully like their single-barred equivalents, etc. One of my major concerns about displaying code as typeset mathematics on-screen is that ambiguity is almost inevitable with the state of (a) display technology, (b) computer typesetting, and (c) the mathematical typefaces available today. If the legibility issue isn't resolved, and decisively so, we could see the old "1 vs l vs | vs I", "o vs O vs 0", "5 vs s vs S", and so on, all over again and a zillion times worse. Brackets were just the first example that came to mind; you could just as well pick on greek letters, or binary mathematical operators, or indeed several other families of symbols that can be represented as Unicode characters internally but are hard to distinguish on-screen.

Re:Read the FAQ

[DragonWriter]

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

I suspect that, as the characters are Unicode as noted in the same FAQ entry as the syntax example PDF, more traditional editing environments will work, though special keyboards or at least keymappings may become a necessity for using it. Given, though, the orientation of the language, that's perhaps a sane approach. Learning how to do the entry for it may be less of a barrier than learning an entirely new vocabularly and its mapping to standard mathematical expressions.

Re:Read the FAQ

[zsau]

In practice, are these various brackets going to be contrasted? Is a program that uses two different brackets that look almost the same likely to be written? I imagine also that people are able to use a larger font when it's necessary (but before then, I would probably stop using hard-to-contrast letters).

I'm certainly not saying that we should be using them when it's hard to contrast, just when it provides a benefit. The ability to use Unicode characters is not the obligation to use ones you can't distinguish...

(FWIW, I've never found greek letters particularly difficult to contrast from Roman (aside from the identical caps --- but who'd use them?), even when set in a fixed-width low res font. Probably the use of Greek characters in Roman scholarly work for centuries has helped them to keep apart.)

This is fake...

[Anonymous Coward]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

Re:This is fake...

[owlstead]

Getting code quickly developed and creating components out of used code is as much important with high end computing as with other disciplines. What good is a 128 node supercomputer if it stands there waiting for someone to implement the code? And as there are Java to native compilers out there, there will be native compilers for Fortress as well. Even if there aren't, the JVM (which is what the current version runs on) is pretty fast. It's faster than C++ in many cases (e.g., when C++ programmers start to use smart pointers), and much more reliable, with good multi-threading support build in.

Anyway, seeing that this is intended to run on big hardware, I don't see how a 'slashvertisement' would do it any good. There won't be many /.ers with big iron in their computer rooms, dorms or garages, and those who do would undoubtedly already heard of this development.

Re:This is fake...

[tjr]

I first read about Fortress, oh, about a year ago. This is the version 0.1 release, coming out of Sun's research lab. Frankly, I'm surprised that they are releasing as much as they are so soon! I suspect that a good open source compiler will come along eventually.

Re:This is fake...

[adrianmonk]

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

Read the summary. It's an alpha version of the language. Beta software means the design is finished and the feature set will not change, but the implementation is not finished. Alpha software means the design is still changing.

Why would any sane person or organization produce an optimising compiler for a language whose definition is still changing? That makes about as much sense as sending prototypes of some new car you're designing off to the government agencies to have them crash tested. You're going to have to redo the process again later when the design is finalized, so there is really no point in doing it now.

APL

[RAMMS EIN]

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

[Coryoth]

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) to get the idea.

Re:APL

[exp(pi*sqrt(163))]

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

Re:APL

[RAMMS EIN]

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

[Anonymous Coward]

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

Re:APL

[Coryoth]

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

[rbanffy]

Noooo!

APL is my textbook example of a write-only language.

I couldn't figure out in the afternoon what the program I wrote in the morning did (actually, the problem was "how it did it").

There must be a better way.

Re:APL

[oohshiny]

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.

All the mathematicians and scientists I know use C and C++ when they can. The notion that there is some big C/C++-phobic subculture of mathematicians and scientists out there is a myth. And, no, adding math notation to programs doesn't make them easier to read, it just adds a whole, unnecessary layer of complexity to deal with.

The things that matter to me in a numerical programming language are simplicity, safety, performance, multidimensional arrays, efficient tuples, and easy hookup with existing C and Fortran code. Any extra language gimmicks are a net minus.

Re:APL

[mwvdlee]

If syntactic sugar was all they were after, they should have released a "mathematical-notation-in-unicode to function" preprocessor with a matching library for whatever language they wanted.
Compiler-compilers do this kind of stuff all the time, so it wouldn't exactly be uncharted territory.

C/C++ has third pary Fortran-speed math libraries and isn't unknown territory for this sort of preprocessing.

But I'm sure Fortran itself would be suitable too as it already has the library built in.

If they really wanted to do it on the Java platform, that would have been just as easy. Java already comes with a unicode preprocessor standard, so what would be the problem with a more flexible one?

Re:APL

[Count Fenring]

It is no harder to learn than TeX - easier if you already know TeX in fact.

This is kind of like saying "It's no more painful than torture," you realize.

Not to say that TeX has an obscure syntax... but TeX has an obscure syntax.

Re:APL

[Anonymous Coward]

I'm a mathematician and I don't know a single mathematician who likes C/C++. Most use matlab or mathematica (or grad students) for their coding. A few use C, but do so reluctantly. So I'd say the anti-C sentiment among mathematicians is very much true

Cue Fortrain Jokes

[locokamil]

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

Re:Cue Fortrain Jokes

[jonadab]

> I'd actually venture that FORTRAN has more jokes about it than C.

The main reason for this is that Fortran is actually a pretty good langauge. Sure, it has some foibles we can make fun of, but they are minor enough to be funny. The problems with C are not funny, because they are painful to talk about. Cracking a joke about malloc/free is like making fun of Crohn's Disease: nobody laughs.

Ambituous

[RAMMS EIN]

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

Re:Ambituous

[Coryoth]

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:Ambituous

[DragonWriter]

When DARPA is handing out grant money, people tend to make an effort, even where others have failed in the past. That being said, its somewhat interesting that of the languages developed for this DARPA program, the IBM entry (X10) extends Java.

Another winner from Guy Steele

[msuzio]

For those who won't bother to read the article, Fortress was designed by Guy Steele, 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

[Anonymous Coward]

Sorry, but this loser doesn't even have a beard.

Re:Another winner from Guy Steele

[Anonymous Coward]

Maybe he has a wife instead.

Re:Another winner from Guy Steele

[Coryoth]

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) (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

[plopez]

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

Re:Another winner from Guy Steele

[thechao]

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

Re:Another winner from Guy Steele

[belmolis]

Right. And following another tradition, the various versions of Fortress will be called: Graphite, Gypsum, Apatite, Quartz, and Diamond or something like that.

Re:Another winner from Guy Steele

[sinserve]

Another clean-shaved nerd is John Ousterhout. He does look normal now, but at some point he was very GQ looking; very stylish annoyingly business-like.

Fortran has some coolness

[EmbeddedJanitor]

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

[mhore]

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

[Anonymous Coward]

How are you going with threads? NOT AT ALL!

Re:Fortran has some coolness

[Stephen Williams]

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

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

-Stephen

Re:Fortran has some coolness

[mhore]

How do I handle threads? I use OpenMP.

Mike.

Re:Fortran has some coolness

[PhunkySchtuff]

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

[cp.tar]

Maybe... an OS?

And it would still be easier to debug than Windows.

Re:Fortran has some coolness

[Just Some Guy]

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

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

Re:Fortran has some coolness

[mhore]

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.

Re:Fortran has some coolness

[repvik]

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

Re:Fortran has some coolness

[morgan_greywolf]

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

[Chris Mattern]

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

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

Chris Mattern

Re:Fortran has some coolness

[infofc]

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

[gardyloo]

Especially if you use something like C++ you know perfectly well how the resulting code will behave.

    I am not a programmer. I learned everything I know about programming from jokes going around the internet, like the "How to shoot yourself in the foot with different programming languages" one. The entry in that for C++ reads something like
 

C++
        You accidently create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical assistance is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying "That's me, over there." Something doesn't quite agree with your post, though I'll be damned if I can tell what it is.

Re:Fortran has some coolness

[amuzulo]

How about a wiki engine in four lines?

#!/usr/bin/perl
use CGI':all';path_info=~/\w+/;$_=`grep -l $& *`.h1($&).escapeHTML$t=param(t)
||`dd<$&`;open F,">$&";print F$t;s/htt\S+|([A-Z]\w+){2,}/a{href,$&},$&/eg;
pri nt header,pre"$_<form>",submit,textarea t,$t,9,70

Source: http://c2.com/cgi/wiki?SigWik

Re:Fortran has some coolness

[Anonymous Coward]

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

I didn't took the time to code the banner (i didn't see that requirement at first sight), but this is a calendar with 47 lines of C (and it can be much much smaller if you want...). It took me 30 minutes to write.

Do you want me to add the banner code?

#include <stdio.h>

int j(int m, int y) {
    int a = (13-m)/12;
    y = y + 4800 - a;
    m = m + 12*a - 2;
    return (153*m+2)/5 + 365*y + y/4 - y/100 + y/400 - 32045;
}

int fd( int m, int y ) { return (j(m,y)+2)%7; }

int ld(int m, int y) { return j(m+1,y)-j(m,y); }

int cd(int m, int w, int d, int y) {
    int c = d+w*7-fd(m,y)+1;
    if (c<1) c = -1;
    if (c>ld(m,y)) c = -1;
    return c;
}

static char *m_name[12] = { " January ", "February ", "  March  ", "  April  ", "   May   ", "  June   ", "  July   ", " August  ", "September", " October ", "November ", "December" };

main( int argc, char **argv )
{
    int y = argc==2?atoi(argv[1]):2007;
    int t,m,w,d;

    printf( "\n%31s%d\n\n", "", y );
    for (t=0;t!=4;t++) {
        for (m=0;m!=3;m++) printf( "%15s        ", m_name[t*3+m] );
        printf( "\n" );
        for (m=0;m!=3;m++) printf( " S  M  T  W  T  F  S   " );
        printf( "\n" );
        for (w=0;w!=6;w++) {
            for (m=0;m!=3;m++) {
                for (d=0;d!=7;d++) {
                    int c = cd( m+t*3, w, d, y);
                    printf( (c==-1)?"   ":"%2d ", c );
                }
                printf( "  " );
            }
            printf( "\n" );
        }
        printf( "\n" );
    }
    return 0;
}

Re:Fortran has some coolness

[ananamouse]

>> OOP belongs in business... not in Molecular Dynamics. >Yes, because in physics, nothing is like anything else. (rolls eyes) First, let us assume a uniform, spherical keyboard...

Re:Fortran has some coolness

[bloobloo]

OOP was originally developed for dynamic modelling of chemical plants, a computationally intense field. Even 6 years ago I was working on models that simulate a full scale plant accurately that operated at real time speed. This was done in Java, obviously using objects. Obviously this is only a subset of scientific calculations, but OOP was the logical approach to use.

Re:Fortran has some coolness

[mollymoo]

j()
fd()
ld()
cd()

If you ever get a job please tell me where, so I can avoid ever having to decipher what the shit you write is supposed to be doing. Thanks.

Re:Fortran has some coolness

[Anonymous Coward]

I'm glad that you were able to clarify because your original statement sounded dogmatic. But you are right, developers should "always use the best tool for the job". Sometimes that tool is procedural, sometimes it is object-oriented.

There is a recent trend in HPC applications to refactor legacy codebases because although the original code runs fast, it is nearly impossible to maintain. With the recent advances in hardware technology, namely multi-core processors, low-latency and high-bandwidth interconnects, and various memory hierarchies the original "fast" simulations are now "slow" (well, the codes are "not as fast as could be" and thus the hardware is wasted).

In my biased opinion, I think that codes will become more modular but not necessarily OO. The kernel in which 90% of the time is spent still needs to be optimized to the Nth degree and procedural code can be easier to optimize. But all of the glue code that inputs, outputs, communicates, etc. needs to be efficiently separated.

In the end, I agree, "there is a place for everything" and too much of anything (procedural or OO) "just adds unneeded complexity to a program".

-J

Re:Fortran has some coolness

[adrianmonk]

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.

OK, here's my 44-line version written in C. The only library calls I use are printf(), putchar(), and atoi(). I even inserted several blank lines and separated out the banner printing into a separate function to make it easier to read. I didn't group groups of 3 months together horizontally like /usr/bin/cal does, but I don't think that would take more than an extra 13 lines; I'm just too lazy to do it right now. (And yes, it really works. I used a shell script to test the math against the output of /usr/bin/cal, and it at least gets the day of the week of the first day of the year right from 1753 up through 2499.)

Re:Fortran has some coolness

[LizardKing]

Especially if you use something like C++ you know perfectly well how the resulting code will behave.

My usual assumption is that it will misbehave. As someone else pointed out with a slightly tongue in cheek quote, if you aren't totally on the ball you end up creating unexpected copies of your objects. I try to unit test my code with instrumentation on the constructors to see when they're called implicitly (default, single argument and copy constructors), then I can make sure my use of STL containers, initialiser lists and so on are optimal.

Re:Fortran has some coolness

[Snoboo]

Especially physicists (I am one myself) have a tendency to write unmaintainable code - because physics is all that matters and maintainability is of no importance. Who is going to look at the code tomorrow anyway? I have seen buggy bash scripts control AMS machines and fortran code, that was both impossible to understand and impossible to debug. OOP has nothing to do with the quality of the code itself.

Re:Fortran has some coolness

[Anonymous Coward]

You forgot the keys, which of course are point-like and uniformly distributed on the surface of the keyboard. As the number of keys approaches infinity...

Re:Fortran has some coolness

[BlackPignouf]

Wow!

I suppose youve never seen any Ruby code.
Im pretty sure you could do this in just 10 lines while still being understandable.

5 minutes later
Got it! (Sorry, in 12 lines)

def calendar(given_year)
date=Time.utc(given_year)
print given_year
while date.year==given_year
print date.strftime("/n/n%B/n")+" "*3*((date.wday-1)%7) if date.day==1
print date.day.to_s.rjust(3)
puts "\n" if date.wday%7==0
date+=60*60*24
end
end

Here's the result (its well formatted and aligned in ascii):

2007

January
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31

February
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28

March
1 2 3 4
......
......

Re:Fortran has some coolness

[Anonymous Coward]

You know, the cryptic names were part of the joke.

Like the "printf( (c==-1)?" ":"%2d ", c );" and the hard-coded constants everywhere.

Now, for the job, I have professionally written around 2 million lines of code, so thank you very much.

If you want the code in a slighly less obscure version, just tell me...

Re:Fortran has some coolness

[Anonymous Coward]

In fact I bet that the whole of Vista is about 100 lines in Perl. The rest is bitmaps, sounds, the (heavily obfuscated) interpreter and unused cruft for further obfuscation.

Re:Fortran has some coolness

[TheRaven64]

You missed off the banner font for the heading. Also, if you're going to use that many library objects, you may as well do the whole thing in a shell script using banner and cal; I can duplicate your program's functionality in the following shell script:

#!/bin/sh
cal $1

Of course, doing so completely misses the original poster's point, as you have done.

Re:Fortran has some coolness

[Anonymous Brave Guy]

As the number of keys approaches infinity...

...You can type your program in Fortress instead? ;-)

Re:Fortran has some coolness

[BlackPignouf]

Sorry, but I don't know what a "banner font for the heading" is.

Oh, and with your silly argument, any program could fit in 1 line, the one used to call it! :)

Re:Fortran has some coolness

[conradp]

OOP is not just for "business programming" and GUIs, it's actually perfect for large-scale simulations. Simulations have events and objects and forces and flows and all of these are very well modeled by objects. The sort of "units consistency" and dimension and bounds checking that Fortress wants to embed in the language can all be done in C++ with cleverly-designed template classes.

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.

Re:Fortran has some coolness

[jonadab]

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

Umm. The program you just described could be golfed down to about thirty characters in Perl. The long version, with expansive comments to explain what's going on and why, would still be considerably less than 57 lines.

This is not to disparage Fortran. Printing out calendars is not really its designed purpose, and terseness is not usually given as one of its key strengths anyway. I'm just saying that your example isn't a very good one.

Re:Fortran has some coolness

[arevos]

Of course, doing so completely misses the original poster's point, as you have done.

Still, Fortran is not particularly famous for its expressiveness, and to claim its conciseness as a major strength is somewhat incorrect. 57 lines is a lot to create a calendar in, even with a banner font; I'd imagine you could do it in less lines even in C.

Unfortunately, it's not a very good benchmark, as the appearance and size of the banner font was not specified. Also, the original poster was probably not aiming for byte-crushing compact as an experienced Perl programmer could get it.

Re:Fortran has some coolness

[jonadab]

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

Probably not very much more, unless the coder is somebody whose mind can keep track of an infinite number of details simultaneously (e.g., Damian Conway).

The problem with golfing is exactly what you say: it's fairly illegible. So you have to keep track of some of the less obvious aspects of what's going on, and most of us can only keep track of so much of that at any one time. With really densely golfed code, six or eight lines (at 80 columns) is just about the limit in my experience.

Clear and well-written Perl code is another matter entirely, of course. If it's written correctly, you can understand about a screenful of code at a time (which even nicely formatted with comments will still represent a fair amount of logic in Perl, much more than the same number of lines of C for instance). A well-designed program tries to limit each logical unit (e.g., a subroutine) to about that length, so that you can easily understand the section of code you're working with at any given moment.

As I said, there *are* people who can keep track in their heads of a large number of obscure details all at once, but those people are scary.

Still, 57 lines of Perl is far more than enough to print out a calendar.

Re:Fortran has some coolness

[Thuktun]

Don't forget the oft-quoted line allegedly from Steve Haflich in comp.lang.c++, "When your hammer is C++, everything begins to look like a thumb."

Re:Fortran has some coolness

[blafasel]

i do agree that fortran is a pretty nice language for array mangling. still, you might want to note that two of the fastest molecular dynamics engines out in the wild at this point (NAMD and GROMACS) are (at least mostly) written in C. the gap between Fortran and "the rest" has mostly closed.

Re:Fortran has some coolness

[somersault]

I thought the main attaction to Fortress was that it was the first to introduce classes?

What's that you say? Oh, sorry, wrong /. section, wrong shade of blue..

Re:Fortran has some coolness

[Anonymous Coward]

Oh, and with your silly argument, any program could fit in 1 line, the one used to call it! :) Yeah boss, but with your silly argument, any program could fit in 10 lines: the ones used to define the variables of your preexisting classes. To solve the problem as described, you'd have to implement the date and time modules yourself in less than 47 lines (what you have left).

cal is an existing script that comes preinstalled on many Unix variants. It is just as reasonable to use it as a standard part of Bourne shell as it is to use the Date and Time modules in Ruby. That's how shell scripts are written. Your parent was pointing out how silly your argument was via a method called Reductio ad absurdum.

Re:Fortran has some coolness

[jgrahn]

[C++]

As someone else pointed out with a slightly tongue in cheek quote, if you aren't totally on the ball you end up creating unexpected copies of your objects.

I've been programming in C++ daily for years, and I've never seen this bug. Not even in beginner's code.

I've seen void f(string s); when void f(const string& s); would have been more efficient, but never an actual harmful copy. If I don't want a type to be copyable, I forbid copying.

Re:Fortran has some coolness

[LizardKing]

This feature (it's not a bug) can bite you when using STL containers. Check out Cargill's "C++ Programming Style" or Meyer's "Effective ..." books for examples. The implicit calls to single argument constructors to convert types can also result in unexpected copying. AS I pointed out, if you're concentrating all the time then this sort of thing can be avoided. However when writing a big system, the inevitable little lapses can really take their toll - that's another reason for unit testable code, as profiling the whole system isn't always practical.

Re:Ambitious

[RAMMS EIN]

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

Multi-core?

[Nasarius]

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?

[IvyKing]

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?

[Cassini2]

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?

[RAMMS EIN]

``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?

[DrDitto]

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?

[iluvcapra]

Please read about parallelization 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?

[P Fayers]

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?

[Nasarius]

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

Re:Multi-core?

[Nasarius]

Ah, finally a relevant response. BTW, Fortran already has parallelization extensions. I've used it for some scientific calculations.

Re:Multi-core?

[P Fayers]

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?

[Anonymous Coward]

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?

[AchilleTalon]

"Fortress is proposing a language to automate that scaling."

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.

Re:Multi-core?

[DrDitto]

I know this. But using the T1000 Niagara processor as an example platform for a scientific programming language is just plain wrong!

My experience with the Niagara is that your program better have NO serial bottlenecks. A parallel, 32-thread make of Firefox is twice as slow as a 2-threaded make of Firefox on a Core 2 Duo.

Re:Multi-core?

[TeknoHog]

Fortran does some level of parallelization since F90. Specifically, it has builtin matrix/vector operations, which are inherently parallel operations, so they can be readily parallelized by a compiler. In 2001 I wrote some code at CERN for a dual Pentium III, and the PGF90 compiler made good use of SMP and MMX/SSE.

Of course, there's a lot to improve when it comes to parallelizing code besides vectors/matrices, and I assume Fortress is addressing some of these issues. In any case, a higher-level language is pretty essential to deal with parallel operations; you don't want to write a sequential loop to add two vectors, for example.

Re:Multi-core?

[owlstead]

Fortunately, home pc's like to run multiple things in parallel. Especially if flash or other memory takes over from HDD's for running the OS and applications, there will be something to do for multi-processors. The state of current programs is pretty abysmal regarding multi-threading. Many programs do things in batches instead of delegating tasks to other threads. And for many programs this makes sense, because any (parallel) IO would kill the performance anyway. If that goes away, there is quite a lot to optimize.

Fortress looks more like a tool to do scientific programming. Although some home PC tasks might suit that bill (PAR checking uses some mathematics, for instance), many others won't, so we will have to use the more orthodox methods presented by Java or C# instead. And that *can* certainly be done. A parallel for loop seems to me something to avoid, since it sounds suspiciously to very fine grained parallelism, but I might do it not enough credit with this statement.

Most programmers would not understand all that mathematical mumbo jumbo anyway. Did you look at the examples? Not something to use in your basic word-processor application that.

Re:Multi-core?

[IvyKing]

And it differs from 8-way multiprocessor systems how?

Memory access. The cache and four memory banks are tied to the 8 cores on the Niagara via a crossbar switch, so the cache and memory are local. On an 8-way Opteron system, non-local memory access can involve 1 to 3 hops over the HT links and good luck getting adequate memory perfomance on an 8-way Xeon system.

Another difference is power consumption - a Niagara system consumes about the same (or less) power than a single core Opteron. Due to the lower clock speed of the Niagara, the 8 cores on a Niagara will not be 8X the throughput of a single Opteron. And as someone else pointed out, the FP performance of the Niagara 1 sucks - but the Niagara 2 is reported to be about 10X better.

Re:Multi-core?

[jstott]

Currently, all these multi-processor mapping activities happens manually, and it really sucks. It would be wonderful if programming languages supported this activity automatically.

That's the whole point of High Performance Fortran (HPF). You tell it what to do, and it figures out how to do the threading and data segregation for you: vector operations, different data models, block vs cyclic storage, load balancing, everything. The compilers are commercial, but they do exist for high-end systems.

-JS

Re:Multi-core?

[robj]

Actually Fortress has probably more mechanisms to support high-performance, programmer-controllable parallel computation than any other current language. Unfortunately they haven't published any good papers about the details yet, but slides 21 and thereafter of this Guy Steele lecture http://research.sun.com/projects/plrg/GSPx-Lecture 2006public.pdf make it very clear that Fortress does at least the following:

- Provide an abstract definition of data structures.
- Define reductions and computations over those data structures in an abstract manner.
- Allow specification of concrete mappings to particular processor and network topologies, such that those computations can be efficiently scaled to the local system.

In some ways it reminds me of Google's MapReduce system, but applied at the language level, in a way that allows library authors to create their own data structures and computational mappings in a fully extensible way. Super cool stuff, not only groundbreaking in the computer language world, but also potentially revolutionary in the scientific computing world.

And so what if their interpreter is written in Java? That's like writing off Java because the very first Java engines were bytecode interpreters! You walk before you run, and you interpret before you compile, when building up a new language from absolute scratch.

Also, they put a lot of emphasis on interoperability with Java, so there should be no problem using existing Java codebases to build UIs, etc. for Fortress apps.

Here's the actual summary from the Steele presentation:

- Regions describe machine resources.
- Distributions map aggregates onto regions.
- Aggregates used as generators drive parallelism.
- Algebraic properties drive implementation strategies.
- Algebraic properties are described by traits.
- Properties are verified by automated unit testing.
- Traits allow sharing of code, properties, and test data.
- Reducers and generators negotiate through overloaded method dispatch keyed by traits to achieve mix-and-match parallel code selection.

Re:Multi-core?

[TheRaven64]

A lot of scientific computing doesn't use floating point maths at all; it's too inaccurate. You use data types that represent rational numbers, and keep irrational numbers around as symbolic constants that are either factored out or only evaluated in the final output stages. All of this is then compiled to integer operations.

My memories of Fortran

[UnknowingFool]

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

Something short and useful in a modern language

[scwizard]

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

I don't see anyone trying to give credit where due

[zappepcs]

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.

Intellectual Fortress Commentary

[namtro]

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

dozens have tried before

[LM741N]

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.

[imbaczek]

With this guy as project lead, you can't fail in this domain.

Nothing like FORTRAN

[gregor-e]

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.

Re:Nothing like FORTRAN

[rbanffy]

Would something designed to replace APL actually replace something?

Will it make any sound?

From the specification, it is Ugly

[XPulga]

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

[Coryoth]

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

Re:From the specification, it is Ugly

[Bromskloss]

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

[Anonymous Coward]

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.

Re:From the specification, it is Ugly

[mritunjai]

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

C came from AT&T Bell Labs. Which AT&T editor do you use to program in it ?

The language specification is out in open (on research.sun.com, no less!). You're free to make an editor, if that satisfies your fancy.

Secondly you should have paid more attention in algebra and CS101 classes, if you haven't seen the mathematical math symbols for boolean operators - The ^ and inverted version of it! Remember, "&&" is NOT the symbol for logical AND in mathematics. Hell, I'm a mechanical engineering grad by education and you should have known better!

Re:From the specification, it is Ugly

[XPulga]

The major issue with Eiffel was the lack of APIs (or bindings) for useful stuff when the language appeared. The bindings came too late. My point in comparing Fortress to Eiffel was pointing out that Fortress may be closer to Eiffel than to Fortran, and the press release from Sun mentions Fortran alone.

Fortress may be wonderful for the scientific part, but I do hope Sun finds a way to keep the GUI/OS-interaction code in some other language (Java is reasonable), making it possible to build applications from Fortress and non-Fortress parts. Treating mouse and other UI events with that math notation won't be fun, even for the most devout Mathematician.

I didn't see in the specs (I skimmed through it quickly, could be my fault) how Fortress is meant to parallelize computations more efficiently. From all I saw, I assume each method runs atomically in a single thread and parallelization of methods is be based on the contracts.

I am a Perl programmer, and I don't think Perl is that unreadable. In fact, I agree with most of its design. I am happy that now we can point the finger at something else when someone complains about "weird syntax" and "too many operators".

Re:From the specification, it is Ugly

[Coryoth]

My point in comparing Fortress to Eiffel was pointing out that Fortress may be closer to Eiffel than to Fortran, and the press release from Sun mentions Fortran alone.

And I think that's reasonable, given that the role that Fortress is intended to play is far more important (especially given that it is a niche role) than what Fortresses ancestor languages are. It owes as much to Scala (at least it looks that way - I have no idea whether Scala was actually an influence) as it does to Eiffel. What counts is what it is intended to be used for - which is scientific computing and HPC where parallelisation counts: that is to say the niche currently filled by Fortran.

I do hope Sun finds a way to keep the GUI/OS-interaction code in some other language (Java is reasonable), making it possible to build applications from Fortress and non-Fortress parts. Treating mouse and other UI events with that math notation won't be fun, even for the most devout Mathematician.

I honestly have no idea what you mean here. I expect GUI/OS-interaction code would most likely look an awful lot like Scala, which is hardly a problem. The math formatting onlycomes in when actually doing mathematics. The rest of the time it's essentially just an OO language like any other, and won't look any different to any other language. Treating UI events will be straightforward.

I didn't see in the specs (I skimmed through it quickly, could be my fault) how Fortress is meant to parallelize computations more efficiently. From all I saw, I assume each method runs atomically in a single thread and parallelization of methods is be based on the contracts.

There are a number of things that Fortress does to make parallelisation work. For instance for loops are parallel by default, as are vector operations. Try looking at the "atomic" keyword to see more on how control of serial and parallel operation is handled. If you want easy parallelisation via each method working in a separate thread and contracts determining wait conditions then look at Eiffel and SCOOP: it introduces a single new keyword (separate) and allows you to do just that.

I am a Perl programmer, and I don't think Perl is that unreadable. In fact, I agree with most of its design. I am happy that now we can point the finger at something else when someone complains about "weird syntax" and "too many operators".

I think what you need to consider is how many operator symbols are defined by default in Fortress: it actually isn't that many. Fortress simply supports unicode and the ability to define new operators using classical math symbols - it doesn't have them all defined in the base language. Almost everything is farmed out to libraries. You may think it looks ugly and complicated compared to Perl but I (who have done a fair bit of Perl programming, and have spent time looking at Fortress as it developed) think you're being premature. See it in action or actually try using it yourself and I think you'll quickly find it is, in fact, a lot more readable than Perl.

Re:From the specification, it is Ugly

[bockelboy]

What kind of sick language designer writes an interpreter in Java to demonstrate something related to High Performance computing ?

Actually, it's not that bad of an idea. For example, if you are writing in C, you might be tempted to write a matrix-vector multiply as nested for-loops; you should write it as a library call, as LAPACK will always be faster than your code.

On the other hand, if you write in an interpreted language linked to a fast library, the cost of the library call is always O(1) while the numeric operation takes a lot more. If it takes LAPACK 4 seconds to do an operation with a 4000x4000 matrix, who cares if the library call took .000001s in an interpreted language instead of .0000001s in C?

So - just like anything else - as long as you use the tools correctly, they will behave as desired.

Re:From the specification, it is Ugly

[Valar]

NASA has their own language.

Re:From the specification, it is Ugly

[GileadGreene]

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

That's true to a certain extent. But the other reason that Fortran stays around is the sheer quantity of legacy Fortran code. In the aerospace industry (with which I have some experience) there's a boatload of old Fortran code lying around that gets used for all sorts of important stuff (computational aerodynamics, spacecraft trajectory computations, etc.). No one wants to port the code to a new language because (a) the existing code is known to work, while any port might introduce bugs, and (b) the guys that actually understand what the code does and how it works are likely retired or dead, which increases the chances of introducing a bug during a port. So while Fortress may be a worthy replacement for Fortran (no argument there), there's no greater chance of a move to Fortress than to any other language for a lot of the legacy code out there.

Re:From the specification, it is Ugly

[LarsWestergren]

What kind of sick language designer writes an interpreter in Java to demonstrate something related to High Performance computing ?

Someone whose knowledge of Java performance is much more up to date than yours.

Re:From the specification, it is Ugly

[Sinical]

I was at my folk's for Christmas, and somehow we got around to my dad showing me his APL language reference something or other. It, too, has ridiculous numbers of symbols, and requires a specific keyboard configuration to use. Check it out at Wikipedia (keyboard image is about halfway down). It's wacky, I mean I never imagined that floor() and ceil() would ever have their own operators.

Re:From the specification, it is Ugly

[geekoid]

I can't decide if you were trolled, or if that 'Perl Programmer' is as ignorant about programming as his post indicate.
I mean how far off did he need to go to completly overlook the point of why they called it a FORTRAN replacement?

Good News, but work is still needed

[deadline]

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 articles on ClusterMonkey.

C didn't fail...

[mangu]

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

[RAMMS EIN]

``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), which claims CMUCL 19c produces code as fast or even faster than GCC 4.

Re:C didn't fail...

[Anonymous Coward]

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


Aliasing is a major nightmare, on something like a Playstation two. But it's not a major show-stopper on our x86 computers. And there's so much computer science put into C compilers that even if theoritically Fortran should always be better, in practice C is the same.

C has all sorts of things that can make you shoot yourself on the foot.
But C is a practical, good enough language to design a Kernel or a 3d engine. C++ could replace it for those uses but Stroustrup tought it was great to include everything and a kitchen sink inside his language AND pretending it's a "system language". It's not. Everyone who uses C++ for low level work uses a very strict subset, mostly C with Classes. Most of the best 3D engines i know are written in C or "C with Classes". Full blown C++ engines with high use of all it's features are very slow and crappy. C++ itself is as slow as Java, if you don't use the "C Subset" of C++. Iostreams SUCKS.

Re:C didn't fail...

[mangu]

but it has still not superseded FORTRAN

Well, there are still people who ride horses, so you could also say that cars haven't superseded horses, right? BTW, the all-capital spelling is definitely out these days, according to the latest standards, the language is now called "Fortran".

there are still issues in C that prevent C code from being as heavily optimized as FORTRAN

There are some C compilers that do not generate code that is as optimized as the best Fortran compilers. Also, a mediocre programmer can create a C program that doesn't optimize very well. After all, C is an extremely flexible language that will let you do almost anything you want. But I don't know of any issues that will not let a program written by a competent programmer in C be as optimized as the best Fortran program.

Having said all that, I must admit that I still use Fortran to some extent. For instance, I use LAPACK, in the FORTRAN-77 version. But it's compiled in my machine using the ATLAS optimizer, which is a C program that creates a version of LAPACK that's optimized for the machine you are using. You see, to get the ultimate performance they had to use C...

Pointer aliasing, it's true, could create problems for optimization in some cases, but that could be circumvented by specific "#pragma" declarations, as I mentioned in my GP post. But the most efficient optimizations, such as using SSE2 in Pentium CPUs or the equivalent instructions in AMD machines, go way beyond what can be used by simple syntax manipulations.

To use the full power of things like vector-like CPU operations you need to use an algorithm suited for the purpose. There is no language or compiler that will change a poorly designed program into a good one. Using the right algorithm is the first step in optimizing, I know of no compiler that will analyze a program and decide, "hmmm, this is actually a Fourier transform, let's use an FFT instead".

as opposed to pgfortran?

[Anonymous Admin]

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?

[Anonymous Coward]

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.

Re:as opposed to pgfortran?

[Anonymous Coward]

Highly optimized on 1024 procs? I doubt it. When you scale that large you usually have to switch to a message passing model to account for caching and such.

Welcome FORTRESS

[echusarcana]

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.

Re:Welcome FORTRESS

[Anonymous Coward]

Clearly, you have no idea want your talking about. Fortran 66 became an ANSI
standard in March 1966. Fortran 77, the revision to F66, became an ANSI
standard in April of 1978. I don't have access to the Fortran 90 standard,
so can't post a date, but Fortran 95 was ratified in 1997 as an ISO standard.
Fortran 2003, the newest standard, became the standard in Nov. of 2004.
Work is currently underway on Fortran 2008. You can read about the details at
http://www.j3-fortran.org/ The fact that several vendors offered often
incompatible extensions isn't the fault of the various Standard committees.
Fortran, as a standardize language, has been around for over 50 years. You
can't say that about any other language.

As to Fortran in GCC. It is alive and well. You can go to http://gcc.gnu.org/ or
http://gcc.gnu.org/wiki/GFortran to learn more. You may also be surprised
that gfortran is competitive with commercially available compilers. See
compiler comparison at http://www.polyhedron.com/

Simulations

[Ardanwen]

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:Simulations

[Kremmy]

Well that explains why those labs take so damn long to get results.

Re:Simulations

[kv9]

VIR_FAM.times {|family| $virii << Virus.new(nil,family,VIR_POP) }

from what you're pasting there, I suppose you're some sort of scientist. if so, could you explain:

In the English language, the standard plural of virus is viruses. This is the most frequently occurring form of the plural, and refers to both a biological virus and a computer virus. The less frequent variations viri and virii are virtually unknown in edited prose, and no major dictionary recognizes them as alternative forms. Their occurrence can be variously attributed to hypercorrection formed by analogy to Latin plurals such as radii; idiosyncratic use as jargon among a group, such as computer hackers; and deliberate word play, such as on BBSs (see, e.g.: leet).

do you just like using "virii" to piss people off, or is it the big stick up your ass?

Re:Simulations

[Anonymous Coward]

I'm betting that "virii" is used because it's shorter than "viruses", is easily understood, and is uniquely searchable/replaceable. Same reason I deliberately "mispel" my variable names.

INCONCEIVABLE

[OpenSourced]

...and is published under the BSD license.

-...You keep using that license. I do not think it means what you think it means.

Re:INCONCEIVABLE

[Aladrin]

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

Excellent reference!

Re:INCONCEIVABLE

[adrianmonk]

...You keep using that license. I do not think it means what you think it means.

Yeah, that's it. Sun doesn't know much about the BSD license. That's real easy to believe considering that Sun was founded by a small group of people including Bill Joy, who happens happens to have been one of the major authors of BSD in the first place, having written (at least) the TCP/IP stack, the vi editor, and the C shell.

Oh, and versions 1.x through 4.x of SunOS were based on BSD. SunOS 5.x is based on SVR4, but it also has both source and binary compatibility with the SunOS 4.x, so it certainly has some BSD code in it as well.

So, I think Sun is in a position to grok the BSD license. And even if they didn't, they could still put this stuff in commercial products, since they own the copyright and don't need a license to do whatever they want with it.

Make it LaTeX compatible!

[inverselimit]

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!

[Bromskloss]

LaTeX is the one that should change, imho.

Re:Make it LaTeX compatible!

[rkww]

> Unicode will never be flexible enough to be as dominant

never say never -- sooner or later we'll be able to hand write this stuff.

Re:Make it LaTeX compatible!

[the_greywolf]

Tell that to good Mr. Knuth, who wrote (and maintains) TeX.

i totally agree...

[andyr0ck]

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

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.

Fortran aint that fast...

[spagetti_code]

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.

Re:Fortran aint that fast...

[Bromskloss]

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.

What would one such complex operation be?

Re:Fortran aint that fast...

[mjc_w]

Another possibility is that the program used a lot of indices (for 1 and 2 (or more) dimensional arrays) and the fortran version had subscript checking on. My experience is that subscript checking can add (undex VAX VMS) up to 20 to 30 percent to the run time. My experience is also that this catches at least 1/3 of my errors and is definitely worth it.

Fortran (and Ada) are languages that understand arrays.

In C, an array is a pointer, an offset, and a prayer.

Re:Fortran aint that fast...

[spagetti_code]

Geeze, its a long time ago - that level of detail has long been moved aside to make way for more important details about wine and beer.

There was definately a crapload of matrix ops and eigenstuff going on... Stuff that I suspected at the time wasn't a chip op but a library implementation.

Re:Fortran aint that fast...

[hitmark]

i think the fast part is about coding, not execution speed.

but then i have no experience with fortran...

Re:Fortran aint that fast...

[TopherC]

I did a fair amount of programming in Fortran 77 (plus usual enhancements) not long ago. I agree that compiling programs with bounds-checking is extremely useful and easy to do. With C or C++ programs, that's possible but quite a bit harder and much slower. That said, I still prefer C or C++ in general since it tends to encourage better design, which in turn makes things easier in the long run.

At about that same time ('95-'01), I discovered Perl. It really worked well in conjunction with the Fortran programs! Perl's one serious weakness is efficiency, both in terms of memory and speed, for number-crunching. Fortran's primary weakness is in its user interface possibilities, string handling, and job control. Those two languages really support each other well! These days I love writing in Python whenever it's a reasonable choice. When you aren't pushing the envelope of a computer, which is probably the case far more often than not, these scripting languages are fantastic!

Keep in mind two kinds of programmer: One who writes programs for others to use, and one who writes programs for their own use. Fortran and probably Fortress are really designed for the latter group. I'm arguing that in that environment, a scripting language is also tremendously helpful.

You will never replace Fortran

[vm370guy]

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.

Re:You will never replace Fortran

[daverabbitz]

Real men use punch-cards.

Fortress rejected by DARPA

[Arakageeta]

As previously noted http://it.slashdot.org/article.pl?sid=06/11/22/203 7231, Fortress was Sun's failed entry in DARPA's HPC program.

Re:Fortress rejected by DARPA

[htd2]

Hardly, Sun, IBM and Cray were competing for HPC platform projects. The key is in the reference to proximity computing which is very definitely not anything to do with SW.

Go read about it...

[mritunjai]

Folks,

Seriously, first go and read about it before making any comments or cracking FORTRAN jokes.

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.

Please follow the links to the specification down in this thread and go through it, if your busy schedule permits.

Thanks

Re:Go read about it...

[bunyip]

Integration with typography? Mathematica does this, and also has multi-paradigm support. I've been using Mathematica for years and really like being able to type readable equations, use Greek letters, etc.

That said, typing of variables is kind of interesting.

Alan.

Should the value of pi change...

[Chris Shannon]

pi does not equal 3.141592653589793. It has many more digits than that.

Re:Should the value of pi change...

[rbanffy]

The main different between a matematician and an engineer is that engineers understand the concept of "equal enough".

Re:Should the value of pi change...

[Anonymous Coward]

Mr. Strawman, "referring to pi as" does not equal "pi is equal to." Thanks for the reminder, though.

(i am not the parent poster)

Re:Should the value of pi change...

[todslash]

But sometimes it does matter, especially as those errors will propogate through your calculations and accumulate (especially after a few million iterations). As your math teacher should have told you: Use as much precision as you can throughout your calculation and only drop the insignificant digits at the end.

The best and easiest way to get a value for pi is to use one of the trigonometric functions. When I started programming in fortran I was told to do this:
pi=4.0d0*atan(1.0d0)

which will automatically give you machine precision (depending on the accuracy of the math library).

Re:Should the value of pi change...

[todslash]

An addendum to my post:

rbanffy is actually correct, the value given is as accurate as you can get for that situation (which will be a 64 bit floating point number). The accuracy starts to get lost at about the seventeenth decimal place and the closest you can actually get to pi in the IEEE standard which has a 52 bit mantissa is: 3.141592653589793115997963468544185162

Re:Should the value of pi change...

[rbanffy]

Yes. But a matematician would never fall for that.

3.141592653589793115997963468544185162 is close, but it is not Pi. ;-)

Not at all

[Anonymous Coward]

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

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.

Re:Not at all

[Anonymous Coward]

LOL!

Someone just finished his compiler course. "call eval on the AST node instead of emit", LOL! "Opcode optimization" .. please stop.

I like your enthusiasm though, kudos.

Ugly AND Slow

[Thomas the Doubter]

The language looks like a cross between Pascal and Java, and with a Java virtual machine, it will not be fast. If HPC is the market for this language, Sun is way off.
Performance is the first and last consideration in the HPC arena. When Fortress can be compiled to machine code, then maybe it will be considered. There are already some good parallelizing compilers for FORTRAN, which are getting better all the time.

See also: DARPA HPCS Project

[briaydemir]

It's worth noting that Sun's Fortress project was not selected for Phase III of DARPA's HPCS project. (And for good measure, a link to a blog at Sun and an FAQ on how Fortress relates to the other HPCS languages/projects.)

Re:See also: DARPA HPCS Project

[napir]

Just remember... Ada WON a DARPA contest.

woo...hoo...

[Anonymous Coward]

Wasn't Fortress the loser in DARPA's High Productivity Computing Systems challenge?

http://it.slashdot.org/article.pl?sid=06/11/22/203 7231

Perhaps deriving "integer" from "commutative ring" made people think Sun went a little overboard with the OO.

HELLO SUN

[spacemky]

C     Hello World in Fortran

      PROGRAM HELLO
      WRITE (*,100)
      STOP
  100 FORMAT (' Hello World! ' /)
      END

Re:HELLO SUN

[geekoid]

Well done, you have made an excellent point regarding FORTRANs failing in being a hello world language.

SVN checkout

[lancelet]

Has anyone been able to do a fresh checkout via SVN since the SlashDot posting? I keep getting the following error:
svn: REPORT request failed on '/svn/fortress/!svn/vcc/default'
svn: REPORT of '/svn/fortress/!svn/vcc/default': 400 Bad Request (http://fortress.sunsource.net)

I even registered as an "observer" of the project in case that was blocking my SVN access.

I thought it'd be nice to play with it for a while... you know, before bashing it. :-)

Re:SVN checkout

[lancelet]

OK, after several hours' trying, it's now checked out for me.

Can it run Fortran-77 code?

[Anonymous Coward]

I apologize for wasting people's time with my ignorance concerning wrappers, etc. Will this new language run legacy Fortran-77 code with minimal alteration, as I hear is the case with Fortran 90/95? It seems to me the reason Fortran is still used so much is the huge amount of legacy code and libraries that will do just about any computational task by simply understanding the input/output and cutting and pasting, without having to constantly reinvent the wheel.

I have taken a single course in C++ and learned F77 by programming in it. Comparing the two, I have to say that F77 seems more readable (as long as variable names are descriptive), as if it were simply glorified BASIC with a complex data type.

I did run into a problem once where I needed more than seven dimensions for an array, and had to come up with a function to map "composite" indices. It was then I learned that C++ can handle greater dimensions. I also had memory problems, but could always restructure things to eliminate the problem. I guess C++ would have handled this better with dynamic memory allocation, but I hear this is also implemented in the newer versions of Fortran.

Use multiple languages in the same application.

[ChunderDownunder]

Fortress is hosted within a JVM.

The possibility exists to compile one's domain-specific fortress logic to bytecode. So where the fortress paradigm is applicable, use it. But if it is more natural to develop a GUI shell around it using Java, that's an option too.

Were this option explored fully, 'jfortress' code would have access to the java class libraries, as I believe ports such as jruby, jython and the rhino ecmascript environment do.

Re:Use multiple languages in the same application.

[BrokenHalo]

Fortress is hosted within a JVM.

Oh. Ah. Hmmm. Doesn't that mean you lose all three of the best advantages of Fortran? (Speed, speed and speed.) Sure, that might give the programmer access to a nice set of tools, but native Fortran libraries would be preferable.

I'm probably being a curmudgeon (again) but I catch a whiff of Sun maximising their investment in Java in the sciences arena. But then, I still use some libraries I wrote 30 years ago in Fortran 4, and they still work fine. If Sun cripples Fortran in this implementation, Fortress will deserve the oblivion to which that godawful RATFOR has rightly been consigned.

But are some more equal than others?

[Anonymous Coward]

"Equal enough" sounds like some weird animal farm invention...

exp(Pi*i) + 1 = 0 (equal)

exp(Pi) - Pi = 20 (equal enough)

exp(Pi*sqrt(163)) = 262537412640768744 (equal enough)

Equal enough is fine, but are some are more equal than others?

pointless

[oohshiny]

Fortress looks decent but wholly pointless. Numerical code these days has to co-exist with large C and C++ libraries and integrated into general purpose applications. Maybe a Fortress-to-JVM and Fortress-to-CLR compiler would be useful, but if Fortress lives in its own, separate world, they might as well not bother. As a language, I think it's unnecessarily complex. Fortran became popular because, as a language, it's dead simple; Fortress isn't.

Guy, fix Java, or start over with the next version of Java. Fortress is pointless.

Re:pointless

[DragonWriter]

Fortress looks decent but wholly pointless. Numerical code these days has to co-exist with large C and C++ libraries and integrated into general purpose applications. Maybe a Fortress-to-JVM and Fortress-to-CLR compiler would be useful...

The FAQ notes that their initial implementation target is the JVM.

Wish list

[Michael Woodhams]

I like the units capability - having done astronomy, this can be very useful.

I'd like to see matricies having all sorts of flags to specify their properties - real, complex, double precision, hermitian, symmetric, diagonal, triangular etc. Linear algebra libraries have huge numbers of routines for various combinations of these (e.g. a different routine to solve a system of equations where the matrix is diagonal than when it is not, or eigenvectors of a symmetric matrix vs an asymmetric one.) With these flags, the compiler could quietly use the correct routine. It would also know how to assign flags to newly calculated matricies, e.g. a matrix times its transpose is always symmetric.

It would also be handy to allow matricies to quietly acquire and carry alternative representations: LU factorization, eigen-decomposition/diagonalization etc. Once the LU factorization has been done, it is cached, and any later operations with that matrix which can benefit from an LU factorization make use of it. (This automatic behaviour would need to be easily overriden, for memory efficiency reasons.)

Objects are meant for simulation

[backwardMechanic]

There's a place for everything, and I'm not convinced that simulations are the place for it.

Um, one of the earliest OO languages was Simula (http://en.wikipedia.org/wiki/Simula). The clue is in the name, it was designed for simulation. I can write code that's near impossible to debug in any language, and OO code is no exception. Writing OO code does take a bit of practice. But well written OO code can be a real pleasure to use, very easy to read, maintain and extend.