Why Scientists Are Still Using FORTRAN in 2014

New submitter InfoJunkie777 (1435969) writes "When you go to any place where 'cutting edge' scientific research is going on, strangely the computer language of choice is FORTRAN, the first computer language commonly used, invented in the 1950s. Meaning FORmula TRANslation, no language since has been able to match its speed. But three new contenders are explored here. Your thoughts?"

Comments

Q: Why Are Scientists Still Using FORTRAN in 2014?

[dtmos]

A: Legacy code.

It's the right tool for the job

[Balial]

Scientists work in formulas. Fortran was designed to do things naturally that don't fit into C/C++, Python, whatever.

Re:It's the right tool for the job

[smoothnorman]

mod the above up please (i'm fresh out of mod points), because that's it in a nutshell. Fortran was designed for science/engineering work. And here's something that a majority of computer-science mavins never seem to grasp. In academia, at least, the use of a program is often relatively ad-hoc, and for the life of the publication. they need to have lots of numerical stuff down by easily references libraries, then handed off to their (poor) dost-docs/grad-students to study for their own one-off programming purposes. That is, the next vital program will have little to do with the previous except for those same well referenced peer-reviewed linked-to numerical libraries. Does that sound like a perfect use (model) of Clojure or Haskell to you? (yes yes you in the back, i know you brush your teeth with monads, but you're the rare case). Haskell and friends force you to think a lot up front for gains at the rear-end, but with much of academic programming there's no rear-end.

Re:It's the right tool for the job

[Anonymous Coward]

Also because vector machines are coming back, sort of.

Re:It's the right tool for the job

[Cramer]

Not so much that it "doesn't fit", but that some things are a pain to do and the compilers suck at handling it. (eg. array math. even 2 dimensions is a mess in C/C++)

Re:It's the right tool for the job

[Darinbob]

I think this is indeed the problem with a lot of languages explicitly designed to be more concurrent or parallel. I looked at SISAL and similar languages ages ago in grad school and they really were more difficult to understand and get the concepts clear. Not so bad for CS students (or CS grad students in the case of Haskell) but do you really want the physics or chemistry academic to learn a style of programming language that the vast majority of programming professionals don't even understand or care about?

Re:It's the right tool for the job

[wiredlogic]

You might not want to be so quick to write off Python.

Re:It's the right tool for the job

[Anonymous Coward]

Because scientists doing real work care about some hipster's Github page?

Re:It's the right tool for the job

[slickwillie]

Shouldn't the Haskell code in the article be

  fib 0 = 0 ...

Re:It's the right tool for the job

[jbo5112]

The python code I tried ran at half the speed of my C++ code for machine learning (mostly matrix crunching). The situation got worse for python when I could push C++ compute steps into compile time. Scientific modeling seem to need a lot of number crunching.

Re:It's the right tool for the job

[Marginal Coward]

...but with much of academic programming there's no rear-end.

I guess that explains why Sir Mix-a-Lot left academia to pursue a career in the popular arts.

Re:It's the right tool for the job

[narcc]

A painfully slow language that struggles to maintain compatibility between versions?

Yeah, what a great replacement.

Re:It's the right tool for the job

[TapeCutter]

Formula's fit "naturally" into modern "languages" such as Mathematica, MatLab, etc.

Of course hindsight is always of the 20/20 variety - If we could find a Delorian, we could time travel back to the early 50's and present The good doctor with a technical demo of CUDA running on a modern $150 video card, do we think the boffins of today would be using C++ CUDA kernels, or FORTRAN?

Aside from the hindsight fantasy, what's wrong with using FORTRAN in the way it was intended to be used? - Old certainly doesn't equate to useless, if it did I would be out of a job! Sure, I can be a cynical old bastard but I hope I never become so cynical as to forget I am "standing on the shoulders of giants" when I fumble around with the truly awesome computing power of my "commodity" video card(s). For ~$200 I can get a video card from the local shops with at least an order of magnitude more raw number crunching power than Fujitsu's game changing numerical wind tunnel that held the supercomputing heavyweight tile in the early 90's (not that long ago for someone who was born 2yrs after FORTRAN).

It truly is an interesting time to be alive, during most of the ~500 year old "enlightenment", most the great polymaths such as Newton were children of nobility and the upper classes, they didn't make it into the history books because nobility are any more insightful than commoners, we know their names because they were the only people with enough time and money to devote to intellectual pursuits. It really didn't impact or concern the "common man" until the arrival of the telegraph, public railroads, museums, clothing dyes, public sanitation, etc, took off in the Victorian era. Today the "common man" (at least the western version of him/her) has the time and money to pursue their own intellectual interests, they also have access to a vast repository of knowledge at their fingertips enabling them to learn from others who have gone before them.

The commonly heard lament of the creativity impaired that there's "nothing left to invent or discover", has never before been a more reliable signpost to a lack of intellectual curiosity than it is today. Knowledge begets knowledge, the explosive growth of Science and Technology I have witnessed in my middle aged life time look like it will continue on it's exponential trajectory. I hope the society my grandchildren become part of points that awesome power toward solving the critical problem of the 21st century, resurrecting our neglected and abused life support systems to their pre-industrial glory.

Re: It's the right tool for the job

[Anonymous Coward]

Piss off.

I'm not going to regurgitate his entire CV just because you're too fucking lazy to do your due diligence before you run your twat mouth, but just for giggles ...

Director of Research - Physical Sciences, University of Washington
Former NSF post-doctoral fellow
Co-author of a book and 19 scholarly articles, numerous talks, author/contributor/maintainer of several prominent scienc-y Python libraries

Sounds like a real scientist who does real research to me.

Re: It's the right tool for the job

[Anonymous Coward]

It's Numba vs Cython though, not Fortran.

You should do better research before posting irrelevant crap.

Re:It's the right tool for the job

[Kaz Kylheku]

Is it possible that scientists work with throwaway programs that don't integrate with anything, are operated by command line interfaces, and assume that all their inputs are correct and trustworthy?

Re:It's the right tool for the job

[Anonymous Coward]

Are you using numpy for python or cblas and lapack for c/c++? They make a huge difference. blas is a little painful to use if you are used on an OO syntax for matrix manipulation but there are half-a-dozen major wrappers for matrix manipulation that can be used, although which one works the best for you would need to be teased out with benchmarking. You can probably create your own matrix wrapper class and then relatively quickly prototype that by changing the implementations within that class to each of the main abstractions, then recode to not use the wrapper if the secondary abstraction is an issue.

numpy and scipy are largely written in C, so effectively by using those you are calling C, it's just a convenient way to do this, and keeping the python syntax at the human-visible end of things.

To get the best speed you need a hardware-optimised underlying implementation and they are not generally free.

Depending on how you have implemented and compiled your code at the moment and what levels of hardware-optimised underlying implementation you can access then a speedof execution improvement of an order of magnitude could be very possible.

The basic premise is to use the work that Jack Dongarra and his team of contributors have done over the past approximately 40 years and the best optimised version of that for your hardware. That's assuming that you can't improve the algorithm, but you can take legacy code and pep it up considerably in many instances.

Re:It's the right tool for the job

[shutdown -p now]

People using Python for this kind of thing usually don't use it for the entire thing. Compute-heavy parts are pushed out to C or C++ or Cython (or even Fortran!), while Python handles the higher-level things like input parsing and pretty graphs made from results.

Re:It's the right tool for the job

[chthon]

Please choose your examples well.

Although son of a well to-do farmer, Newton was not nobility, and could only study because of recognition of his talent. Gauss was the son of really poor people.

Re:It's the right tool for the job

[mrchaotica]

Are you using numpy for python or cblas and lapack for c/c++? They make a huge difference. blas is a little painful to use if you are used on an OO syntax for matrix manipulation but there are half-a-dozen major wrappers for matrix manipulation that can be used, although which one works the best for you would need to be teased out with benchmarking.

I hate to break it to you, but if you're using BLAS then you're still using Fortran!

Re:It's the right tool for the job

[Type44Q]

Haskell and friends force you to think a lot up front for gains at the rear-end

Increasingly popular in Europe, apparently...

Re:It's the right tool for the job

[jbo5112]

That was with numpy in python. In C++ I was using the Armadillo library, but I'm not entirely sure what is going on underneath that. Both blas and lapack are dependencies, and it uses different ones for different operations. However, I'm not sure if it was using blas3 or openblas because they're both installed.

I should point out that this was for a machine learning class, so the matrices were fairly small. At a larger scale, the difference may have been more negligible due to other overhead, but I do know that in C++, >98% of the CPU time was typically spent on matrix operations. However, Armadillo supposedly provides some nice runtime optimizations, and I seem to remember sizable compile times, given the small programs I was writing.

I was using C++, but if Fortran was responsible for a good, compiled library then I'm glad they used it. It's a language I may have to look into, when I get a chance. I hate to see good hardware go to waste, simply because of shoddy software.

Re:It's the right tool for the job

[lee1]

Author here. While mathematicians usually begin the series with zero, in papers about computing the initial zero is often left off. I should have been consistent, though.

Wrong question

[Brett Buck]

Why not?

      Actually that is a serious question, for these sorts of applications there seems to be no significant downside.

Re:Wrong question

[jythie]

That is what tends to bother me about these 'wow, people are not using what we in another field are using!' type questions. FORTRAN does its job well, has libraries relevant to what people are using it for, and experience in it is common within that community. Why shouldn't they use it?

Re:Wrong question

[timeOday]

Computer languages turned out to be one of those things that seem very deep and significant, but actually aren't. FORTRAN and Lisp (and BASIC and C, only somewhat later) made programmers about as productive, within a reasonably small constant factor, as anything since. (And before you hit me with "Citation Needed," remember it cuts both ways!)

Re:Wrong question

[Rhys]

There's actually significant upside.

Ever debugged a memory error in C? Ever done it when it is timing dependent? How about on 1024 nodes at once? Good luck opening that many gdb windows.

I TA'd the parallel programming class. I told the students (largely engineers & science, not CS) -- use fortran. Lack of pointers is actually a feature here.

Re:Wrong question

[Shompol]

FORTRAN and Lisp (and BASIC and C, only somewhat later) made programmers about as productive, within a reasonably small constant factor, as anything since.

I recently switched from C to Python, and my productivity shot up ~100 times. For example, I created a tree of hashes to perform pattern matching on large data sets in linear time. It took me 2 hours from concept to production run. Also factor in a huge library that does everything needed on this planet, ease of maintaining 100x fewer lines of code and 0 memory management hurdles.

The downside is that it runs 100 times slower than C, but since it is the programmer's productivity your are talking about, you are very wrong.

Re:Wrong question

[mbone]

The downside is that it runs 100 times slower than C, but since it is the programmer's productivity your are talking about, you are very wrong.

You do realize that CPU limited problems are not uncommon in physics and engineering?

Re:Wrong question

[Anonymous Coward]

Depends precisely on what you're trying to do.

End-user or similar application? Perhaps you're right.

Trying to do low-level OS stuff reasonably portably (Which may include the pointerless language you're using...)? Lack of pointers is a MISFEATURE there. I don't CARE what you say about debugging a memory error here- totally and completely differing mindsets and requirements.

Re:Wrong question

[Anonymous Coward]

>How about on 1024 nodes at once? Good luck opening that many gdb windows.

Um, if you TA'd, you really should know about Totalview.

Re:Wrong question

[Anonymous Coward]

What second rate class doesn't teach people how to use the right tools?

There are a ton of formal analysis tools for C/C++ code that can detect such problems and more (assuming you've got a few hundred machine hours to run the analysis and validation suite - but if you're in this industry, that's a given).

Using Fortran doesn't give you a free pass to bypass QA and formal validation of your code, just as using C doesn't make it any harder (the only part I'll concede here is in C you 'can' more easily shoot yourself in the foot, where as in Fortran you have to go out of your way to do so at both a language and compilation level).

Re:Wrong question

[Anonymous Coward]

You can build good C++ that doesn't use pointers. Or at least not that are exposed to the programmer. It's not the destiny of every coder to drown in pointer arithmetic.

Re:Wrong question

[Anonymous Coward]

Lack of pointers is actually a feature here.

Fortran has pointers.

Re:Wrong question

[amaurea]

In my experience they are the norm rather than the exception. I work on a program that takes 12 hours on 320 cores to complete (and that's when we still only have a small fraction of our expected amount of data). If it were all written in python, it would take weeks to months instead.

Re:Wrong question

[Anonymous Coward]

>How about on 1024 nodes at once? Good luck opening that many gdb windows.

Um, if you TA'd, you really should know about Totalview.

Totalview is not free.

Re:Wrong question

[Anonymous Coward]

Python is not necessarily slow. If you use numpy properly, it can easily be faster than unoptimized C code in many occasions.

Re:Wrong question

[mrchaotica]

If you're buying 1024 computers to run your program, maybe budgeting a little extra for a better debugger is worth it.

Re:Wrong question

[Anonymous Coward]

Yeah, the numpy looks like this (program.py):

from OptimizedC import *
print callOptimizedC()

Re:Wrong question

[Anonymous Coward]

Hit the nail on the head. Fortran is tried and tested, does a damn good job for physics/engineering work, has a lot of battle-hardened libraries out there ready to go, and most people know it.

Plus it's old enough to have avoided much of the annoying cruft and buzzwordy bullshit baggage that weighs down many other "modern" languages.

Why not?

[grub]

At work in the recent past (2000's) we were still supporting FORTRAN on the SGI machines we had running. The SGI compilers would optimize the hell out of the code and get it all parallized up, ready to eat up all the CPUs.

Newer isn't always better.

Re:Why not?

[Anonymous Coward]

Interestingly the DeltaC compilers from SGI did the same for C code.

Ten Reasons to use Modern Fortran

[wispoftow]

1) Modern Fortran is not all uppercase
2) Modern Fortran does not have to start on column 7
3) Modern Fortran has dynamic memory allocation
4) Modern Fortran can use the same types as C (maximizes interoperability), hence can be called where C might be called
5) Modern Fortran has an objects, polymorphism, etc.
6) Modern Fortran has (a limited form of) pointers
7) Modern Fortran has concise array/vector/matrix operations
8) Modern Fortran has dynamically allocatable, multidimensional arrays that can be indexed starting with any integer
8) Modern Fortran supports the complex type without higgery-jiggery
9) Modern Fortran doesn't *need *pointers *in *all *the *places *that &C does, pass by reference is the norm
10) Modern Fortran is blazingly fast and designed for sciene ....

Some folks still write in Fortran 77, and the tired tales of woe that are bound to come from a language specification that is many decades old.

But, that code/style still works, and who am I to judge how you want to get your work done?

Re:Ten Reasons to use Modern Fortran

[rubycodez]

you left out the massive gigabytes of well-tested and respected numeric libraries for all the major fields of science and engineering (that are free for use too).....oh, and much of that written in F77. the most optimizable langague for numeric computation on planet earth, that's why supercomputer companies always sell ForTran compilers

Re:Ten Reasons to use Modern Fortran

[Anonymous Coward]

9) Modern Fortran doesn't *need *pointers *in *all *the *places *that &C does, pass by reference is the norm

yup. i'm sure that doesn't cause any bugs!

i just don't care enough to point how how dumb most of these points are.

Re:Ten Reasons to use Modern Fortran

[Anonymous Coward]

Libraries are libraries. They are pre-compiled pieces of code, and any language can use them.

Re:Ten Reasons to use Modern Fortran

[flappinbooger]

My college taught us, Mechanical Engineering majors, Fortran. Specifically. It's the only language they intentionally decided we needed to know as part of the core curriculum. This was at least as recent as the mid 90s.

I later discovered that the native scripting language used by the FEA code ANSYS, was ..... FORTRAN.

Re:Ten Reasons to use Modern Fortran

[ClickOnThis]

You know why some folks still write in the Fortran 77 standard? Because they had to wait too long for "Modern" Fortran to adopt the features you described, most of which appeared in other languages decades ago, and the rest of which I consider ill-advised (such as default pass-by-reference.) (Complex numbers are an exception; see below.) Those who wanted those features moved to languages that supported them and never looked back. The Fortran die-hards who remained never started using them because they didn't realize the advantages they provided.

Support for complex numbers arguably was an advantage for scientific computation with Fortran when other languages without it (such as C) or with limited support (such as Pascal) started arriving on the scene, but that deficiency was addressed elegantly in C++ and eventually in C also. In all other aspects, Fortran has very much been the laggard with regard to adopting new features.

Re:Ten Reasons to use Modern Fortran

[wispoftow]

I agree. I posted elsewhere on this thread saying essentially the same thing, especially about dynamic memory allocation and free-form input.

Re:Ten Reasons to use Modern Fortran

[Kaz Kylheku]

Pass by reference is the norm? That is moronic and encourages bugs. We should avoid destructive manipulation such as variable assignment as much as possible in programming; reference parameters exist to make it possible to modify a caller's variable.

If you have reference parameters in the language, then any foo(var) call can potentially modify var. If it doesn't today, then someone can change it tomorrow to give himself access to var inside foo.

The C convention of taking an explicit address is safe against this.

Pass by value should be the norm. Pass by reference shouldn't even exist.

Lisp is purely pass by value; there is no pass by reference: just that some types have reference semantics (cons cells, arrays, etc).

Re:Ten Reasons to use Modern Fortran

[wispoftow]

In my mind, I equate "passing by reference" as passing the memory location of the first element to a function, and passing by value as making a copy, then passing that to the function/subroutine.

If the array being passed consumes almost all of the memory of the machine (very common in scientific computing), then making a copy first would leave you dead in the water.

Re:Ten Reasons to use Modern Fortran

[wispoftow]

Also, I think that my quick post was fairly incomplete, it's a pretty big topic. People generally don't want to make copies every time data enters a function, for performance reasons.

Modern Fortran has "intent" statements that prevent overwriting by functions, that go quite a way in improving safety, and guaranteeing immutability for parallelization considerations.

subroutine dosomething( A )
integer, intent(in) :: A(:,:,:)
end subroutine dosomething

Altering A in this subroutine generates an error. In Fortran, if you wish to "pass something by value" thus keeping the original data, you can always do that explicitly. The copy will be passed by reference. (To the best of my knowledge, I hope a Fortran maven will correct me if I am wrong)

Re:Ten Reasons to use Modern Fortran

[ClickOnThis]

In my mind, I equate "passing by reference" as passing the memory location of the first element to a function, and passing by value as making a copy, then passing that to the function/subroutine.

[Pardon my Fortran -- it has been awhile.] The following illustrates why default pass-by-reference is a bad idea:

            double precision function foo(x)
            double precision x
            x = x + 1
            foo = x
            return
            end

            program main
            double precision y, z
            y = 1
            z = y + foo(y)
            print*, z
            end

What value does the above program print out? 3? or 4? The answer is: it depends. On the compiler, or on scheduling in the processor, or on the system. You can run this program repeatedly, and see both outputs appear at random.

The point is you cannot be certain of whether the value of the first y in z = y + foo(y) is obtained before or after the call to foo. Before? then y equals 1. After? It equals 2. In either case, foo(y) returns 2.

If the array being passed consumes almost all of the memory of the machine (very common in scientific computing), then making a copy first would leave you dead in the water.

Then pass it by reference. Obviously Fortran does this, but essentially so do C and C++ if the array is based on a primitive type. The array's address is still passed by value, but the receiving function can treat it as an array or as a pointer to the first element of the array. There's more to this, but the bottom line is that passing of large data-structures without copying is possible for all of the languages we're discussing.

Re:Ten Reasons to use Modern Fortran

[wispoftow]

This is a very interesting example. Would you believe that gfortran 4.2.1 gives z=2 (two!) and gfortran 4.8 won't even compile, due to a bizarre REAL(4) vs REAL(8) error? There's something very wrong with this, and your point is taken. (The intent(inout) attribute of f90 would not have helped here, either.)

I would point out that, since this has side effects, I would probably have done this as a SUBROUTINE instead of a FUNCTION. Then, things would have materialized in a predictable way. I try to write all of my functions as "pure" functions that have no side effects.

Re: Ten Reasons to use Modern Fortran

[Anonymous Coward]

One reason to NOT use FORTRAN: code style sucks

Strangely?

[fahrbot-bot]

When you go to any place where 'cutting edge' scientific research is going on, strangely the computer language of choice is FORTRAN, the first computer language commonly used, invented in the 1950s.

Perhaps it's still the best tool for the job. Why is that strange? Old(er) doesn't necessarily mean obsolete -- and new(er) doesn't necessarily mean better.

Re:Strangely?

[jythie]

"tool" is the key word. Within the type of research that uses it, they want a tool for getting their actual goals done. CompSci and such tend to see languages and such as points of focus unto themselves.

Re:Strangely?

[Dutch Gun]

Agreed. My thought at reading the summary was "Do older languages have some sort of expiration date I don't know about?" What's odd about it? Also, it's not like the language has been stagnant. English is an old "legacy" human language with lots of cruft and inconsistent rules, but it works well enough for us that it's not worth jumping ship for Esperanto.

A large part of it is probably the simple inertia of legacy, both in code, systems, and personnel. However legacy systems tends to eventually be replaced if a demonstrably superior product can improve performance in some way. Any significant change, even one for the better, causes pain and friction, so the change typically has to be worth the pain involved. Obviously in the eyes of many science-focused projects, it hasn't been worth switching to a new language. There's also value in having a body of work in an older and very well understood and documented language, as it means new team members are much more likely to already be proficient with the language than a newer and less popular language.

I can also understand not wanting to switch to some "flavor of the month" language when you're not sure how long it will be actively supported. FORTRAN has credibility simply based on it's incredible longevity. No, it's not new and sexy, but you can bet it will probably be around for another half-century.

Re:Strangely?

[Desler]

Agreed. My thought at reading the summary was "Do older languages have some sort of expiration date I don't know about?" What's odd about it? Also, it's not like the language has been stagnant. English is an old "legacy" human language with lots of cruft and inconsistent rules, but it works well enough for us that it's not worth jumping ship for Esperanto.

That is because you aren't a hipster or fad brogrammer. These idiots probably expect them to be using Node.js or some such bullshit.

Re:Strangely?

[Anonymous Coward]

My thought at reading the summary was "Do older languages have some sort of expiration date I don't know about?" What's odd about it?

If the language is older than the programmer*, he tends to think it's obsolete and bad, especially around 18ish. That's why Perl was considered obsolete by the early/mid 2000s, while Python was still okay for a while longer. Then Python hit 18 a few years ago and Ruby was all that was left, but now Ruby isn't cool either, so nobody talks about it positively any more. Haven't figured out what the new hotness is supposed to be after Ruby, but it'll get the same treatment as soon as it matures, too.

* With exceptions. A few languages seem to get a pass, and not everybody is a shallow idiot that assumes a language's worth is inversely proportional to its age.

Similar probelm to COBOL

[Anonymous Coward]

It's not a dead language. It still changes with the times. And there's a vast reservoir of code already written in it. Why cast all that away and start from scratch with new languages.

Of course, if you could make the new language recognize the old code and incorporate or interface with the new code then you could do a transition rather than a plain break with the past.

It's not a bad language

[Anonymous Coward]

There are languages with worse syntax and clunkier to use -- I'd rather know why people are still willingly using COBOL. "Too lazy/expensive to upgrade legacy infrastructure" isn't a valid reason, it's just a popular and convenient excuse.

Re:It's not a bad language

[John.Banister]

Someone told me (in 1986, I think) "It's amazing. You just write this documentation, and it runs!"

Re:It's not a bad language

[Desler]

Why rewrite things that are well-debugged over decades of use for untested code likely to contain tons of its own bugs?

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

No, not just "legacy code." Fortran (yes, that's how it's spelt now, not "FORTRAN") was designed to be highly optimizable. Because of the way Fortran handles such things as aliasing, it's compilers can optimize expressions a lot better than other languages.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

B: CUDA adaptations of legacy code.

Fortran is NOT the language of choice

[Rostin]

I have a PhD in engineering, and my dissertation involved writing lots of code. Now I work at a national lab in the US, and I and nearly all of my coworkers work on scientific or engineering codes of some sort. Although there is significant amounts of legacy code that was written in Fortran lying around (a project I work on uses a fortran library written in 1973), very little development is done in that language. It's all C++ or Python.

Re:Fortran is NOT the language of choice

[Anonymous Coward]

Agreed. I work at a university and run on national supercomputers.. Lots of legacy code exists in Fortran, but lots more development happens in Python or C++ now, sometimes with small kernels being written in Fortran.

Also, the speed difference of Fortran over decently-written C/C++ is non-existent. C/C++ lets you write things less efficiently, but it doesn't mean you have to.

Re:Fortran is NOT the language of choice

[Anonymous Coward]

Is this a recent change? I toured Goddard Space Center with my college in 2011 and we were told that they were -always- on the lookout for anyone with FORTRAN skills.

Re:Fortran is NOT the language of choice

[Anonymous Coward]

I imagine they need people to maintain their legacy stuff when the current maintainers retire.

Re:Fortran is NOT the language of choice

[AchilleTalon]

Fortran is a scientific programming language. You are an engineer, seems clear enough why you are not using Fortran. Any explanations needed?

Re:Fortran is NOT the language of choice

[Cramer]

Indeed. They were sniffing around the College of Textiles (!) in '95 when I was graduating. We were one of the few departments that required FORTRAN (77).

(I had been campaigning since '93 to stop that shit. 'tho it paid well as a Lab Instructor (aka "TA".) They switched to Java (ugg) in '96-97.)

Re:Fortran is NOT the language of choice

[Anonymous Coward]

what the fuck do these weasel words mean? what does it mean to be a "scientific programming language". what features would an "engineering programming language" have? does anybody know? how does this get modded up?

Re:Fortran is NOT the language of choice

[Anonymous Coward]

God. My school did similar thing. Dropped C++ in favor for Java SE. And they still teach swing and shit. No EE at all. ;_;

Re:Fortran is NOT the language of choice

[shutdown -p now]

On a somewhat unrelated note, if you are one of those people doing Python or C++ (and especially Python and C++ together) for number crunching etc, or if you know some of these guys, can you please spare two minutes of your time on this survey?

Re:Fortran is NOT the language of choice

[Anonymous Coward]

I think you don't know what engineering means. An engineering phd student does a lot of science.

Re:Fortran is NOT the language of choice

[Rostin]

I don't understand what you mean, so maybe some explanation is needed. Fortran may be a "scientific" programming language, but it was also the language of choice for engineers for a long time. The advantages that Fortran had over other, lower level languages were things like native complex numbers and built-in transcendental functions, features useful to both scientists and engineers.

When

[Anonymous Coward]

When will they ruin Fortran, like they are ruining everything else?

When will Fortran lose half its funtionality?
When will Fortran get a touchscreen interface?
When will Fortran do a forced upgrade to continue being supported?

Re:When

[mbkennel]

No, Fortran won't be ruined.

Fortran, the language, has evolved very significantly with little annoying cruft hurting current design on account of legacy compatibility.

The comparison vs C and C++ is instructive.

Re:When

[sjames]

Actually, Fortran has already been seriously damaged by some of that evolution. Once upon a time, Fortran was dead standard. If your Fortran program ran correctly on a PC it would run correctly on a mainframe, mini, or supercomputer. More importantly, it would produce the same result. It didn't matter which compiler you used.

Now, I see more and more programs that really need a particular compiler to compile at all, much less produce the correct result. Even avoiding -Ox where x>3 doesn't assure correctness anymore.

Re:When

[Anonymous Coward]

Once upon a time, Fortran was dead standard. If your Fortran program ran correctly on a PC it would run correctly on a mainframe, mini, or supercomputer. More importantly, it would produce the same result. It didn't matter which compiler you used.

I'm not really sure what fantasy land you are living in, but it's not the real world. Original PCs were 8bit machines competing with 64bit machines. If you were doing integer based math sure you had the same result (much much slower), but most of science is not integer math.

If you have doubts, take a basic trig function (4*atan(1)) and run that on an 8 bit machine and a 64 bit machine and look at the result. Since any idiot should recognize that as Pi, go ahead and run an equation that calculates the amount of liquid held by a few thousand cans.

Further, Fortran was never a dead standard. I heard lots of people claim it was, but it never went away. Analysis code has always been heavy Fortran, because it's fast and accurate, it runs parallel very well. If you heard the same thing and believed people, I bet you feel like a sucker now.

Re:When

[sjames]

I did not say it was a dead standard, I said it was dead standard. There is a huge difference. (now who feels like a sucker? :-)

Next, PCs had an 8 bit data bus but were 16 bit machines. Larger variables (including double) were handled just fine either in software emulation or the 8087 co-processor (later integrated into the CPU).

By contrast, it was only later on that C decided how many bits int and long were.

Re:When

[Blaskowicz]

Original PC was 16bit and had an optional FPU that computes on 80 bits internally. PC means "IBM PC" not Apple II, PET, CP/M, ZX81 etc.

Re:When

[rmstar]

If your Fortran program ran correctly on a PC it would run correctly on a mainframe, mini, or supercomputer. More importantly, it would produce the same result. It didn't matter which compiler you used.

This isn't true. As in C, optimizations might have changed the order of fp operations resulting in subtle differences that often matter. Memory allocation (yes, the static arrays) has some really funny weirdnesses across compilers that make buggy programs produce very different results on different versions of the same compiler. The F77 language has very little support for avoiding bugs, and quite a few booby traps. Most F77 codes are just riddled with bugs and depend on undefined behavior that varies a lot from one compiler to the next.

Just look at all the code generation flags of gfortran to get an idea.

Re:When

[sjames]

You're thinking about a generation too late. You're also thinking of -O values greater than 3 (though now, some compilers do unsafe re-ordering at nearly any O level).

It USED TO BE true. It isn't now.

Re:When

[ClickOnThis]

Once upon a time, Fortran was dead standard. If your Fortran program ran correctly on a PC it would run correctly on a mainframe, mini, or supercomputer. More importantly, it would produce the same result. It didn't matter which compiler you used.

That is a fantasy. It was never true. NEVER. You could not simply copy a Fortran program between machines and expect it to compile without modification. Compilers were notorious for implementing the Fortran standard inconsistenly.

And produce the same result? Don't count on it -- not without careful programming hygiene, to make sure there were no hidden side-effects, or integers that wrapped around on 16-bit machines but did not on 32-bit ones, or whatever.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[PPH]

At least Slashdot seems to encourage re-use of commonly used responses when a question is asked.

Memory management

[kefalonia]

The biggest reason of interest is that it helps non-computer-science scientists write up computational codes, neither having to devote excessive amount of time in memory management, nor deviate from the classic imperative programming model. And, it is also important for a purely non-technical reason: a generation of domain experts in engineering and scientific domains where trained in FORTRAN codes.

As managers of High Performance Computing platforms, we generally take an a-religious approach and deliver to the users all possible permutations of language types that a given community may need. The following is a very common setup, containing both GNU & Intel compilers: https://hpc.uni.lu/users/softw...

btw. I'm not defending Fortran in any kind of way; ask any Fortran-fun, in which language his compilers are written in ... there is a reason :)

Re:Memory management

[phantomfive]

Good point. Sometimes we forget how hard it is to adapt to the object-oriented programming style, since it comes so naturally to us. But if all you want to do is get the computer to implement your formula, OOP doesn't give you much.

Still a big hit in Vietnam

[smittyoneeach]

After all, it was "For Tran".

Re:Still a big hit in Vietnam

[grub]

That had me laughing.

Re:Still a big hit in Vietnam

[Anonymous Coward]

I'm a sucker for any gag involving punctuation or whitespace manipulation.

Re:Still a big hit in Vietnam

[Anonymous Coward]

Careful, around here they'll think it's tranny porn.

Re:Still a big hit in Vietnam

[Anonymous Coward]

Phuc, you?

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Nemyst]

This. I have many friends in the physics dept and the reason they're doing Fortran at all is that they're basing their own stuff off of existing Fortran stuff.

What amused me about the article was actually the Fortran versions they spoke about. F95? F03? F08? Let's be real: just about every Fortran code I've heard of is still limited to F77 (with some F90 if you're lucky). It just won't work on later versions, and it's deemed not worth porting over, so the entire codebase is stuck on almost 40 years old code.

As others have said... why not?

[Karmashock]

If the language accomplishes the task efficiently and effectively with no apparent downside then why attempt to switch languages simply for the sake of switching?

Furthermore, an ability to run legacy code should be sustained especially in science where being able to use that code again after many years might save scientists from having to reverse engineer past discoveries.

Re:As others have said... why not?

[Anonymous Coward]

The main reason is that people who do serious number crunching for a living don't waste time writing pretty new languages, porting all their code to it and testing that it is correct. And the people who write pretty new languages aren't interested writing compilers that are highly optimised for efficiently, precise mathematics using multidimensional arrays. Those as the article says Julia is an attempt at this.

I have a friend who is an astrophysicist and his dept. insists that all their precision number crunching is done in Fortran because the mathematician who wrote the code for them decades ago did all the calculations, statistics and errors properly and its been checked and used for decades so they know that the results will be correct. Their PhD students who try to do it themselves C++ alway end up wasting time time on their own code which gets things wrong and contains bugs, before they revert to using the Fortran.

I have another friend who is a programmer who worked on project for a genetic dept. trying to get their Fortran library routines for DNA sequence analysis, population genetics etc. working in C++. His major problem was inconsistencies in namespaces etc. in C++ across the various C++ compilers for the Unix, Linux, PC and Macs in use in the dept.

Simple and working is often best.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

Seconded. And the legacy isn't necessarily just the source code. Many of the engineering industries using such codes have a relatively low turnover rate, meaning an older group of engineers and researchers with the most experience stick around for decades. Most of these folks used Fortran since college. It works for them, and they aren't concerned with any "new-fangled" languages that offer more features. Another reason I hear from these folks is that Fortran has powerful array slicing and indexing syntax not found in C, making big data manipulation simpler. Newer programming languages like Python have packages like NumPy which offer similar capabilities, but it's often a nightmare to translate hundreds of thousands of legacy code lines simply to "escape" Fortran. And there are decent bindings to Fortran that can be leveraged for many parallel computing packages (MPI), which means even less incentive to move up.

Newer folks entering the field often work under the tutelage or mentoring of these folks, and Fortran sticks around. Python is gaining usage in the scientific communities, and it's often coupled with mixed-language wrapping code like f2py or SWIG to access any legacy Fortran code for heavy number-crunching work. I've seen this recipe used successfully in parallel computing to detach some of the "administrative" aspects of scientific code into newer languages.

Weird

[Anonymous Coward]

They also use integrals and derivatives which first were used in the 17th century. Oh wait, that's OK! Software is mostly fashion these days.

It just works

[Anonymous Coward]

Fortran is the best at numbers, and not so good at other things (Try downloading a webpage with it, or even bind to Curl without the command prompt). The only language that can approach Fortran's niche is C, which is pretty good at everything, but you have to know a lot of programming tricks to get the same performance with numbers.

Why replace Fortran? I think it's great that a technology is still being used that spans back to vacuum tube machines and that those programmers' skills are not abandoned by industry (i.e. Visual Basic).

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[mbkennel]

A: Legacy code, and because Fortran 2003+ is a very good modern language for scientific computation and maps very naturally to problems. As it turns out, the language semantics (both legacy and modern constructs) make it very good to parallelize. And it runs fast, as in, equalling C++ level of performance is considered a weak showing.

If you haven't seen or used modern Fortran and think it's anything like Fortran 66/77 then you're mistaken. Except for I/O, which still tends to suck.

In addition there are still some seemingly trivial but actually important features which make it better than many alternatives (starting from Fortran 90).

There's some boneheaded clunkers in other languages which Fortran does right: obviously, built-in multi-dimensional arrays, AND, arrays whose indices can start at 0, 1 (or any other value) and of course know their size. Some algorithms are written (on paper) with 0-based indexing and others with 1-based and allowing either one to be expressed naturally lowers chance of bugs.

Another one is that Fortran distinguishes between dynamically allocatable, and pointers/references. The history of C has constrained/brain-damaged people to think that to get the first, you must necessarily take the second. That doesn't happen in Fortran, you have ALLOCATABLE arrays (or other things) for run-time allocation of storage, and if you need a pointer (rarer) you can get that too. And Fortran provides the "TARGET" attribute to indicate that something *may be pointed to/referenced*, and by default this is not allowed. No making pointers/references to things which aren't designed to be referred to multiple times. This also means that the aliasing potential is highly controlled & language semantics constructed to make Fortran able to make very aggressive, and safe, optimization assumptions.

The more parallel you want, the more of these assumptions you need to get fast code, and naturally written Fortran code comes this way out of the box than most other languages.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[the eric conspiracy]

Legacy code that has been carefully checked to give correct results under a wide range of conditions.

In other words...

[93 Escort Wagon]

If it ain't broke - don't fix it.

Re:In other words...

[ClickOnThis]

If it ain't broke - don't fix it.

If it's working, don't improve it?

Disclosure: IAAP, not a CS, although I have worked in the area of scientific computation for much of my career. I started with Fortran because my PhD supervisor was comfortable with it. But oh! how I wanted to escape from it. And I did, with much determination and self-directed study. So I come to bury Fortran, not to praise it.

Why do so many programming languages exist? Expressive power. They all have their strengths for solving certain kinds of problems. Many of them are good for solving scientific problems. Fortran is one of them, but IMHO it ceased to be the best choice long ago. Yet it persisted, because it was a practical choice. And that was a shame, because many new generations of scientific programmers did not get exposed to new languages with new expressive power (such as OO) that could solve new problems.

In short, we can do better with better tools. Imagine what would have happened to quantum mechanics if physicists had refused to learn about Hilbert spaces, or electromagnetism if they had refused to study vector algebra and multidimensional calculus. These fields might have progressed, but more slowly.

Re:In other words...

[tomhath]

If it ain't broke - don't fix it.

No, it goes beyond that. Scientific calculations are just that - calculations. You don't need services, facades, annotations, etc. that mostly obscure what the code is doing. You just need a sequence of calculations.

Re:In other words...

[petrus4]

And that was a shame, because many new generations of scientific programmers did not get exposed to new languages with new expressive power (such as OO) that could solve new problems.

I've only ever seen two groups of people, who advocated OO as some sort of inherent virtue in itself.

a} Psychopathic, buzzword-obsessed, clueless IT managers.

b} Elitist, equally clueless programmers, who mainly advocate OO and related languages, (such as C++) because they enjoy ego tripping about the fact that they can write code that nobody else is able to read, rather than actually getting real work done.

The main argument that both groups use to advocate OO, is the appeal to modernity fallacy. I.e., the idea that "modernity," is an inherent virtue, purely for its' own sake.

Re:In other words...

[Anonymous Coward]

I've also seen on the flip side far too much code written by people who don't know anything about OO, and essentially expose coupled APIs that abstract nothing but do use struct-filling as weakly-typed message passing.

Encapsulation is an end in itself, DRY is an end in itself, and where you have to build interoperating systems with teams that are already using an OO language, using those languages is the only real choice. But that implies objects and pure interfaces, and not the usual leakage of half-assed classes, (i.e. do not expose partial implementations, and "everything is not a class"). So there is a third way.

Re:In other words...

[ClickOnThis]

I've only ever seen two groups of people, who advocated OO as some sort of inherent virtue in itself.

a} Psychopathic, buzzword-obsessed, clueless IT managers.

b} Elitist, equally clueless programmers, who mainly advocate OO and related languages, (such as C++) because they enjoy ego tripping about the fact that they can write code that nobody else is able to read, rather than actually getting real work done.

The main argument that both groups use to advocate OO, is the appeal to modernity fallacy. I.e., the idea that "modernity," is an inherent virtue, purely for its' own sake.

So as far as you're concerned there are only two groups who see value in OO: detached managers who are too far away from the code, and immersed developers who are too close to it. Since you're so fond of logical fallacies, let me introduce you to the one you're committing.

You ignore the excluded middle: the overwhelming number of programmers who have solved new problems with object-oriented techniques. Of course, they could have solved these problems with older tools, but with greater effort. My point is that new programming practices would help scientific programmers as well. Yet many of them stick to Fortran, a language that has been consistently way behind the programming practices of the past four decades. As a result, they only see their problems in terms of formulas and arrays, and do not recognize the expressive power of newer languages.

I think this entire discussion suffers from survivor bias: those who advocate strongly for Fortran have not given serious consideration to anything else.

Re:In other words...

[petrus4]

> I think this entire discussion suffers from survivor bias: those who advocate strongly for Fortran have not given serious consideration to anything else.

I've just honestly never heard of OO being used anywhere, where it wasn't a crutch for bad programmers; with again, the appeal to modernity fallacy being used to justify it.

I consider computer programming in its' current form, to very largely be a field in serious decline, and ruled by baseless hubris, to be honest. That is also the reason why I'm so wary of the appeal to modernity. Most of the time in my observation, newer methods are actually markedly inferior to older ones, rather than an improvement.

I think a big part of the reason for this, is because the emphasis is constantly on reducing programmer effort. What nobody seems to remember, however, is that needing to apply effort, is how you become good at something.

So we now have spoon-fed, degenerate Millenials, awash in cheap CPU cycles and coding in C++. They don't need to learn efficiency; they don't need to learn how to do things truly well. The complexity of the software they write, also perpetuates their delusions that they are skilled at what they do; when the truth is the exact opposite.

not really

[Anonymous Coward]

I working in scientific computing and almost all new software is written in c++. Two huge parallel solver libraries petsc and trilinos are c and c++, ditto for many, many other codes. LAPACK is the one fortran code that you might find yourself using. There are legacy codes written in Fortran, but it's always a mistake to start something new in Fortran, particularly if you want your developers to be able to get jobs outside of science (when the funding goes south).

Key Reason

[stox]

Huge libraries of FORTRAN code have been formally proven. New FORTRAN code can be formally proven. Due the limitations of the language, it is possible to put the code through formal processes to prove the code is correct. In addition, again, as a benefit of those limitations, it is very easy to auto-parallelize FORTRAN code.

Re:Key Reason

[Anonymous Coward]

Define "formally proven". I have yet to see something involving floating point computation to be "formally provable", at least in the usual sense. One is usually concerned with error propagation, accuracy, and numerical stability, but "formal proofs" of numerical code? In a way possible in Fortran but not in C++? That would be a new one.

Workers still use shovels in 2014!!!!!

[TapeCutter]

Prospectors did not stop using shovels when bulldozers were invented. FORTRAN is the scientist's shovel, visualization software is the bulldozer.

A: Legacy code.

AKA battle hardened libraries that work as advertised.

Re:Workers still use shovels in 2014!!!!!

[Kaz Kylheku]

Fortran is a plastic shovel with a rolled up newspaper for a handle.

Re:Workers still use shovels in 2014!!!!!

[Vellmont]

Fortran isn't a shovel, and other languages aren't bulldozers. Fortran is like the first shovel ever invented, and other languages are improvements on that shovel.

Cobol was an early language as well, and nobody but a few dinosaurs program in it anymore. Why? Because they have to maintain legacy code.

Mostly the same reason with Fortran.

Re:Workers still use shovels in 2014!!!!!

[Anonymous Coward]

But fortran brand shovels have been improving over the years too!

Re:Workers still use shovels in 2014!!!!!

[DutchUncle]

A: Legacy code.

AKA battle hardened libraries that work as advertised.

This. ++. "Stable" does not mean "boring"; it means "reliable".

Re:Workers still use shovels in 2014!!!!!

[bytestorm]

Fortran is a Paper-Handled Plastic Shovel +4 of SCIENCE, forged in the early days when the world was young upon the ancient IBM 704. A keen observer might still find where John Backus himself scrawled "F*@# ASM!" in the crossword puzzle, its margins filled with arcane formulae from which the secrets of missile guidance emerged. It has fought and won many battles as an agent of the Holy Maths against the forces of nature, problems inscrutable, and libelous apocrypha. In its wake are the algorithms and research papers which lay the foundations of our modern tools, many of which are still used behind the scenes today. It is a thing of great purity, not tainted by the crude indelicacies of ui design or text processing; these tasks it leaves to other tools. Numbers go in, solutions come out, transformed by algorithms proven true over so many years.

Do not so lightly cast aside a tool which has proven its worth many times over.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Jeremiah Cornelius]

Why?

Not to put too fine a point on the matter, Fortran is still used to bust the n00bs.

It's academia, for God's sake! This is where Doctorae Philosophiae held forth discourse in Latin, as recently as 150 years ago, fully 1600 years after that language fell into conversational extinction.

I never thought about engineering and Fortran

[93 Escort Wagon]

Large scale models handling huge arrays, though - like climate or weather modeling - I think that's where Fortran has always been king of the roost.

The whole point is speed. No one's working in Python if they're interested in speed.

Re:I never thought about engineering and Fortran

[Darinbob]

My guess is that python is being used mostly to handle data rather than crunching numbers. As in read those three files that came in from the satellite, merge them, strip out the irrelevant stuff, shove it back out as a packed binary file ready for processing.

Re:I never thought about engineering and Fortran

[Redeye Carci]

Python is used to glue all the lower level stuff together. If you are iterating over large arrays in python you are doing something wrong, but if you are using python to glue C/Fortran molecules together then it starts to look much better.

Re:I never thought about engineering and Fortran

[majid_aldo]

by carefully constructing python statements and calling libraries you can get the speed you want from a 'python' program. if you can fit your problem in this way, then yea it makes sense to go to fortran or C.

Re:I never thought about engineering and Fortran

[blueg3]

Python is also extremely popular in scientific computing, particularly if you're doing data analysis. It's a better, free replacement for Matlab. All of the real, serious computational work is done by calling native libraries, naturally.

Serious scientific computation, particularly libraries and important models, are still frequently in Fortran, though I've seen a lot in C and C++ too.

Re:I never thought about engineering and Fortran

[camperdave]

I thought huge arrays of massively parallel computation were done on GPUs these days.

Re:I never thought about engineering and Fortran

[Anonymous Coward]

climate or weather modeling - that's where Fortran has always been king of the roost.

I am a scientist using massively parallel code. Climate modeling code is considered a joke in our field. The go-to example of a subfield that has no clue what they're doing programming-wise and only gets resources because they're the only code in town.

Re:I never thought about engineering and Fortran

[Anonymous Coward]

The whole point is speed. No one's working in Python if they're interested in speed.

Scientists who use Python generally use SciPy, which is a collection of fast and reliable libraries (many of which are actually compiled Fortran) glued onto Python.

Native Python code is something like 50x slower than C or Fortran. But if all you are using it for is to glue together calls to libraries, and then plot the results (using a plotting library), then the slowness of Python is not a significant factor.

So you can work in Fortran and get the wonderful, reliable, fast Fortran libraries; or you can work in Python and get those same libraries, with the convenience of an interpreted language that offers interactive graphing and a bunch of other useful stuff.

When scientists move from an older language to a newer one, the newer one almost always is Python.

Guido van Rossum, when he created the first Python, made a conscious decision to make it interface well with compiled libraries. History has shown that this was a really, really good idea.

Re:I never thought about engineering and Fortran

[Rostin]

I am not a software engineer, so my speculations here should be taken with an extra grain of salt. With that disclaimer out of the way, my understanding is that Fortran is falling out of favor mostly because scientific and engineering software is growing more complex. At the same time, we are depending more on its reliability, and it is being more widely used by people other than the researchers who developed it. Language features like classes and templates that make developing complicated, reusable, and maintainable code more tractable are baked right into C++. Fortran has some of these kinds of features, but they are almost an afterthought, and I've never actually seen an object oriented Fortran code in the wild. The main things Fortran has going for it, like native vector and matrix operations, complex numbers, and (arguably) greater speed, are no longer enough of a selling point.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

This may be especially important if the testing method is ISO acredited. Getting a new test accredited may just not be worth the hassle, so if it ain't broke...

I call BS

[Anonymous Coward]

Sorry folks, I've spent a lot of time in HPC environments and I just don't see Fortran being the GOTO language any more. The differences that use to allow Fortran to be better compiled are fading away, the only thing hiding this fact is the bloated uber-templated unintelligible over-abstracted C++ doesn't necessarily compile well. Take a modern compiler, write code that is numeric heavy in Fortran and C -- then actually look at what ends up being created and there isn't a hill of beans difference, most of the instructions are in COMMON. WHILE Fortran used to be easier to compile, that is nearing its END. DO you not think so?

It's all about math, stupid

[Anonymous Coward]

FORTRAN is all about math. Math functions are trivially easy to define because the language was built do deal with math functions.

Also, there is an enormous library of established, proven, dependable libraries for the most important math functions in most industries. LINPACK, LAPACK, etc..

Doing math in C/C++ or whatever other language - you just never know what results you're going to get.

Re:It's all about math, stupid

[Anonymous Coward]

Doing math in C/C++ or whatever other language - you just never know what results you're going to get.

I have used C for doing math for the past 25 years. I have never had a problem.

Re:It's all about math, stupid

[Anonymous Coward]

Remind me to never hire you as a C/C++ or whatever other language programmer. Floating point operations have known margins of error that should be well below the margin of error in your science or engineering. No language is safe from the limits of processors either, without inventing new, slower data types (e.g. bc).

not in the field, eh?

[rubycodez]

no, used because Fortran is the high level language that produces the fastest code for numeric computation, it is by far the most optimizable. Yes, it blows away C.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Bing Tsher E]

Precision is important in scientific discourse. Latin isn't a language with creeping grammar and jargon. It's sorta what Esperanto only wished it could ever be.

yes really

[rubycodez]

haha, maybe you better look at what language huge parts of the cores of your petc and trillinos are written in. hint, starts with an F

Re:yes really

[smoothnorman]

yep. along with all the rest of the BLAS, EISPACK, CERNLAB, MINPACK, SOFA, ATLAS, EIGEN, ... and even the comparatively more recent Bioinformatics cores.. BLAST, BLAT, ...

I really don't understand the "scientific computing .. almost all new software is written in C++" comes from. It's all become Python (and Perl before that) calling old libraries at the scientific meetings i've attended. (but i suppose YMMV)

Re:yes really

[raxx7]

ATLAS is mostly written in C with a ton of compiler SIMD intrinsics.
It provides a Fortran BLAS and partial LAPACK interface, along with a C BLAS interface.

As you said, YMMV.
From your description, it seems that in your field you spent most of your CPU time performing a relatively small number of large and time consuming operations on matrices. This can be efficiently handled by an interpreted language (Python, MATLAB, etc) with an efficient underlying implementation of matrix operations.
Some of those implementations have a very long history and they're written in Fortran, with C interfaces available (which is how they're built into Python and Matlab).
And there isn't any kind of pressing need to re-write them into C or whatever.

Other areas have different profiles.
Particle physics is completely different. Most of the CPU time is spend a very large number of tiny operations, comparisons and branching.
Such code needs to be written in a compiled language, like Fortran or C/C++.
And the choice nowadays for new code is, by far, C/C++. They even rewrote their main simulation package (GEANT) from Fortran to C++. I think they really felt the need of OOP to handle complex models.

More generally, most _new_ critical loop parts are written in C/C++, albeit with the possible usage of old Fortran libraries in the cases they exist.
And non critical loop parts are often written in Python or etc.

Re:yes really

[K. S. Kyosuke]

"Trilinos packages are primarily written in C++, but provide some C and Fortran user interface support."

C++ doesn't seem to start with F, now does it? Also, the Trilinos page mentions support for AD, which is apparently a major performance (and accuracy) feature for them. Given that (to my knowledge, at least) AD is unsupported out of the box in both Fortran and C++ compilers and that their own AD package Sacado uses C++, it appears that even if they're using Fortran libraries like BLAS etc. for convenience, they're providing you a C++ transmunger expecting you to write application specific code (involving derivatives to be fed into solvers) in C++. That's seems like a huge smell of using Fortran for legacy reasons.

Re:yes really

[Anonymous Coward]

I feel sorry for the developers of BLAST and BLAT.

Re:yes really

[the gnat]

even the comparatively more recent Bioinformatics cores.. BLAST

BLAST was never Fortran; the current version is C++, the original was C. More generally, very few bioinformatics programs that I'm aware of were written in Fortran.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[tlambert]

A: Legacy code.

Most people who learned FORTRAN did so in a class intended to teach FORTRAN.

Most people these days aren't learning FORTRAN, they're learning other languages, and they're doing them in a context that teaches them about apply the tool, rather than making them really, really good with the tool itself.

To use an analogy, it's the difference between learning how to use all the tools in the wood shop before being sent in to make a chair (learn the tools) vs. being taught all about "chairness", and then being sent in to make a chair, without a great knowledge of the tools themselves. Someone is going to lose a finger, in the second case.

So it might be "legacy", but the legacy they want is the teaching methods which were in use when most of the FORTRAN programmers came into existence in the first place.

We're Not

[friedmud]

I saw this link bait the other day...

We're NOT using Fortran anymore...

Many of us at the National Labs do modern, object-oriented C/C++... Like the project I'm in charge of: http://www.mooseframework.org/

There are whole labs that have completely expunged Fortran in favor of C++... Like Sandia (http://trilinos.sandia.gov) who actually went through a period in the late 90s and early 2000s where they systematically replaced all of their largest Fortan computational science codes with C++.

Those places that don't use C++ use C like the awesome PETSc library from Argonne ( http://www.mcs.anl.gov/petsc/ ) which actually employs an object-oriented scheme in C.

The big name modern codes that are getting run on the biggest machines are generally done in C and C++.

I don't see that situation changing anytime soon as there is simply a massive amount of C and C++ libraries that will continue to provide the engine for tomorrows codes. The trend i see happening most often is utilizing C and C++ libraries with Python glue for everything doesn't need raw speed.... I think that trend will continue.

Re:We're Not

[Anonymous Coward]

If you're using C++ for scientific math, then you deserve to have whatever credentials you may possess to be revoked immediately. No language should be used for scientific math that can produce different results based upon the version of library or platform it is compiled against.

You also cannot prove C++ code is good. You just can't. C++ is not deterministic, again, because the outcome depends on platform/library versions, compiler options, time of day, alignment of the planets, and many other factors. There is no way to say for certain that "Yes, this code will produce the correct results under all conditions."

The big name modern codes that are getting run on the biggest machines are generally done in C and C++ and producing incorrect results.

I have PoC code that I have used to prove that C++ can produce incorrect results based on factors other than the code itself, and at the level of significance as high as 10^-15. That is a completely unacceptable level of inaccuracy for scientific exploration.

Re:We're Not

[friedmud]

Firstly... 10^-15 is WAY beyond what most scientific codes care about. Most nonlinear finite-element codes generally shoot for convergence tolerances between 1e-5 and 1e-8. Most of the problems are just too hard (read: incredibly nonlinear) to solve to anything beyond that. Further, 1e-8 is generally WAY beyond the physical engineering parameters for the problem. Beyond that level we either can't measure the inputs, have uncertainty about material properties, can't perfectly represent the geometry, have discretization error etc., etc. Who cares if you can reproduce the exact same numbers down to 1e-15 when your inputs have uncertainty above 1e-3??

Secondly... lots of the best computational scientists in the world would disagree:

http://www.openfoam.org/docs/u...
http://libmesh.sourceforge.net...
http://www.dealii.org/
http://eigen.tuxfamily.org/ind...
http://trilinos.sandia.gov/

I could go on... but you're just VERY wrong... and there's no reason to spend more time on you...

Re:We're Not

[Dizzer]

If you get hung up on floating point truncation errors, then I have bad news for you: Fortran won't protect you from that. You seem to be under the delusion impression that this invalidates the results for some reason. This is utter bullshit. One example are molecular dynamic simulations. An MD simulation is a chaotic system. The _exact_ trajectory is not the relevant result. The phase space that is sampled is. Trajectories of systems with identical initial conditions are bound to diverge on different machines due to a change in floating point operation order and the resulting truncation errors. But the phase space that is sample is _equivalent_ in each run. If for some reason machine precision is important to you you'd be much better off by using a library such as GMP (https://gmplib.org/).

Re:We're Not

[Anonymous Coward]

the project I'm in charge of: http://www.mooseframework.org/ [mooseframework.org]

Thanks for wasting my tax dollars you unproductive asshole.

Re:We're Not

[friedmud]

Interesting... I'm not sure what's unproductive about producing a freely available scientific engineering platform that is directly impacting the energy generation issues in this country.

But, ok :-)

Re: We're Not

[wispoftow]

You're right Fortran won't protect you from ~inconsistent~ round off errors, but the lower performance IEEE data types that Fortran (natively) and a few other languages implement through heavy add-ons will.

May I suggest that you consider applications in domains outside of your own. If you have any interest in computer forensics, e.g. why did the ODE screw up and crash the lander, why did the airplane software malfunction, nuclear reactor meltdown, etc. etc. then you might start to care much more deeply about being able to reproduce the precise values that existed during the course of the evaluation. (As well as consistently handling the numerical exceptions that tend to arise. I'm no expert in IEEE, please consult a reference.)

In your own domain -- Molecular Dynamics -- you might wish to send your initial configuration (position and velocities) to a colleague/reviewer who is using a different compiler. He could, in principle, reproduce your trajectory exactly. (Otherwise, there is a compiler error.)

You might not wish to routinely run with IEEE arithmetic, because it is slower. But for those folks who need it, it is right there at their fingertips and totally and completely (ANSI/ISO) standard.

Re:We're Not

[Anonymous Coward]

If you're using C++ for scientific math, then you deserve to have whatever credentials you may possess to be revoked immediately. No language should be used for scientific math that can produce different results based upon the version of library or platform it is compiled against.

Oh, go away. C and C++ are fine for scientific math.

I have PoC code that I have used to prove that C++ can produce incorrect results based on factors other than the code itself, and at the level of significance as high as 10^-15. That is a completely unacceptable level of inaccuracy for scientific exploration.

I don't belive you.

Re:We're Not

[Roger W Moore]

If you're using C++ for scientific math, then you deserve to have whatever credentials you may possess to be revoked immediately.

Really? Well I'm guessing that's it for the entire field of particle physics then.

I have PoC code that I have used to prove that C++ can produce incorrect results based on factors other than the code itself, and at the level of significance as high as 10^-15. That is a completely unacceptable level of inaccuracy for scientific exploration.

...and yet we found the Higgs with such code...or do you think it was just a rounding error in ROOT?

Re:We're Not

[Anonymous Coward]

Most of the professional codes try to use iterative approaches to solve their equations, so that numerical inaccuracies at this level don't play a role.
The accuracy game was even much worse a decade ago, where everyone still used the x87 floating point unit.
If the number remained in a cpu-register instead in memory, it was saved with 80 bit (long double) accuracy instead of 64 (double) bit or 32 bit (float). That lead to the effect, that optimized code was more accurate than non-optimized.
This had nothing to do with the programming language.

Re:We're Not

[BradMajors]

No. Your code produces incorrect results because it has bugs. Learn to debug your code or stick to FORTRAN.

Re:We're Not

[K. S. Kyosuke]

No language should be used for scientific math that can produce different results based upon the version of library or platform it is compiled against.

I'm not aware of any language that can give you an assurance of identical results on all platforms while still using the platform's native resources (FP hardware and basic libraries). In fact, if you're relying on something like this for your calculations, it probably raises a question of how robust those calculations are with regards to variations around 1 ULP (for example, whenever transcendental functions are involved, due to some deep math problems in their calculation). At least I was taught that begging for the results to be identical is a desperation move for the numerically inept programmer.

Re: We're Not

[Anonymous Coward]

the lower performance IEEE data types that Fortran (natively) and a few other languages implement through heavy add-ons will

What are these "lower performance IEEE data types" and how do they protect you from, say, the table-maker's dilemma?

You might not wish to routinely run with IEEE arithmetic, because it is slower. But for those folks who need it, it is right there at their fingertips and totally and completely (ANSI/ISO) standard.

I'm no expert at IEEE 754 either but I recall that it doesn't prescribe how all useful operations are to be performed. What you are describing would seem to mandate precisely that. And I'd assume that the forensics in question is usually performed by using identical SW, and either by using either identical HW or a functional emulator of the hardware, one yielding identical results.

Re:We're Not

[amaurea]

What array libraries do you recommend for numerical programing in C++? I'm used to fortran and numpy arrays, which are very similar. Something that allows convenient slicing of multidimensional arrays, and is as fast as fortran arrays, would be really nice to know about.

Re:We're Not

[Anonymous Coward]

Arent the flagship PETSc applications (e.g., FUN3D during the days of PETSc 2.X and PFLOTRAN during PETSc 3.X) which PETSc authors always list in their slides (showing massive scalability) written exclusively in Fortran?

Btw C++ is also pretty much absent from Climate models where Fortran is almost exclusively used. There are many examples in CFD (my area) as well.

Re:We're Not

[Anonymous Coward]

Your response is awesome and I'm not the AC from above (and frankly I think this whole debate is dumb -- unless your CPU has developed a personality then who is going to complain what language you compile things in?), but OpenFOAM is your top example? Ugg... I would not list that after "lots of the best computational scientists in the world"... I've been doing advanced CFD development for decades, and no one I know touches OpenFOAM.

Re:We're Not

[Anonymous Coward]

Scientist != Programmer/Developer

Re: We're Not

[inflamed]

In your own domain -- Molecular Dynamics -- you might wish to send your initial configuration (position and velocities) to a colleague/reviewer who is using a different compiler. He could, in principle, reproduce your trajectory exactly. (Otherwise, there is a compiler error.)

You might not wish to routinely run with IEEE arithmetic, because it is slower. But for those folks who need it, it is right there at their fingertips and totally and completely (ANSI/ISO) standard.

The position and velocities or seed value will allow for reproduction of trajectories up to a certain point. Accumulation-derived errors take quite some time to develop and are acceptable. This is why relatively lossy GPU hybrid single-precision / double precision accumulation codes for CUDA are acceptable (and a game changer). Over an extended time the simulation will sample the same phase space. If the same phase space isn't sampled the simulation isn't run long enough or the model is bunk :-)

Re: We're Not

[Dizzer]

Apart from what has been said before about this subject by the other commenters, I'd like to stress that you seem to lack the physics understanding to appreciate what the significance of rounding errors is. If you system is unstable enough to have rounding error affect the outcome you need to do uncertainty quantification anyways! In particular a sensitivity analysis of the input data (which is rarely known with precision anywhere comparable to the machine precision) is necessary. Reproducibility does _not_ imply reproducibility of exact trajectories, it means reproducibility of relevant observables.

My colleague/reviewer could not care less about exact trajectories. Do you think trajectories get published? Do you think full trajectories are even stored to disk most of the time?! If the conclusion of your paper hinges on an exact trajectory it should not be published at all. Hell, you shouldn't be doing science if you think that is how it works.

Re: We're Not

[wispoftow]

First of all, please note that I said ~exact~ reproduction. You keep going back to some ensemble average as being "good enough." Secondly, what you are saying about the scientific topic is inconsistent with numerical analysis of MD simulations using e.g., the velocity Verlet algorithm.

Please see: http://chris.sweet.name/docs/s... for an example of floating point error in action (special attention to the single vs. double precision differences that appear once the simulation has run a long time.) One of the early criticisms of GROMACS (the fastest MD!) was that it ran really great in single precision. But everyone else (AMBER, CHARM, and homegrown codes) were criticizing it for floating point round-off error leading to trajectories that flew apart because they developed too much momentum.

These don't "appear" if you have slapped a thermostat on the simulation (NVT ensemble). This is why you should always run an equilibration run and then switch to constant energy (NVE ensemble) when you are generating results that you wish to report. Otherwise, you are sweeping all sorts of problems due to floating point arithmetic and integration error under the rug.

But I suppose that you are doing classical MD -- trying to draw some inference on e.g. protein dynamics based on interactions between van der Waals spheres. These simulations tend to be "right" half of the time -- they are wrong until you've cooked the force field enough to match the definitive experiment. Constraints go a long way in keeping the system together.

So, in this environment, where the primary interest is generating "ooh's and ahh's" from movies of dancing proteins as quickly as possible, you are probably safe using single point arithmetic and hiding all of your sins with a nice, strongly coupled thermostat and barostat.

Re: We're Not

[wispoftow]

What you say is inconsistent with decades of work of my colleagues on the subject, and my own observations. (I have a few dozen papers in JACS and J Phys Chem)

a) The problem is that seemingly "stable" systems develop instability over time due to integration and floating point error. You mention chaos, and this is it -- sensitivity to minute change in initial conditions and accumulated tiny effects. But it's not randomness -- this chaos could be reproduced using well-defined arithmetic.
b) people do publish trajectories in supporting information or on their web sites, perhaps only snapshots, but how would you ever get from snapshot to snapshot to prove that you had implemented their methodology correctly, or to demonstrate the reproduction of a phenomenon: perhaps interesting, perhaps evolution to a corner case thus demonstrating a theoretical/methodological error? If you are working on different processors/compilers, it's almost impossible to reproduce.

I agree that people tend not to do IEEE arithmetic with classical MD. Please go back a comment or two and read it this time to confirm it for yourself. I was trying to give an example of a case where exactly reproducible results could be useful in the field of MD, particularly in development.

I remain convinced that IEEE arithmetic is useful in many important (but perhaps comparatively rare) circumstances, and that FP error will always be a lingering issue that rears its ugly head. Fortran implements ways of dealing with it consistently.

Re:We're Not

[Anonymous Coward]

I have heard that machine precision is very important for climate models. Some universities keep old hardware around for that to allow to model to be run again as verification. Some paper published that adding 10e-15 once to the result of one calculation in a certain model resulted in earth getting a climate like venus.

Re:We're Not

[Anonymous Coward]

I think he is saying that the same exact code, running on the same exact machine can produce floating point truncation errors if given different C++ compiler options. Here it is the compiler options that are producing the issue, not the underlying machine configuration.

That is much, much different (and worse) than running the same code on different machines and not expecting floating point errors.

I have not seen the grandfather's proof-of-concept code; it would be interesting to see if that is indeed the case.

Re: We're Not

[Dizzer]

A specific trajectory can serve as an example, but the exact trajectory itself is not a meaningful observable. I suggest you go back and take a look a previous posts that mention uncertainties in the initial conditions being overwhelmingly larger than truncation errors. Add to this a thermostat if you will.

Even with a fully IEEE compliant floating point implementation (which by the way is the CPU's business - why are we even talking about this here?) operation order will determine how the truncation error is propagated. Results are still deterministic on the same hardware with the same optimization and the same parallelization. But this is mainly of importance for code debugging. There is no physics based reason for insisting that a truncation error should always be the same.

Furthermore I don't buy it. I'm calling bullshit on you. You have yet to divulge what these magic "lower performance IEEE data types are". Are you talking about longer types? That will not protect you from truncation errors and will do NOTHING to make them more "consistent" either. To me it frankly sounds like you are set in your old fortran ways and are just trying to rationalize sticking to an outdated language.

Re:We're not

[Anonymous Coward]

Just the standard slashdot aspie libertarian

Re:We're Not

[Anonymous Coward]

... and in your entire post I didn't see you mention a single good reason WHY you "expunged" all the Fortran other than "The big name modern codes (sic) that are getting run on the biggest machines are generally done in C and C++". Yet TFA pointed out that Fortran was still highly popular in supercomputing and STEM. Did you have a bunch of taxpayer dollars you needed to spend?

Re: We're Not

[wispoftow]

Please, go back and look at my previous comments. I said "consistent" and not "exact". Now, you have called "bullshit" on me, and so it's time to go to source to back up what I have said. I choose "Modern Fortran Explained" by Metcalf, Reid, and Cohen, specifically Chapter 11 which covers the Fortran implementation of IEEE 754-1985 and IEC (ISO) 559. These guys are associated with the likes CERN and NAG.

IEEE arithmetic has ~nothing~ to do with Fortran per se (see my comment above) -- the Fortran standard demands its implementation. You accusing Fortran users of "being stuck in its ways" is blatantly stupid -- as any language that implements IEEE is guilty of the same crime. A "type" is more than its storage -- a type is the union of its storage with its operators. In Fortran, (to the best of my knowledge) using IEEE arithmetic alters these operators, including essentials like +-*/ and including essentials like sqrt. (Aside: Note that GROMACS started life being a fast enough, precise enough, sqrt operator project due to its role in computing Euclidean distance. In my experience, it did not work out so well, unless a thermostat kept bleeding out the aberrant velocity build up.)

Since the FP types use finite width, no doubt there are still FP errors, as this is not exact arithmetic. Fortran does not fix this, and I never said it did. Again, I said IEEE, which Fortran implements, makes it "consistent."

Different CPUs have different performance characteristics for various operations. Where there is a preferred/faster order of operations, then the compiler can reorganize so that things run faster. This can be good and/or bad. From Metcalf, "Some computers perform division by inverting the denominator and then multiplying by the numerator. The additional round-off that this involves means that such an implementation does not conform with the IEEE standard."

My thoughts above were about ~different types~ of machines doing billions of operations in whichever way they please, thus leading to different results in long running simulations. It is possible to demand IEEE arithmetic and exception handling, in which case "Execution may be slowed on some processors by the support of some features."

Now, let's talk about your fuzzy thinking. You said "There is no physics based reason for insisting that a truncation error should always be the same": do you expect bitwise arithmetic to be different, provided that the same sequence of instructions with the same starting values? You also think/thought that scientists don't post their trajectories or snapshots. I'm actually starting to wonder about you.

This subthread had little to do with Fortran, except as an innocent bystander that has IEEE support. This had to do with the suggestion of the usefulness of consistent orders of operations that can lead to consistent results between different types of machines.

Re: We're Not

[Dizzer]

IEEE arithmetic has ~nothing~ to do with Fortran per se (see my comment above) -- the Fortran standard demands its implementation.

Correct. And it is also correct, that the C++ standard does not demand IEEE 754 compliance. There are hardware requirements (i.e. CPU/FPU support) for this. Requireing these would exclude a whole bunch of embedded systems for example.

Fact is that the hardware you will run on is very likely to support IEEE 754.

a type is the union of its storage with its operators. In Fortran, (to the best of my knowledge) using IEEE arithmetic alters these operators,

Huh? Fortran rewires my CPU?!

Different CPUs have different performance characteristics for various operations. Where there is a preferred/faster order of operations, then the compiler can reorganize so that things run faster.

IEEE 754 defines a set of basic operations. What it does not define are rules for the compiler how it must or must not order these operations!
Bear in mind that this goes beyond simple reordering of terms in one calculation. The order can be impacted by MPI communications for example. IEEE 754 says nothing about this, and neither does the Fortran standard.

do you expect bitwise arithmetic to be different, provided that the same sequence of instructions with the same starting values?

Of course not, because the sequence of operations is not the same on different systems and parallelization topologies.

You also think/thought that scientists don't post their trajectories or snapshots.

Nonsense. Maybe you will learn through repetition: Exact trajectories are almost never a relevant physical observable. Read the stuff about uncertainties in initial conditions again please.

The problem you believe Fortran can help you with is not a problem, and furthermore Fortran cannot help you with it anyways. Sorry, man.

Re: We're Not

[wispoftow]

You keep trying to convince me that Fortran is not a panacea like I might actually believe that it is. I have confirmed that you are trolling.

If one sets a random seed from a reproducible generator, then start a swarm of trajectories sampled from a Maxwell distribution of velocities, then one should be able to get the exact same computer renditions of those trajectories on any computer that implements IEEE arithmetic. These are computationally deterministic simulations. This is reproducible research.

Or maybe you are invoking quantum mechanical uncertainty for a classical mechanics simulations. Even quantum mechanical simulations that start with the same wave packet (x and p) can be reproduced faithfully if the initial conditions are known, and the order of operations is the same.This discussion has nothing to do with ensemble averages or quantum mechanical and

.

Compilers most certainly can dictate the order of operations of a CPU -- that's the whole point. Whether this is most efficient for a given architecture is another matter, and one reason why performance can drop if the CPU is ordered to perform its instructions in a suboptimal manner.

Finally, I agree with you that MPI has nothing to do with IEEE arithmetic, and I really don't know why you have brought this up.

(I regret that I must refrain from further discussion on this topic. Ummm... you win.)

Re: We're Not

[Dizzer]

If one sets a random seed from a reproducible generator, then start a swarm of trajectories sampled from a Maxwell distribution of velocities, then one should be able to get the exact same computer renditions of those trajectories on any computer that implements IEEE arithmetic.

No, god damn it!!! How the hell to you do computational research? On a single CPU?! You are either totally thick, or the troll in this discussion.

Or maybe you are invoking quantum mechanical uncertainty for a classical mechanics simulations.

I'm invoking order of operations. Why is that so hard to understand?!

Postscript

[sk999]

Today someone told me about how he once wasn't allowed to disturb a printer - because someone was using it to run a job doing an FFT written in Postscript. Apparently the large amount of memory available in the printer was paramount.

Re:Postscript

[50000BTU_barbecue]

Geez, was this Don Lancaster's printer? It makes sense though, Postscript has to do a lot of math.

http://www.tinaja.com/post01.s...

Why is anyone still using C++ in 2014?

[thisisauniqueid]

Forget Fortran, I want to know why anybody in their right mind is still using the obtuse juggernaut mongrel of a language known as C++ in 2014. (Even with the 11 and 14 versions don't make things any better, they only wallpaper over obtuse features with other obtuse features... very few people alive truly know all the weird quirks of C++ inside and out.)

Re:Why is anyone still using C++ in 2014?

[friedmud]

Not everyone needs to know all of the quirks of C++ to use it. My project ( http://mooseframework.org/ ) does all of the nasty C++ stuff under the hood so that we can expose a very straightforward interface to non-computer-scientists.

It's working out well so far.

Object-oriented is still a good paradigm until the functional language people get everything figured out and there are enough computational science libraries written in functional languages. And if you want to do object-oriented and you still want to be fairly close to the metal for performance reasons then C++ is a good choice.

There are people that do object-oriented with C like the PETSc team ( http://www.mcs.anl.gov/petsc/ )... and they have good reasons for doing so... but the result isn't necessarily less imposing to the uninitiated than C++...

Re:Why is anyone still using C++ in 2014?

[DMUTPeregrine]

Well, as the old joke goes, everyone knows 30% of C++.
They just all know a different 30%.

Re:Why is anyone still using C++ in 2014?

[Brett Buck]

I have been writing and reviewing various forms of scientific and embedded processor code for, well, a damn long time. I have seen A LOT of crap spaghetti code. All the very worst examples were C++.

Re:Why is anyone still using C++ in 2014?

[Desler]

Because it's a perfectly fine language for people who care more about writing complex and efficient software than appearing hip to the brogrammer crowd.

Re:Why is anyone still using C++ in 2014?

[Anonymous Coward]

And I've seen lots of code in various langauges and the C and C++ code is usually among the best. Maybe you should work with less shitty programmers. In my experience it's the hipsters and brogrammers that use all the fad shit that seem to make the shittiest and most incomprehensible code.

Re:Why is anyone still using C++ in 2014?

[Dutch Gun]

Forget Fortran, I want to know why anybody in their right mind is still using the obtuse juggernaut mongrel of a language known as C++ in 2014. (Even with the 11 and 14 versions don't make things any better, they only wallpaper over obtuse features with other obtuse features... very few people alive truly know all the weird quirks of C++ inside and out.)

// Project sanity check
ProjectCriteria projCrit;
projCrit.requireEfficientRuntime = true;
projCrit.requireEfficientMemoryUse = true;
projCrit.requireEfficientNativeLibInterop = true;
projCrit.legacyProjectInterop = true;
projCrit.buzzwordCompliant = false;
auto langChoice = languageCollection.find(projCrit);
if (langChoice != Language.Cpp) {
        string s = "It appears C++ may not the be appropriate language for your project. Have you considered ";
        DisplayMessage(s + langChoice.name + " instead?");
        return;
}

langChoice.doActualWork();

Re:Why is anyone still using C++ in 2014?

[shutdown -p now]

Because there's no language that does everything that C++ does just as well.

Re:Why is anyone still using C++ in 2014?

[jbo5112]

I use it because it because I can get it to run a very significant amount faster with 10% of the memory footprint of Java. Java, in addition to going through a slow, buggy, insecure vm, doesn't let me do the same optimizations, and consequently, the resulting Java code would take at least 3x as long to run (python is probably worse).

My C++ source code generally ends up smaller too, especially when I have to interface with a database. JDBC is an awful mess compared to OTL. My code is bug free enough that my problems are are almost entirely limited to C++ tweaks (in my personal libraries) that I can't do in safer languages or using bad algorithms, which tend to come from business requirements (or misunderstanding thereof).

I'm sorry you consider lambda (anonymous) functions and expressions, range based loops, standardized multi-threading, regular expressions, smart pointers, and type inference to be obtuse. Your programming world must be small or you just really hate C++. If you know of something better, where I won't take a meaningful speed hit, then let me know.

Re:Why is anyone still using C++ in 2014?

[tmarthal]

I think the idea is "Why C++?" - you can write all of the numerical crunching routines in Fortran and continue to use Python to wrap them all together. In fact, you probably didn't have to rewrite any of the Fortran code into C++ at all.

You already seem to use Python, so the question is why is there a C++ middle layer?

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

Latin was the one language that all academics shared. To them, it was a convenience. The dominance of English in international communication is a very recent phenomenon...

As a Social Science Ph.d.

[robbiedo]

I am sticking with Visual Basic 6

Re:As a Social Science Ph.d.

[Anonymous Coward]

VB6 makes it too easy.
Real programmers use FORTRAN and produce big stacks of punch cards!

Re:As a Social Science Ph.d.

[AchilleTalon]

Funny!

Re:As a Social Science Ph.d.

[InfoJunkie777]

OP here. Give this man some mod points for FUNNY!

Because C and C++ multidimensional arrays suck

[Animats]

A big problem is that C and C++ don't have real multidimensional arrays. There are arrays of arrays, and fixed-sized multidimensional arrays, but not general multidimensional arrays.

FORTRAN was designed from the beginning to support multidimensional arrays efficiently. They can be declared, passed to subroutines, and iterated over efficiently along any axis. The compilers know a lot about the properties of arrays, allowing efficient vectorization, parallization, and subscript optimization.

C people do not get this. There have been a few attempts to bolt multidimensional arrays as parameters or local variables onto C, (mostly in C99) but they were incompatible with C++, Microsoft refused to implement them, and they're deprecated in the latest revision of C.

Go isn't any better. I spent some time trying to convince the Go crowd to support multdimensional arrays properly. But the idea got talked to death and lost under a pile of little-used nice features.

Re:Because C and C++ multidimensional arrays suck

[friedmud]

Easily fixed with libraries like Eigen ( http://eigen.tuxfamily.org/ind... ) and many others.

Most of the better "frameworks" out there come with their own proxy objects for multidemensional arrays (like http://libmesh.sourceforge.net... )

Multidmensional arrays haven't been an issue (especially in C++) for quite a long time...

Re:Because C and C++ multidimensional arrays suck

[Dizzer]

All the built-in array people are essentially obsessing over a micro-optimization. First of all I would argue that in a scientific research environment development time is a far more important factor than execution time. And having a framework with a clean outward facing interface for reusers makes a huge difference. Clean, well designed object oriented code also encourages contributions and allows you code to flourish, which reduces the pressure for people to invent their own wheels (again saving developer time). Secondly, the more substantial optimizations come from choosing the appropriate algorithms. Why worry about a 5% speed-up, when choosing the right preconditioner can give you a 10fold speed-up. As an aside, why worry about even a 20% slow down if you have a scalable parallel implementation that you can just throw a few more cores at. Profile before you optimize, and profile _economically_, too!!!!

Re:Because C and C++ multidimensional arrays suck

[Animats]

Easily fixed with libraries like Eigen ( http://eigen.tuxfamily.org/ind... ) and many others.

That's the problem. There's no one way to represent a multidimensional array in C++. There are many ways. Which means math libraries using different ones are incompatible with each other. The last time I did a big number-crunching job in C++, I had four different array representations forced on me by different libraries.

Because the compiler has no clue what those array libraries are doing, you don't get basic loop optimizations that FORTRAN has had for 50 years.

Re:Because C and C++ multidimensional arrays suck

[Anonymous Coward]

Both of the examples libraries that you list are useful only for N-dimensional arrays where N=2.
Real scientific programming can and does involve arrays of higher dimensionality.

Re:Because C and C++ multidimensional arrays suck

[flargleblarg]

A big problem is that C and C++ don't have real multidimensional arrays.

I don't think that's a big problem.

There are arrays of arrays, and fixed-sized multidimensional arrays, but not general multidimensional arrays.

General multidimensional arrays are trivial to implment in both C and C++, due to the syntax of [].

FORTRAN was designed from the beginning to support multidimensional arrays efficiently.

Both C and C++ support hand-made multidimensional arrays quite efficiently. You simply allocate a block of memory and set up the appropriate intermediate pointers. The syntax and the compiler take care of the rest.

They can be declared, passed to subroutines, and iterated over efficiently along any axis.

Multidimensional arrays in C and C++ can be iterated over efficiently along any axis of your choosing. You simply choose which axis when you create the array. (Of course, the ordering of dimensions is important during the array setup phase.)

The compilers know a lot about the properties of arrays, allowing efficient vectorization, parallization, and subscript optimization.

That's pretty nifty. It would be cool if C and C++ had that.

C people do not get this. There have been a few attempts to bolt multidimensional arrays as parameters or local variables onto C, (mostly in C99) but they were incompatible with C++, Microsoft refused to implement them, and they're deprecated in the latest revision of C.

Yeah, but what C and C++ do have is still plenty good for 99% of real-life computation tasks.

Re:Because C and C++ multidimensional arrays suck

[DoofusOfDeath]

A problem with multidimensional arrays in C++ is that there's not a single, agreed-upon type for them. Everyone either rolls his own, or uses whichever comes with the various libraries he's working with (Intel Math Kernel Library, Boost, etc.)

Because there's a variety of multi-dimensional array representations, programs which include external libraries can need to translate between different array representations in different parts of the code. This leads not only to greater code complexity, but greater runtime complexity and memory requirements.

Re:Because C and C++ multidimensional arrays suck

[Animats]

Multidimensional arrays in C and C++ can be iterated over efficiently along any axis of your choosing. You simply choose which axis when you create the array.

That has to have been written by someone who doesn't do much matrix work. A basic matrix multiply iterates in row order for one matrix and column order for the other.

Re:Because C and C++ multidimensional arrays suck

[Anonymous Coward]

General multidimensional arrays are trivial to implment in both C and C++, due to the syntax of [].

You have no idea what you're talking about. General multidimensional arrays, together with all the operations Fortran supports on them, are extremely hard to implement efficiently. Several C++ libraries have tried, and they have all failed. Eigen probably is closest, but it only manages 2D, and is messy and inelegant compared to modern Fortran.

Re:Because C and C++ multidimensional arrays suck

[Anonymous Coward]

>A big problem is that C [...] don't have real multidimensional arrays.

What's a "real multidimensional array" ?

void
plop(int n, int m, double arr[n][m])
{
    double tmp[n][m];

}

Are not arr and tmp real arrays ?

> they're deprecated in the latest revision of C.

What are you talking about ? About that http://en.wikipedia.org/wiki/C11_%28C_standard_revision%29#Optional_features (Variable length arrays) ? If so, they are not deprecated but optionnal...

>but they were incompatible with C++ ... and C++ has mutliple alternatives. Please stop puting C and C++ in the same bag. They are different language with different purposes.

Re:Because C and C++ multidimensional arrays suck

[serviscope_minor]

There's no one way to represent a multidimensional array in C++.

Actually, there is. Underneath it all, it's a pointer, a size per dimension and dimension-1 strides. I do not believe I've ever encountered a multidimensional array (as distinct from arrays of arrays) system which did not do it that way.

In practice, this means you can write a bit of glue code in about 10 minutes to translate multidimensional arrays from one "incompatible" system to another. It's a minor pain, but hardly a showstopper.

Having mixed code from two image processing libraries (two different 2D image representations), a C++ numerics library (its own matrix and vector ones) and some bits of a C one it wasn't that hard. Basically once I had 4 functions like:

CV1Image etoCV1(CV2Image&)

it was pretty much a non issue. Not ideal, but certainly not worth giving up all the other good bits of C++ for.

Re:Because C and C++ multidimensional arrays suck

[Pinhedd]

No language has real multidimensional arrays because most computer address spaces are linear by design. Multidimensional arrays are arrays of arrays, either by index or by reference. There is no other way to do it. Mimicking multi-dimensional arrays in C/C++ is trivial if the style, dimensions, and stride are known. Just allocate an appropriately sized block of data and dereference it with appropriate offsets (or twice if it's jagged). The code generator converts [x][y] notation into this format anyway and most autovectorizers should pick it up.

Re:Because C and C++ multidimensional arrays suck

[Pinhedd]

A contiguous multi-dimensional array in C/C++ is just a block of data with unit stride along the columns and n times unit stride along the rows.

Calculating offsets to do matrix multiplication is incredibly easy as long as the base, dimensions, and stride of each input matrix are known. Now, for particularly large matricies the memory access pattern may be optimized through some clever transposing but that's a different matter.

Re:Because C and C++ multidimensional arrays suck

[HybridST]

Undergrad here. So the base case is taken care of and you call your translation function recursively. What's the difficulty here?

Re:Because C and C++ multidimensional arrays suck

[jabuzz]

You young kids on the block. FORTRAN was *NOT* designed to support multidimensional arrays from the beginning. That only came in Fortran 90. What it did do was have a complex number type. Boy does that make lots of simulation code much much easier to read.

When Fortran 90 came along and added in all the matrix types that made code even easier to read.

Those two reasons along with the fact that academics don't have the time to rewrite all their simulations in the latest new fangled language is why tones of scientific code is still in Fortran.

Re:Because C and C++ multidimensional arrays suck

[J. J. Ramsey]

FORTRAN was *NOT* designed to support multidimensional arrays from the beginning. That only came in Fortran 90.

Not true. Multidimensional array were around at least as far back as Fortran 77. Now what is new in Fortran 90 are the ways to manipulate those arrays. In Fortran 77, one could do arithmetic on elements of arrays but not on arrays as a whole, so, for example, adding two arrays in Fortran 77 required DO loops. In Fortran 90, though, one can add arrays A and B with the expression "A + B".

Re:Because C and C++ multidimensional arrays suck

[flargleblarg]

General multidimensional arrays are trivial to implment in both C and C++, due to the syntax of [].

You have no idea what you're talking about.

Actually, I do. I have implemented multidimensional arrays in C many times.

General multidimensional arrays, together with all the operations Fortran supports on them, are extremely hard to implement efficiently.

Ok, you go ahead and continue to believe that. Meanwhile, I'll continue to be happy with the multidimensional arrays I have in C.

Several C++ libraries have tried, and they have all failed. Eigen probably is closest, but it only manages 2D, and is messy and inelegant compared to modern Fortran.

A friend of mine 20 years ago wrote a general N-dimensional array allocator in C when I showed him how to do 2-dimensional arrays. It worked great then and it still works great now.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

The headline is not a question but a statement. The explanation is in TFS where it says, "no language since has been able to match its speed."

What difference does it make???

[Anonymous Coward]

The business world is still using COBOL. Sometimes you do get it right the first time...

Re:What difference does it make???

[mark-t]

COBOL is a newer language than Fortran.

Re:What difference does it make???

[Anonymous Coward]

COBOL ... is Fortran. "COMPUTE " (as long as it's simple and doesn't require libraries etc.etc.).

Re:What difference does it make???

[Anonymous Coward]

COBOL ... is Fortran. "COMPUTE " (as long as it's simple and doesn't require libraries etc.etc.).

Yeaaaa riiiight. Back in the early 80s I took COBOL as a free elective in college (because it was easy and the teacher was frickin' HOT!!!). I began the semister writing the assigned programs in both COBOL and FORTRAN. The FORTRAN program was folds easier ... until around week 5 or so when the "sort" instruction in COBOL was introduced. You could sort a data structure with up to sixteen (16) keys with a single statement. Needless to say I ceased to continue the write assignment in both languages... (but I did get a date with the instructor! But she smoked like a freight train and couldn't get passed that...)

Took Fortran 77 std. in collegiate academia

[Anonymous Coward]

It was VERY easy to learn, loaded with libraries out the wazoo for just about anything imagineable in the sciences, & very strongly reminded me of BASIC (from what I recall of it).

* I didn't mind using it @ all...

APK

P.S.=> I never once used it professionally on the job though (though I had just about everything else language-wise I'd learned, which is around a dozen or so over time)... apk

Because it works

[BradMajors]

Because it works and it is good enough. FORTRAN is not a good language for "scientific research".

Yes you are

[dbIII]

Don't need fortran due to Petc? Take a look at how it is installed:
http://www.mcs.anl.gov/petsc/documentation/installation.html
Especially note the: ./configure --with-cc=gcc --with-fc=gfortran --download-f-blas-lapack --download-mpich
Is that enough to tell you that the Petc libraries contain fortran?

Re:Yes you are

[friedmud]

You can install PETSc without a Fortran compiler at all. Change that --download-f-blas-lapack to --download-c-blas-lapack and you're good to go...

In fact... MOOSE works on platforms without a Fortran compiler at all... although we generally recommend that you have one (so that you can still link in any legacy routines you've written in Fortran).

I'm not specifically against Fortran... I was just trying to say that most new computational science development at the National Labs is NOT being done in it. We've moved on...

Re:Yes you are

[Dizzer]

Uhm...: http://www.mcs.anl.gov/petsc/documentation/faq.html#why-c

Re:Yes you are

[dbIII]

Fair enough. Python and Numpy is usually the tool of choice where I am but there is some fortran in use, probably mainly due to convenience of adding to existing projects instead of porting.

Re:Yes you are

[Anonymous Coward]

at the National Labs

Um... which nation?

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[K. S. Kyosuke]

APL-style languages should be even more optimizable, since they use higher-order array operators that make the control flow and data flow highly explicit without the need to recover information from loopy code using auto-vectorizers, and easily yield parallel code. By this logic, in our era of cheap vector/GPU hardware, APL-family languages should be even more popular than Fortran!

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Darinbob]

Also "legacy training". Student learns from prof. Student becomes prof. Cycle repeats.

Also Fortran didn't stagnate in the 60s, it's been evolving over time.

Other languages are highly optimizable too. However most of the new and "cool" languages I've seen in the last ten years are all basic scripting languages, great for the web or It work but awful for doing lots of work in a short period of time. It's no mystery why Fortran, C/C++, and Ada are still surviving in areas where no just-in-time wannabe will flourish.

F77/F95 was what I saw used.

[Anonymous Coward]

That may be but most of the code I saw written was Fortran77 although some was Fortran 95. Some of the code was mocked in python first, but there was a HUGE performance difference so all the actual research code was fortran.

Re:not in the field, eh?

[Cramer]

They both generate machine code. But they get there in different ways and produce very different output. It would be more correct to say FORTRAN (compilers) blows away any C compilers. (esp. gcc)

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Brett Buck]

F77+extensions, usually DEC extensions. Very very few people ever used strict F77 with no extensions.

        Some of the issues this causes are irritating bordering on unnerving. This we we discovered that g77 didn't care for treating INTEGER as LOGICAL. Used to be that there was no other way to specify bit operations, now it is precluded. Everybody's code has that, and there's really nothing intrinsically wrong or difficult to understand about it, but it was technically non-standard (although everyone's extensions permitted it) and it won't work on g77 - maybe only with the infamous -fugly flag.

 

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[InfoJunkie777]

I am OP: Sorry I had it down as all caps.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[mbone]

Yeah, I used to hear that argument a lot in 1978...

Re:not in the field, eh?

[rubycodez]

you are spouting off about a field in which you do not work, against a well-known fact.

Doing the quite common operations of numeric analysis, machine output of the C compiler will be worse, less optimized, slower than that of Fortran.

The Best

[Anonymous Coward]

Yes there is a legacy to FORTRAN.

I had my first introduction to FORTRAN, FORTRAN 77, in the Fall Quarter 1978. HOT ! And it was taught in a class from the Electrical Engineering Department ! A Computer Science "Department" came along soon enough in 1980 but the quality and rigor were not there.

Psst.

When I write Bourne shell scripts to do arithmetic and trend surfaces in ANOVA and geophysical inverse, the base functions are FORTRAN 77.

Ha ha

Re:not in the field, eh?

[InfoJunkie777]

OP here. This is what the article said. Compilers are the key. They have been around a long time. Another key is that commercial compilers (like Intel for example) further increase the speed, as the manufacturers know how to optomize the code for the specific CPU at hand.

f2c

[perpenso]

When will they ruin Fortran, like they are ruining everything else?

The did, f2c. :-)

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[K. S. Kyosuke]

Well, we live in a somewhat different world today, given that suitable HW for that is virtually everywhere. But just to be clear, I'm not suggesting anyone should adopt APL's "syntax". It's more about the array language design principles. Syntax-wise, I'd personally like something along the lines of Nile, with math operators where suitable, and with some type inference and general "in-language intelligence" thrown into the mix to make it concise. I realize that depriving people of their beloved imperative loops might seem cruel, but designing the language in a way that would make obvious coding styles easily executed on vector machines seems a bit saner to me than allowing people to write random loops and then either hope that the vectorizer will sort it out (they're still very finicky about their input) or provide people with examples what they should and shouldn't be writing if they want it to run fast.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Dizzer]

This. I have many friends in the physics dept and the reason they're doing Fortran at all is that they're basing their own stuff off of existing Fortran stuff.

The types of people who haven't head about collaborative development or, dare I say, version control.
I've been there. You end up with a zillion diverging (and never merging) forks, people reinventing various wheels over and over, and of course adding their own bugs.
This is a terribly unproductive and sad way of developing code. Unfortunately most scientists I know (knew) don't give a crap because they are _completely_ oblivious to what they are missing out on.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[K. S. Kyosuke]

...because tying your code to a single HW platform is such a great idea.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

> it's[sic] compilers can optimize expressions a lot better than other languages.

No. Wrong. C has had similar aliasing rules for a very long time. It's only recently that they got turned on in GCC by default. This is what all the -f(no-)strict-aliasing nonsense is all about. The problem is, people know that once, before C89, Fortran was faster. So of course it's still faster. Why would anyone ever modify C to be faster? That's just dumb.

Also Blitz++ uses template metaprogramming and a DSL (that looks just like normal c-vector math) to optimize BLAS far beyond what fortran can do. A fairly minor example is rewriting the expression tree for (A+B)[2] to (A[2]+B[2]) at compile time.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

People using existing Fortran code are interested in the RESULTS of the computation, not whether the code is modern or has the latest bells and whistles. Programmers forget that the ultimate goal is for someone to USE the program. I wrote a program in CDC Fortran 77 in 1978 that's still being used, Why? Because it does the job.

Re:not in the field, eh?

[K. S. Kyosuke]

Since you're mentioning Intel....doesn't Intel Fortran and Intel C++ share the same optimizer and the same code generator? I wonder what the *real* performance difference would be between those two. Latest Fortran revisions give you some extra array intrinsic operations, but C++ gives you SIMD intrinsics for tuning in some added boost in critical spots. Sounds like a draw to me.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[mark-t]

The only reason no language since matches its speed is because all of the focus on optimization in modern languages is to increase speed while still focusing on producing correct output from whatever inputs are given, while Fortran optimization does not concern itself with the latter. In practice, this is only an issue when pointers to different types of objects could possibly have overlapping content... Fortran compilers would not necessarily produce the correct output from a given input when this is the case.

Disabling the requirement for correctness, the output of a modern C or C++ compiler with appropriate optimizations can very easily match the speed of what is produced by any Fortran compiler.

Language-limited clients and DRY

[tepples]

My thought at reading the summary was "Do older languages have some sort of expiration date I don't know about?"

That is because you aren't a hipster or fad brogrammer. These idiots probably expect them to be using Node.js or some such bullshit.

In some cases, the client side is language-limited, and everything has to be translated to one language before it can be deployed. In the case of iPhone OS (now iOS) during the second quarter of 2010, this was Objective-C++. In the case of Windows Phone 7 apps and Xbox Live Indie Games, this is the subset of verifiably type-safe CIL accepted by the .NET Compact Framework (which in practice means C#). In the case of web applications, this is JavaScript. In order to ensure that the client-side prevalidation in your web application has provably the same behavior as the validation in the server side, they need to be written in the same language in the same source code files. If your client is in JavaScript, having a server also in JavaScript will let you write the application logic once and not repeat yourself. Hence Node.js.

Re:Language-limited clients and DRY

[Anonymous Coward]

My thought at reading the summary was "Do older languages have some sort of expiration date I don't know about?"

That is because you aren't a hipster or fad brogrammer. These idiots probably expect them to be using Node.js or some such bullshit.

In some cases, the client side is language-limited, and everything has to be translated to one language before it can be deployed. In the case of iPhone OS (now iOS) during the second quarter of 2010, this was Objective-C++. In the case of Windows Phone 7 apps and Xbox Live Indie Games, this is the subset of verifiably type-safe CIL accepted by the .NET Compact Framework (which in practice means C#). In the case of web applications, this is JavaScript. In order to ensure that the client-side prevalidation in your web application has provably the same behavior as the validation in the server side, they need to be written in the same language in the same source code files. If your client is in JavaScript, having a server also in JavaScript will let you write the application logic once and not repeat yourself. Hence Node.js.

Huh ? ... why would you write the same application logic on both the client and server ? ... isn't that, by definition, repeating yourself ?
The 'front-end', on the client, cares about fundamentally different things than the 'back-end', on the server.
What is needed is a more-or-less standard way for a 'client' to talk to a 'server', no matter what each is written in ... and we have that with REST/JSON.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[mysidia]

A: Legacy code, and because Fortran 2003+ is a very good modern language for scientific computation and maps very naturally to problems

See.... Fortran 2003 is more modern than ISO 1999 C.... Now that that's settled... How come people are still programming in languages like C/C++/Java, when Fortran2003 is available?

Gnu killed fortran

[goombah99]

For years and years and years the Gnu G95 compiler was only a partial implementation of the language. This made it impossible to use without buying a complier from intel or absoft or some other vendor. It chokes the life out of it for casual use.

Personallyt I really like a combination of F77 and python. Whats cool a bout it is that F77 compiles so damn fast that you can have python spit out optimized F77 for your specific case sizes. Then for the human interface and dynamic memory allocation and glue to other libraries you can use python.

Re:Gnu killed fortran

[wispoftow]

I think it is unfair to say that a group of unpaid developers actively took a role in killing anything. You have to remember the times -- GNU was barely off the ground with gcc, let alone g77. (In fact, g95 filled the role of gfortran) Today, I would argue that gfortran has SAVED Fortran, by making it accessible to low-budget ($0) developers who's salaries are probably less than a Power7/xlc/xlf/essl stack.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

This, plus:
1) C/C++ isn't viable for a scientist to just 'pick up' and be productive with, short of a massive loss in productivity.

2) A lot of the people I've worked with in this field (CSIRO and Geoscience Australia, personally) literally grew up with Fortran (they're in their late 40s to early 50s, they've been in the industry for decades, Fortran works, Fortran is what they were taught, Fortran is what they use).

3) IDL/etc are commercial (node based licensing), you might think "you've got money to burn, just do it!" until you realise we run these algorithms literally on hundreds to tens of thousands of nodes concurrently. Not everyone can afford half a million dollars on top of what's already hitting close to 1m on storage/compute costs. (ammendum: No, GDL isn't applicable to a lot of fields, it's lacking a lot of modules/libraries or non-conformant even in the core)

4) The next set of serious contenders (which is something we actually use, in production environments) is Python w/ NumExpr or Cython or some other set of optimization frameworks that we can use to make our numpy/scipy - but you get back to point #1 - scientists (who aren't great programmers) + dynamic language w/ poor lint tools and no 'compile' time validity analysis = headaches.

All of that said and done, there's a bit of a shift in the industry (or at least in GIS/geophysical analysis/remote sensing) where people are recognizing the science/math, and the implementation are equally important, and require separate skill sets - most modern projects now days don't have scientists writing production code, they've got real developers taking the math or prototype Fortran/etc implementations and porting them to codebases that are more maintainable by their larger development resources (and not those few scientists who still know Fortran).

Re:not in the field, eh?

[mark-t]

The reason this is true is that Fortran compiler output, when appropriate optimizations are turned on, is not actually concerned with producing correct output... and although it is certainly faster, the resulting code will be less robust than code output by a modern most modern C compilers. Modern compilers generally focus on producing correct output at all times, and may make compromises in efficiency for correctness.

The main differences involve pointer aliasing... and a C or C++ compiler with the appropriate optimizations switches to ignore pointer aliasing possibilities, as Fortran does, will produce code that is just as fast as that which a Fortran compiler can produce.

huh

[buddyglass]

Back when I was in school, the consensus seemed to be that C was "about as fast" as FORTRAN. And when FORTRAN was really faster you could just write most of your code in C and link to FORTRAN libs. BLAS, LAPACK, etc. Just had to store your arrays in column-major order. If you look at the benchmarks at the Julia site, linked in the article, you'll see that FORTRAN beats C by a large margin in one benchmark, loses by a large margin in another benchmark, and is slightly faster in all the others. They state that they used gcc 4.8.1 as their C compiler but don't mention what compiler they used for FORTRAN. Also gcc 4.8.1? Kinda matters.

IF (X/Y*Z) 100,300,50

[lfp98]

When I was in college (1968-72) the big contest was between FORTRAN and ALGOL. ALGOL was supposed to be more logical, readable and humane, but it certainly was more verbose, and FORTRAN won out with its brutal efficiency, telling the machine what to do, in the minimum possible number of characters. I remember being particularly fond of the Arithmetic IF (a legacy feature even then): IF (X/Y*Z) 100,300,50, which would go to statements 100, 300 or 50, depending on whether (X/Y*Z) was negative, zero or positive. I haven't written a FORTRAN program in decades, but I'm still saddened to hear that feature is now obsolete. (http://stackoverflow.com/questions/10758935/fortran-compiler-warning-obsolete-arithmetic-if-statement)

Re:IF (X/Y*Z) 100,300,50

[wispoftow]

No loss. IF should expect to be supplied by a boolean: .TRUE. or .FALSE. Also, how dangerous is it to assume that one would ever get 0.000000 condition what with round off error? It may have been useful shorthand when faced with punching out the more explicit if else if's but those days are computer science archaeology.

Re:IF (X/Y*Z) 100,300,50

[wispoftow]

just to correct my comment: computed goto was ~usually~ done with integer arithmetic. I made my comment based on your use of X, Y, and Z which I am sure were declared using IMPLICIT DOUBLE PRECISION (A-H,O-Z) :-)

Re:IF (X/Y*Z) 100,300,50

[Anonymous Coward]

That sounds like the ON .. GOTO that was in BASIC 2.0 on the Commodore 64, and I suppose many other BASICs.

http://www.c64-wiki.com/index....

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[David_Hart]

I would also hazard a guess that Fortran tends to be a tad easier to read than C... Especially for scientists...

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[K. S. Kyosuke]

Blitz++ is hardly the pinnacle of what should be possible with proper array languages. Think of what you could do with higher-order operators - for example, interprocedural loop fusion becomes trivial, and one could probably come up with many other operations optimizable accross procedure/function/subroutine (whatever you want to call it) boundaries as well. Blitz++ was neat but it can't beat a dedicated compiler for an array language (by which I most certainly don't mean stateful loopy Fortran). Although I agree that the C++/C interoperability is a huge plus.

THIS...

[Anonymous Coward]

The three "contenders" are currently only so in the minds of the CS people that're fans of the languages and don't "get" the above concepts.

Of the three, the one with the most potential is Haskell. It can compile to reasonable speeds compared to C/C++, but gets beat for most expressions in Fortran by a factor of 2-3 times faster. Will it replace Fortran? Not likely. Not until it can match Fortran's speed and can convince people to port their stuff over because of the expressiveness available with Haskell. As it stands...Haskell's a distant possible in the space.

The others? Heh...don't make me laugh. Still wondering what crack the article author was smoking to think that Clojure and Julia are replacements for Fortran. Not even close.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

Latin is less ambiguous than English, which is why we still use it in science today (pay attention to medicine and pharmacology). You are ignorant about both Fortan and Latin, but you just had to spout off anyway.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[avandesande]

Or you are explaining the use of a well defined library in a peer reviewed journal. Using a new untested library would be suspect.

Re:not in the field, eh?

[InfoJunkie777]

Since you're mentioning Intel....doesn't Intel Fortran and Intel C++ share the same optimizer and the same code generator? I wonder what the *real* performance difference would be between those two. Latest Fortran revisions give you some extra array intrinsic operations, but C++ gives you SIMD intrinsics for tuning in some added boost in critical spots. Sounds like a draw to me.

You very well could be right K.S. I am not a programmer. Wanted to be. Too late to start I think. I was just going by what was in the article. I had hoped others would comment on the the "3 modern condenters" but the bulk of comments are in line with the article: "it just works and it is fast and has HUGE libraries and legacy code." From what I could follow Julie seemed the most interesting, but the bugs not out of it yet.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

It's not just that it was the only language shared, it was that the language is capable of precision other languages lack. Doctors still use Latin for just this reason.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[edibobb]

This is absolutely right. It's also easier to write, in many cases. Most scientific applications don't need things like lambda expressions or derived classes. Many people who write applications as tools in their research don't want to spend time learning esoteric aspects of languages.

Popular has a lot to do with installed base...

[Anonymous Coward]

First you have to convince people they want to use a language, regardless of how good it is for anything, any new language will have to compete with the existing code base and programmers' (reasonable) reluctance to learn new things.

Part of why fortran is so easily optimizable is because of all the practice that people have optimizing it, and man-centuries spent developing it.

Re:Popular has a lot to do with installed base...

[Rei]

Isn't the main performance benefit that Fortran has always claimed over C/C++ the fact that an array is guaranteed to only be used from one thread at a time, and thus you don't have to re-read from memory to registers each time you want to do something with the data in the array? A capability that was formally added to C in C99 (and pretty much universally informally added to C++) with the restrict keyword?

Correct me if I'm wrong here, as I'm not a Fortran programmer.

Re:Popular has a lot to do with installed base...

[dumael]

Fortran doesn't restrict multiple threads accessing the same array (see OpenMP), instead it restricts how pointers may be used. A frequent problem with program optimization is that if two or more pointers address the same location, it is aliased.

This wrecks havoc as the compiler can no longer assume some optimizations are safe.

Otherwise your post is mostly correct.

Re:Popular has a lot to do with installed base...

[Athrac]

Restrict keyword is not related to threading. C/C++ compilers have always assumed that data is not accessed from several threads without synchronization. It just wasn't standardized until the new memory model in C11 and C++11. So if you don't use mutexes, memory barriers etc, the compiler is allowed to assume a single thread of execution.

What restrict does is it guarantees that two pointers do not point to same area in memory (aliasing). Let's say a function takes two pointers (char* a, char* b). If you write to the data pointed by a, then the compiler has to emit code to re-read data pointed by b, because a and b might refer to the same location. With restrict pointers the compiler doesn't have to do this.

C/C++ have also always had the concept of strict aliasing, which basically says that pointers with different types may not be used to access the same memory location (char pointers are exception). It allows the same optimizations as the restrict keyword. However most compilers don't enforce the rule because programmers are stupid and use all kinds of noncompliant hacks with pointers.

Re:Popular has a lot to do with installed base...

[ttucker]

Isn't the main performance benefit that Fortran has always claimed over C/C++ the fact that an array is guaranteed to only be used from one thread at a time, and thus you don't have to re-read from memory to registers each time you want to do something with the data in the array? A capability that was formally added to C in C99 (and pretty much universally informally added to C++) with the restrict keyword?

Correct me if I'm wrong here, as I'm not a Fortran programmer.

Correction, the whole debate about speed is mostly a thinly veiled excuse to continue using an antiquated programming language for no other pragmatic reason. Half the problem is probably the desire to use legacy libraries, but the other half is simply difficulty in learning something new.

Re:Popular has a lot to do with installed base...

[Anonymous Coward]

Antiquated?

It is not like Fortran stopped improving.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[OakDragon]

Please... it's spelt "c" now.

Because Real Programmers don't need anything else

[ecgordon]

From the still clever, still humourous, and still applicable 1983 Letter to the Editor in Datamation Real Programmers Don't Use Pascal. Just replace "Pascal" with your language of choice. Enjoy.

BLAS is just an API.

[Anonymous Coward]

Oh like BLAS?

When will people learn that BLAS is an API, and OpenBLAS and MKL or whatever you find isn't actually written in Fortran. It's C and assembly for the most part.
Also, I haven't seen any sparse solvers written in Fortran ever (there might be one, but they are not the ones I'm using).
Just like writing something complex like, say, ParMETIS or Netgen, in Fortran wouldn't be something you wished upon your worst enemy.

The stuff you find at NETLIB is a reference implementation. It's meant to be easy to read, not to be actually USED in serious applications. Sheesh.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[wispoftow]

No, you are wrong by being terribly incomplete. People who use Fortran (or any language for that matter) are interested in getting the correct answer, in the fastest reasonable time, with the shortest amount of developer work (and perhaps cost matters). In the scientific domain, Fortran remains competitive. The precise cost function that balances these considerations depends on many variables and is precisely why we have so many languages today.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

blah blah... allowing people to write random loops and then...blah blah

This comment is either an ad hominem or completely ignorant. It's math, and there are no random loops. Loops are intentionally designed and required, or perhaps you missed out on several years of Calculus and Linear Algebra.

The reason Fortran is still around is that it's exceptional for math. Both ease of writing code to solve equations and it's precision when code is run.

Sure, Pascal had some advantage in certain expressions. Pascal was also horrible for I/O so great if you never wanted to do anything but solve an equation in memory. C is easier for some things too, but not when the equations get massive or require repetition.

Blabbing on and on about vector based GPUs is idiocy, because not everything uses trig where vector based processing is beneficial. I have no confidence you have ever seen math intensive code based on what you are talking about. Nile from their own page is # The Nile Programming Language ## Declarative Stream Processing for Media Applications and NOT a language for Math.

Re:not in the field, eh?

[K. S. Kyosuke]

I think it's quite simple: climate scientists will be using Fortran for the next hundred years, because that's what dozens of humongously complex climate models have been written in, and these people will absolutely need to perform meta-studies and aggregate studies comparing dozens of independent models, including comparisons of their newest models to all the models that have been devised from 1970s or so until the point of their current research. This is, after all, where IPCC gets their "best predictions/worst predictions" charts. So even if many people were willing to switch to something else (those with smaller codebases, independent scientific programmers and engineers etc.), there will still be huge bodies of code that will absolutely need to stay untouched to support reproducible research in the future at least in some very important scientific fields.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[wispoftow]

Missing out on what, the wonders and simplicity of using git? (/sarcasm)

Many Fortran programmers are academics, and academics are often times (not always) concerned with one-off programs that demonstrate a computer-based solution to a novel phenomenon. Often times, the investigator works alone. Once that is done, sometimes the code is never visited again. In these cases, anything more than VMS-style versioning is total overkill.

I agree that version control is important and often ignored. But this is not specific to Fortran -- but rather that the fact that version control adds overhead both in using and learning -- and academics are often putting all of their efforts into the science.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[camperdave]

APL-family languages should be even more popular than Fortran!

Probably would be if it wasn't a write only language.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

Why program in Perl if Python is here, or Ruby, or Shell scripts, or Java, or hell even Cobol. Every language has a purpose and feature set, which was designed to make something easy. I would not write a pop-up window in Fortran any more than I would try and write a physics equation in TCL. The languages are not designed or suited for the same thing. This is not some hard to get concept, it's basic fucking history.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[wispoftow]

...and i would like to see statistics on how many git branches are created, yet never merged back in.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[camperdave]

Please... spelt is a grain.

Re:not in the field, eh?

[ShanghaiBill]

Doing the quite common operations of numeric analysis, machine output of the C compiler will be worse, less optimized, slower than that of Fortran.

Badly written Fortran will run faster than badly written C. Since most scientists are poor coders, it makes sense for them to use Fortran when optimization is important. Someone that understands how compilers work, and understands issues like pointer aliasing (and how to avoid it), can write equally fast code in either language.

Re:not in the field, eh?

[Anonymous Coward]

You don't know what you're talking about.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[K. S. Kyosuke]

Blabbing on and on about vector based GPUs is idiocy, because not everything uses trig where vector based processing is beneficial. I have no confidence you have ever seen math intensive code based on what you are talking about. Nile from their own page is # The Nile Programming Language ## Declarative Stream Processing for Media Applications and NOT a language for Math.

I find this view quite amusing, given that the whole scope of the VPRI project (of which Nile has been of the intermediate results) is to reduce everything in common personal computing into mathematics. And Nile in particular was designed precisely and explicitly to allow the VPRI people to express as wide an array of graphical operations using as short a high-level description as possible - a mathematical description, in equational form, to allow them to express the majority of Cairo (or any other Cairo-like 2D library) in a few hundred lines of these equations. Furthermore, nowhere have I made the claim that the semantics of Nile in its current form is a perfect replacement for any language for scientific computation, as opposed to the thought that there could be some lessons to be learned.

And why don't you log in? There seem to be quite a few anonymous psychotic individuals running around here recently. It makes the conversation feel quite disingenuous.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[redelm]

You may not like Fortran's I/O, but for the subject matter (tables of numbers), IMPLIED DO loops work a lot nicer than repeated printf() calls in `c`. Contrary to n00b whining, FORMAT statements can be your friend.

Of course Fortran is horrible with strings, mostly because it is older than strings!

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[K. S. Kyosuke]

Latin was the one language that all academics shared.

...you mean, those who didn't speak Hebrew, Greek, or Arabic?

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[wispoftow]

Most people learned Fortran in a class intended to teach scientific programming. I have never, ever, ever seen a course catalog that lists CS 201 FORTRAN PROGRAMMING. It has always been about getting the scientific result -- it just so happens that Fortran has been pretty good at it and actually pretty simple -- and so it has often times been used.

That being said, C almost killed Fortran (77) because they waited so damned long to bring out Fortran 90. People were sick and tired of waiting for dynamic memory allocation and free form input, and so many people who were past entry-level programming started jumping to C (...which I would never relish to teach to a beginner who has no solid interest in computer programming).

Fortran speed is an urban legend

[datacharmer]

Several years ago (in 1992) I was involved in the rewrite of a large fortran program, which had been around for decades and had become unmaintainable and slow. The physicists who had been working with the program were absolutely convinced that no software could replace fortran for speed. I did not believe that. Operating systems at the time were written in C, and the only thing that beats C for speed is assembly. I made several tests with bare scientific calculations, using fortran, C, and C++, and fortran came up (surprise surprise!) the slowest. Then, the physicists rewrote the fortran application in C++, with some help from me with the object-oriented design. Not only the replacement program was faster, more maintainable, and easier to read. But we found out that the main problem of the program (written in times where RAM was scarce and never updated) used files instead of in-memory arrays or any more modern data structure, or a database, which would be the first choice nowadays. The application was slow because it was designed with constraints that were not realistic anymore. In the end, the replacement program was slightly faster in the number crunching, but immensely faster in the data handling. While the original program required one day or more of very expensive supercomputer time to complete its work, the new program ran in just a few hours. The sad truth is that, even now, many fortran programs are fossils of an era where hardware constraints made the choice of data structure and algorithm, and they were never reviewed.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

> Fortran (yes, that's how it's spelt now, not "FORTRAN")

Pedantic much?

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[K. S. Kyosuke]

"Capable of precision other languages lack"? There's nothing to support that claim in modern linguistics. If Latin has an upper hand, for example in medicine, it's because most, if not all of the terminology was developed in that language, but nothing prevents you from saying "medulla oblongata" in English with zero loss in meaning. If doctors still use Latin today, it's because writing the remaining 20% of non-teminology in a medical text in the same language that the terminology is written in makes it international, not because it magically gets some "extra precision". (Do purely Latin longer texts get still published in medical journals anyway?)

Legacy Programmers

[Roger W Moore]

Also "legacy training". Student learns from prof. Student becomes prof. Cycle repeats.

Not really - even when I was a student we ditched F77 whenever we possibly could and used C or C++. The issue is more legacy programmers. Often the person in charge of a project is a older person who knows FORTRAN and does not want to spend the time to learn a new language like C (or even C++!). Hence they fall back into something more comfortable.

However by now even this is not the case. The software in particle physics is almost exclusively C++ and/or Python. The only things that I am aware of which are still FORTRAN are some Monte-Carlo event generators which are written by theorists. My guess is that as experimentalists even older colleagues have to learn C++ and Python to use and program modern hardware. Theorists can get by using any language they want and so are slower to change. Certainly it has probably been at least 15 years since I wrote any FORTRAN myself and even then what I wrote was the code needed to test the F77 interface to a rapid C I/O framework for events which was ~1-200 times faster than the F77 code it replaced.

Re:Legacy Programmers

[Anonymous Coward]

In many instances, if you are doing lots of numerical calculations, you are likely to be using numpy, scipy or cblas in which case the heavy lifting is probably being done by the Intel MKL and Fortran (AMD processors are also available and equivalents on GPUs).

This seems to be a good thing as it is providing a higher level of abstraction rather than being concerned about implementation details which potentially change between machine architectures so moving to a different cluster which might have a different APU design will still run at a good level of optimisation, as well as the code being more readable.

Re:Legacy Programmers

[Anonymous Coward]

You should give Fortran 2008 a try. It's a completely different language now, and many people like it better than C++.

Re: Legacy Programmers

[loufoque]

Not all scientific computing is governed by LAPACK. Even for the cases where it is, there are better numerical methods and parallelization schemes out there, it's actually possible to beat MKL in special cases.

Re:Legacy Programmers

[shutdown -p now]

The software in particle physics is almost exclusively C++ and/or Python.

Not so long ago, I talked to a guy whose software was mostly Fortran, with Python as a glue. Apparently the FFI on both ends is good enough that hooking this up is no less complicated than it is with C. That was fluid dynamics.

Among other things, they used Python for unit tests...

Re:Legacy Programmers

[Anonymous Coward]

Also "legacy training". Student learns from prof. Student becomes prof. Cycle repeats.

Often the person in charge of a project is a older person who knows FORTRAN and does not want to spend the time to learn a new language like C (or even C++!). Hence they fall back into something more comfortable.

Excuse me, but you're going to have to explain how your model is different from the one you say is wrong.

However by now even this is not the case. The software in particle physics is almost exclusively C++ and/or Python. The only things that I am aware of which are still FORTRAN are some Monte-Carlo event generators which are written by theorists. My guess is that as experimentalists even older colleagues have to learn C++ and Python to use and program modern hardware. Theorists can get by using any language they want and so are slower to change. Certainly it has probably been at least 15 years since I wrote any FORTRAN myself and even then what I wrote was the code needed to test the F77 interface to a rapid C I/O framework for events which was ~1-200 times faster than the F77 code it replaced.

Ahh! and therein lies the rub. Yes, for some applications other languages can be faster than Fortran, but not always and not all of them. The power of. Fortran was its sequential execution, for a time. Since Fortran90 object oriented principles have been implemented and since Fortran95 there have been many improvements. A lot of quantum and molecular dynamics code are still in Fortran. A lot of finite element analysis code is in Fortran. After being in academia for more than twenty years I can say that the move away from Fortran is definitely hampered by legacy code and faculty keeping their students into their research, not rewriting apps that work in a modern programming language. Unless they are a CS student the kind of code migration you talk of just isn't happening on the scale you might think. Now, where you went to school they may be using C code, but don't count on that being universal. Yes, there are a lot of simple apps written in Perl and Python as well, but they're usually little pre- or post-processing apps, but a lot of engineering and scientific code is in Fortran. This includes large packages like CHARMM, VASP, Amber, and many others used daily by scientists today.

Re:Legacy Programmers

[Roger W Moore]

Excuse me, but you're going to have to explain how your model is different from the one you say is wrong.

The point is that it is not the training provided by us professors it is the people in charge of the projects who used to require Fortran. However this has almost completely changed. I can't speak for other disciplines but in Particle Physics the code migration IS happening on the scale I think. All the major programs used in collider physics have migrated to C++: GEANT, PYTHIA and ROOT are all now C++. There are still some generators written by theorists which are Fortran but these are becoming increasingly rare because it is becoming harder to find anyone who understands the language which means that such programs are less likely to be used.

Re:Legacy Programmers

[Anonymous Coward]

Incorrect. A very large number of scientific applications are still written in Fortran, from global climate models to the weather models and analytical software used by NOAA and NWS offices, even today. These are real applications used to solve real problems, make forecasts, etc. and they're written almost entirely in Fortran.

Fortran isn't going away because there is 50+ year ecosystem built around it. Huge, heavily optimized programs and libraries exist for Fortran that no one is going to bother re-writing for another language. Some of the code I come across in these models and libraries have sections older than I am.

Then, there is the culture. Scientists aren't overly concerned with code quality or maintainability. They focus on getting something working. After that, if someone else wants to use it is their problem. It's better today than it was 20 years ago but modern paradigms and software engineering practices really aren't a big driver in the general science community.

Re:Legacy Programmers

[squarkify]

As someone who spends their sabbatical doing experimental particle physics research at Fermilab, Roger W Moore's description of software usage is 100% accurate.

Re:Legacy Programmers

[Anonymous Coward]

The only things that I am aware of which are still FORTRAN are some Monte-Carlo event generators which are written by theorists.

There's still a lot of new Fortran being used in astronomy too. I still find writing in Fortran cuts my coding time in half for numerical programs and for one-off jobs that's more important than the run time (and I say this as someone who's been using C since 1990, even before I knew Fortran).

-JS

Re:Legacy Programmers

[niftymitch]

The software in particle physics is almost exclusively C++ and/or Python.

Not so long ago, I talked to a guy whose software was mostly Fortran, with Python as a glue. Apparently the FFI on both ends is good enough that hooking this up is no less complicated than it is with C. That was fluid dynamics.

Among other things, they used Python for unit tests...

The interesting bit about tossing Python in the mix is Python is a rich
collection of C, C++ and other code. The interpreter is only a small
bit of what runs in most cases. Time after time when some
interesting bit of Python was found to be a hot spot it would be coded
in C (or any language) with the correct link-to-it bits to to cool off the hot spot.
As long as the linking bits are correct any compiler can be used as
well. Consider that those that find clang.llvm to be a winner over gcc
can use the compiler that is the bake-off winner (there can be large differences).

This relentless hot spot removal by the Python community has
greatly increased the value. Even R bindings exist.

FORTRAN, Fortran and fortran all have clear regions where symbolic
math can rule. Math types have gotten very good at correct symbolic
transformations and machines can automate the transformations.
For example the compiler can discover a constant expression and evaluate
it once inserting the answer into the code. If you run the program 10,000
times on 5000 machines this constant evaluation by the compiler takes
time Tr=Tc/(10000*5000) and at runtime has an answer latency of near zero.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[phantomfive]

I think the problem is the keyboard. They don't make 'em anymore.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[phantomfive]

However most of the new and "cool" languages I've seen in the last ten years are all basic scripting languages

True point.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Salis]

Same sig since 2003....

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

Why is most analysis software Fortran based, if C/C++ is so much more accurate? Hint, it's not. Linear and non-linear analysis applications use Fortran and Fortran libraries not just because they are faster, but because they are more accurate.

With this comment and everything else you wrote in the thread, you are simply wrong and speaking from complete ignorance.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[K. S. Kyosuke]

Actually, you can get one for mere $35! ;) But no, the surface syntax is definitely something I didn't have in mind.

Wrongly!

[Roger W Moore]

Perhaps it's still the best tool for the job. Why is that strange?

It's not strange it's just wrong. Particle physics does not use FORTRAN except in very limited places usually associated with theorists who have not yet migrated to C++ which is a small and diminishing number. As far as I am aware the astrophysicists down the hall from us don't seem to use it much either and the experimental condensed matter guys don't either as far as I am aware. So either things like physics research in general is not cutting edge or the OP doesn't know what s/he is talking about.

Re:Wrongly!

[fahrbot-bot]

Particle physics does not use FORTRAN except in very limited places usually associated with theorists who have not yet migrated to C++ which is a small and diminishing number.

Although, C and FORTRAN are not (or were not) implemented/executed identically. I remember way back in the late 1980s - early 1990s, when I was working as a system programmer/administrator at the NASA Langley Research Center, I was asked to port a FFT (Fast Fourier Transform) routine from FORTRAN to C on their Cray-2. [A researcher wanted to stream live wind tunnel data through the Cray instead of forking out $50k for a dedicated processor.] The C version did not perform as well as the FORTRAN version - yes I ported it correctly. I understand that there were different optimization abilities for the two compilers, but I also believe it had to do with one language being "row major" and the other "column major" for arrays (I can't remember which was which) and the FORTRAN memory model was more efficient on the Cray-2. So, use the appropriate tool for the equipment/environment you're using.

Re:Wrongly!

[Roger W Moore]

Late 80s and early 90s? Welcome to the 21st century! We now have CPUs with features that require compiler hints and optimization to achieve maximum performance. In fact by even the mid 90s I did optimization studies for trigger code for and experiment and found that the C++ compiler generated far more efficient code than the C compiler because that was where the company was putting its development resources.

However it is not just that. In particle physics we do a lot of I/O, reading binary data and have large code bases which need object oriented programming to manage. Fortran can do none of these things unless you use one of the many recent flavours that have tried to bolt these onto the language. In addition it is not a language that undergrads learn anymore (at least in physics).

Re:Wrongly!

[fahrbot-bot]

In addition, the Cray-2 was a vector processor, so, from what I understand, if you accessed your memory/arrays in a manner compatible with the "stride" things ran very, very fast, but you could easily screw that up - which was probably happening with the FORTRAN to C port. I'm not a compiler wonk, but understand that things have come a long way since I started out. I get the I/O thing for your work and have written a few routines doing I/O and mmap(), which is not only fast, but dodges some accounting as well, as well as a few things for an X11 pass-through scanner/server. Obviously not the scale of particle physics stuff, but I get the general idea. Thanks.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

Naturally, since Slashdot also encourages re-use articles!

It's not just ivory tower types

[Lord Kano]

Fortran is still in use in heavy industry.

When I did my internship, I worked for a company involved in heavy industry and despite the language du jour devotion of the business people, the industrial part still relied heavily on Fortran. It's more cost effective to train new people to maintain the Fortran than it is to re-write and debug mammoth Fortran programs that still work just fine.

LK

Fortran supports OO now

[plopez]

Check out the 2008 version. OO and support for parallel processing. Why use anything else?

Re:Fortran supports OO now

[Rei]

Can you inline an instruction as easily as:

thread([&](){ /* Your code here */ }).detach();

?

The easier is is to thread little things, the more people will do it.

Re:Because

[Anonymous Coward]

Scientists prefer:

1.1 + 1.1 = 2.2

instead of

1.1 + 1.1 = 2.19999999999999999999999999999999999999999999999999999999999999999999999

Then don't compile FORTRAN on an Intel Pentium...

Re:not in the field, eh?

[Anonymous Coward]

Being in the industry, I can safely say C and Fortran codebases tend to be equivalent in speed, Fortan can do some implicit optimizations C can't, but you rarely hit those cases if both codebases are well written - this is assuming comparing gcc to gfortran or icc to ifort with identical flags (-O3/4 etc, eg: apples to apples).

Newer Fortran dialects 'can' get implicit parallel optimizations, for sure - but you're not longer comparing apples to apples there, you're comparing single core C to multi-core Fortran - and that's nothing a bit of OpenMP can't fix.

At the assembler level (on x86_64) - we find near optimal register allocation and code generation from both langauges. So you're either doing something very wrong w/ C, or you're full of it.

(note: my industry = remote sensing, working on - in the smallest case, images w/ 60+ channels of 16 or 32bit data at resolutions around 19,000^2 - yes, 60GB images are about as small as we get - although you tend to work on individual channels at a time, so you're often only dealing with a few hundred MB at a time if you're not in a part of the algorithm you can segment/tile)

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

Student learns from prof. Student becomes prof. Cycle repeats.

I've actually seen the exact opposite most of the time. Students, and a lot of people, find it easier to write new code than to read old code, especially if they have some language preference. So a lot of students come in thinking they will rewrite the code in a new language. This is usually at least fruitful because it makes sure they know the internals of the code assuming they get anywhere with it. But at some point, they either realize their code is slower, or they didn't realize how much effort it is to rewrite something, or that they over-extended it into a redesign that fails, or they have trouble getting other people to change to something unproven. Sometimes it does actually go through, and you get something better, faster or easier to maintain. But most of the times you end up with a bunch of students each with their own partial rewrite of something that still works solidly in the first place.

Right took for the job

[Anonymous Coward]

Because its the right fucking tool for the job.

Why instead?

[Grindalf]

Why instead? Why not add other languages to the distros as well as FORTRAN? What is wrong with leaving the f77 standard alone if you don't use it? That's what I want to know

K.S.Kyosuke has delusions of grandeur?

[Anonymous Coward]

Calling all ac's psychotic. Ok. Care to show us your license to practice psychiatric sciences with a degree in them plus years of professional practice along with a formal examination of said ac's given in a professional psychiatric environment? Oh, you don't have ANY of that?? Figures. See subject-line and quit trying to play "the SiDeWaLk-ShRinK of /." since it's about as convincing as your trying to play programmer.

K. S. Kyosuke gets called out & ran

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke gets called out & ran

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[DaveAtFraud]

I disagree. There are several "irregular" English verbs that have become regular but the irrgular use is not incorrect (burnt works as well as burned, dreamt instead of dreamed, etc.).

Cheers,
Dave

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[poodlediagram]

My previous supervisor decided to fork our Fortran code for performing quantum mechanical calculations. We'd worked on it for more than half a decade and it was world-class.

He handed it over to a computer science graduate (i.e. a non-physicist) who really liked all the modern trends in CS. Now, five years later:

1. the tarball is an order of magnitude larger
2. the input files are now all impenetrable .xml
3. the code requires access to the outside (not possible on many superclusters)
4. he re-indented everything for no apparent reason
5. the variable names were changed, made into combined types and are much longer
6. as a result, the code is basically unreadable and nearly impossible to compare to the original formulae
7. code is duplicated all over the place
8. it now depends on unnecessary libraries (like the ones required to parse .xml), and it only compiles after a lot of work
9. it's about four times slower and crashes randomly
10. it generates wrong results in basic cases

To quote Linus Torvalds: "I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really *would* prefer to piss off, so that he doesn't come and screw up any project I'm involved with." ... and I feel the same way about CS graduates and Fortran. They have no idea about the physics or maths involved (which is the difficult part), so the do the only thing they know which is to 'modernize' everything, making it into an incomprehensible, ungodly mess.

Fortran, apart from being a brilliant language for numerical math, has the added benefit of keeping CS graduates at bay. I'd rather have a physicist who can't program, than a CS type who can.

(Apologies to any mathematically competent computer scientists out there)

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Old Fatty Baldman]

Fortran is 40% QBasic and 60% OMFG ALL CAPS. Ideal for folks who are fundamentally ignorant of software development. You think I jest... SUBROUTINE SUB1(X,DUMSUB) INTEGER N, X EXTERNAL DUMSUB COMMON /GLOBALS/ N IF(X .LT. N)THEN X = X + 1 PRINT *, 'x = ', X CALL DUMSUB(X,DUMSUB) END IF END

Speed claims are nonsense.

[Anonymous Coward]

Speed claims are B.S. all it has going for it is efficient array access and that's questionable these days.

Related quote

[DaveAtFraud]

C Anthony "Tony" Hoare: "I don't know what the programming language of the year 2000 will look like, but I know it will be called FORTRAN."

He was conservative on the date.

Cheers,
Dave

Systemd, that's why

[Anonymous Coward]

Systemd

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[tlambert]

I have never, ever, ever seen a course catalog that lists CS 201 FORTRAN PROGRAMMING.

I guess it's "bear in the woods" time...

That is because you are a kid who learned after 1986 in the U.S., after they changed the accreditation standards, and caused the next crop of CS graduates to not have learned programming languages specifically (i.e. caused then to learn their tools, as opposed to "learn the tools on your own and apply them to a problem domain"). That change is one of the reasons it's frequently more useful to hire people graduating from European Universities than U.S. Universities, and why we need so many H1-B visas for those folks: U.S. Students know theory, but can't code, because they don't know how to use their tools, unless they come out of a college or university that offers non-acreddited language courses on top of the rest of the curriculum - e.g. Rice University, Brown University, and so on, or they otherwise mastered (not just learned) them on their own.

https://archive.org/details/co...
Illinois State University course catalog, 1982 - Pg 53 - Applied Computer Science Courses
164 INTRODUCTION TO FORTRAN PROGRAMMING
169 INFORMATION PROCESSING USING PL/1
265 JOB CONTROL LANGUAGE
272 COBOL AS A SECOND LANGUAGE
274 PL/1 AS A SECOND LANGUAGE
283 ASSEMBLER LANGUAGE PROGRAMMING
288 ADVANCED ASSEMBLER LANGUAGE PROGRAMMING

CS Used to be taught very differently than it is today. Today, ABET Accreditation requires that you implement "Outcome Based Courses", which means that it's really not about coding any more, it's about documenting a process, and then documenting that you followed that process. See also:

ABET - Criteria for Accrediting Computing Programs, 2012 - 2013
http://www.abet.org/DisplayTem...

Anyone worth hiring today that graduated with a U.S. CS degree in the last two and a half decades graduated from one of a handful of universities with "Extra requirements" that include actually learning specific computer languages, or included self-directed programs, where one of the options was learning one or more specific computer languages. Or they have been involved in one or more large Open Source projects where participation required that they learn one or more specific computer languages, and that they actually participated more than tangentially in the project.

I've seen many outstanding U.S. candidates, as an interviewer, and either they graduated before 1986-1988, OR they went to one of those universities, OR they participated heavily in an Open Source project. Very few not in one (or more) of those buckets were what I would call "top tier candidates".

Example: I pick a random POSIX-2001 function (let's not worry about all the large file cruft and other APIs that came about because some OS vendors were to lazy to implement per-thread working directories or credentials; we'll make it easy). Can you describe it's parameters and return values without looking at the man page? OK, that might not be entirely fair; random might get me something like "poll", with structure inputs, etc. -- how about if I picked 8 of them; could you describe the parameters and outputs of at least 8 of them?

I think the answer for most people on that question will be "no" - because they don't know the libraries in the UNIX Programming Environment, which are one of their most important tools. These are the people most likely to implement their own version of strncmp(3) because they don't realize that there's an existing function that solves the problem. They are the people who aren't going to realize that asprintf(3) allocated memory which they are responsible for freeing later, intil the memory leak in their code bites them in the butt.

If you want to say "But I don't program a UNIX system, I program Windows!", I invite you to explain CoCreateFreeThreadedMarshaler(

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Nutria]

the whole scope of the VPRI project (of which Nile has been of the intermediate results) is to reduce everything in common personal computing into mathematics.

Bwahahahahahahahahaha.

FORTRAN needs no replacing

[MartinD]

Geebus, FORTRAN is a great language well suited for a specific job. Just deal with it and practice your FORTRAN programming.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Kaz Kylheku]

Wow, faster AND more accurate. They must use some mystical floating-point instructions that only Fortran compiler writers know about.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[jandersen]

A: Legacy code.

B: It is good enough for the purpose.

A lot of the features that general progrmmers regard as essential parts of any program, are simply unecessary distrations. I remember one course in "Chemistry for Physicists" - all about calculating molecular orbitals - where the central data processing tool was a FORTRAN program (this was before they invented lower-case, apparently). You started the program. You input data in CSV format. You input an empty line. You got the results back. No prompts, no explanatory textx, no error messages if one of the lines contained an typo. FORTRAN was designed for the sort of mindset that finds this kind of interface desirable. Strings were originally only allowed as constants in FORMAT statements used for output.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

Most people want I/O in their language.

Ah, but: how much of this ships to end-users?

[Kaz Kylheku]

Do these scientists develop friendly graphical user interfaces for their Fortran programs?

Do these programs have robust and secure handling of all input?

How about configuration: are there dialogs for setting up preferences, which are persisted somewhere?

Do they package up user-friendly installers?

How much of their stuff runs on new platforms like tablets and smartphones?

What non-Fortran-stuff do these programs integrate with? Anything over a network?

Where can I download a scientific Fortran program to evaluate its quality?

Has anyone written a viable program of the following in any dialect of Fortran, new or old?

- operating system kernel
- device driver
- web browser
- web server
- instant messenger
- audio/video telephony client
- etc

Re:Ah, but: how much of this ships to end-users?

[serviscope_minor]

I have literally *no* idea what poiny you're trying to make.

Re:Ah, but: how much of this ships to end-users?

[Anonymous Coward]

Hey! Watch it! I had a poiny groing up!

Re:Ah, but: how much of this ships to end-users?

[excelsior_gr]

Wow, you must be the perfect example of how a low Slashdot ID an insightful comment don't make.

If you even bothered to parse the headline, you'd have noticed that the talk is about scientists using Fortran, not OS kernel hackers, not Web programmers. Fortran is totally NOT the tool for any of the tasks you mention, just like most of the other languages just suck for parallel floating-point operation intensive applications.

But since you're an old hat, I'll take a stroll on your lawn and point out the following:

Do these scientists develop friendly graphical user interfaces for their Fortran programs?

Define "friendly". I have actually seen Fortran programs that print ASCII-art-like diagrams. Sure beats having to look at GB-long tables of numerical data at runtime.

Do these programs have robust and secure handling of all input?

In all my years of experience (>10, so I guess I'm quite the novice in Fortran-years) I have not seen a single security exploit implemented in Fortran. It's just not the tool for the job. BTW if anyone can point out such a thing, please let me know so that I can raise my hat in the right direction. Now, as far as robustness goes, Fortran lets us input data in many creative ways, it would be a shame to take away such a... ahem... feature.

How about configuration: are there dialogs for setting up preferences, which are persisted somewhere?

They are called ASCII files. They are pretty persistent, and they will remember settings that, more often than not, should have been long forgotten.

Do they package up user-friendly installers?

No need. All you need to do is unzip the folder.

How much of their stuff runs on new platforms like tablets and smartphones?

This has actually been done! Check it out here:
http://specificimpulses.blogsp...

What non-Fortran-stuff do these programs integrate with? Anything over a network?

The modern Fortran versions can talk to C. Python uses Fortran libraries for math-intensive stuff. Fortran programs can number crunch across hundreds or thousands of nodes connected with InfiniBand. Network-y enough for you?

Where can I download a scientific Fortran program to evaluate its quality?

Start here: http://www.netlib.org/

And remember kids: If the old man scares you, just kick him in the nuts and run away!

are you kidding?

[Anonymous Coward]

Scientists use Fortran because it's fast and well suited to numerical computing.

Haskell and Clojure are bloated, slow, and have lousy numerical support.

Julia is a good try, but it's at best experimental at this point.

Arrays!

[amaurea]

The big thing Fortran has over C is proper support for multidimensional arrays, with powerful slicing operations built into the language. It was the inspiration for numpy arrays. My first languages were C++ and C, but when I do scientific programming, my languages of choice are now python and fortran (with f2py making it very easy to glue them together). Fortran is horrible at text processing, and has an almost absent standard library, but for scientific use, good arrays make up for that - especially when you can use python in the non-performance-critical parts.

C++ has some multidimensional array classes, but none of them are as convenient as fortran arrays. Especially when it comes to slicing. At least that's how it was the last time I checked.

Re:Arrays!

[gentryx]

Boost multi_array is pretty powerful and supports all sorts of slices.

Re:Arrays!

[J. J. Ramsey]

Boost's multi_array is useful, but it's not really aimed at numeric calculations. That's more the territory of Boost's uBlas, and even then, there are competing libraries like MTL4 or Eigen that may have better performance for that purpose.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[lgw]

None of that is good programming, is the thing.

I really wish people would stop blaming the tools when the problem is people who are tools. Maybe that's endemic to "CS types"? But those of use who code for a living in the real world recognize what you describe as a noob stunt, not a language problem.

The main reason stuff stays in fortran is the general best practice of not messing with working shipped code. If the code needs regular work, for goodness sake use a maintainable language. But lots of fortran code has been stable for decades, and only a madman would go changing it.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[lgw]

I keep hearing this "academics who will be programming their whole loves are too fucking stupid to learn new tools" stuff. Somehow I doubt it.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[lgw]

*lives

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[countvlad]

Reproducibility is part of science. So is identifying and fixing errors. But perhaps the most important aspect of science is being able to continue it.

I've worked in science labs where non-software engineers write code. They fall victim to the same problem software engineers fall victim to when they work without version control: the lose it, they overwrite it, they make mistakes and want to go backwards, they end up with 50 copies and can't remember which one was used to compile their postdoc work. And when it comes time to publish, they (may) archive it and never look at it again - despite the fact that good science should necessitate they release the code, if for no other reason than to reproduce results and ensure they are error free.

Version control is a tool. When used properly, it solves many of the above problems, all which sap productivity. In an academic setting, particularly where peer reviewed papers are being released about computationally intensive science, version control almost certainly saves more time than it creates. People just aren't willing to put the initial investment it takes to learn to use the tool.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[stenvar]

Fortran has been an "APL style language" since Fortran 95, with most of the APL operations present. That was done both for optimization and for convenience. And other APL-style languages are very popular as well, foremost MATLAB.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[K. S. Kyosuke]

Feel free to laugh.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Puff_Of_Hot_Air]

Mod parent up!

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[teg]

A: Legacy code, and because Fortran 2003+ is a very good modern language for scientific computation and maps very naturally to problems

See.... Fortran 2003 is more modern than ISO 1999 C.... Now that that's settled... How come people are still programming in languages like C/C++/Java, when Fortran2003 is available?

The GP did write for scientific computation. Fortran maps naturally to scientific calculcation, and doing linear algebra in Fortran rather than C is faster to develop, easier to read and faster to run. That doesn't meant that Fortran is a good fit for everything, I pity the developer trying to implement an SQL database or an operating system in Fortran. But for scientific computation, it's often extremely competetive.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[amck]

ALL CAPS has been optional since 1990, at least.

Fortran has had modularisation, structured code since 1990, Classes and object-orientated since 2003. Please update your prejudices.

not legacy code, well optimized math library

[aepervius]

There is a wealth of well optimized library out there, for which the mathematical result and the "error bars" are known. Porting such library and checking everything again would cost a lot of money, for what exactely ? FORTRAN is doing the job.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Blaskowicz]

Latin is even more terse than English and the words can be placed where the fuck you want. It can be well ambiguous enough!, but that's because I studied poetic latin a bit in high school. Declensions on every word save it, but mean you can really abuse it. Then being a dead language noone knows how to say "yes", "no", "hello", "thanks", "how are you doing?" and such little things.

In 17th/18th century French replaced it, with less declensions and more grammar. (and you had other such artifical national languages such as German, Italian and English)
English goes a bit too far, it's a pain to write a sentence with the word "could" which can both be read as being in the past tense or in present conditional, and no way to tell between the two (similar thing with "would". And you can't even write "I will can")

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[tlambert]

Wow, faster AND more accurate. They must use some mystical floating-point instructions that only Fortran compiler writers know about.

On PPC implementations, head-tail floating point is typically used for "long double"; this leads to inaccuracies in calculations. 80 bit Intel floating point is also inaccurate. So are SSE "vector" instructions, since denormals, NaNs, INFs, and -0 are always suspect unless you compiler emits an extra instruction in order to trigger the "next instruction after" signalling of the condition, and for NaNs, you are still somewhat suspect there.

If it isn't IEEE-754 compliant, you pretty much can't trust it. FORTRAN goes way the heck out of its way, including issuing additional instructions and introducing pipeline stalls, in order to force IEE-754 compliance.

Pretty much this accuracy only matters if you are doing Science(tm); if you are doing graphics, you are generally willing to eat the occasional FP induced artifact, because what you typically care about is the frame rate in your game, rather than being 100% accurate.

So, in closing, they're not using "some mystical floating-point instructions", they are just using accurate floating point, rather than approximate floating point.

Starting with Unsupported Generality...

[Anonymous Coward]

Starting off with an opinion, not a fact mind you, like, "When you go to any place where 'cutting edge' scientific research is going on, strangely the computer language of choice is FORTRAN,"

Then smart people realize you don't know what you are talking about and we lose their insight....

FORTRAN is used in BLAS, CBLAS, LAPACK, CLAPACK, ATLAS on Linux systems...as a start....

Stable, well used..

[os2fan]

Some of the ideas that came out of the early computing times make much more sense than the current range of 'innovations'. Most pay-ware is legacy stuff on shipping, and eventually you move from dedicated programs for doing X to well-thought-out programs that use some sort of open idiom (like spreadsheets).

I use REXX. My tendency is to use cross-platform stuff because the operating system could change from DOS to OS/2 to Windows, or whatever. Regina REXX is to be had on all platforms. Code i wrote back in the 1990's still work reliably today. Programs i used back in the 1990s have to be ever updated. A number of utilities do not have to be compiled. You can have a fancy program that factorises numbers, and then construct the number to factorise in rexx, and run the command from inside rexx, eg 'factor' me You can even have factor set to a variable, as in factor="c:\utils\factor.exe" and then write the line "factor me" without the quotes, and it will string these strings together, and run "c:\utils\factor.exe 1727999" at the prompt.

Essentially, one is going to find examples of printed code, like fortran or rexx, which one can import without modification. My recollection is that fortran does not require one to think too hard about variable kinds. A chemist is a chemist, not a computer science graduate. He's more interested in formalderhides than data type declarations.

Re:Stable, well used..

[Kaz Kylheku]

Some old ideas indeed make much more sense. But all of those still-relevant old ideas came from Lisp, and none from Fortran.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

The PROPER definition of "legacy" code is not "old code" it is "untested code".

If code is not actively being tested, it is considered legacy, this is the real world definition.

What is the fascination with replacing something just for the sake of it?

I have worked with a lot of CS people

[aepervius]

And even the "pro" make noob error from time to time out of various reason. I could list them, but let us say that even expert are not perfect programming turing complete automaton. They are human. PLus more often than not they suffer from the NIH syndrom, and from the "it must obey my standard rule" syndrom making them rewrite code or change indent variable name etc...

The main reason stuff stays in fortran is the general best practice of not messing with working shipped code. If the code needs regular work, for goodness sake use a maintainable language. But lots of fortran code has been stable for decades, and only a madman would go changing it.

No. The main reason we program in fortran is because the lirbary are known, have known error bars, known comportment , and are "provable". We *DO* reprogram every time we come up to a new problem which need to be translated. Chance is there is no standard code for what you want to simulate for your own specific problem. There are some rare case, like QM program (Gaussian, Molpro etc...) or some engineering program, but those are the exception not the rule.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[gl4ss]

legacy coders.

and scientists who really believe that it produces the absolutely fastest code because the book said so. just like ada coders who use it because it is MILSPEC because the first 10 pages of the book they learned it from were devoted to it being about military spec.

Article just not true

[loufoque]

While a lot of numerical specialists who aren't computer scientists still code in FORTRAN (or MATLAB or Python with NumPy), most cutting-edge research for large scale parallelism, heterogeneous computing and high performance computing is done in C or C++.

Even the new LAPACK replacements are written in C.
CERN is also known for using C++ extensively.

Sure, C compilers aren't always capable of performing some simple optimizations, but with C you can manually optimize as much as you want.

Re:Article just not true

[Anonymous Coward]

Sadly, some of them insisted on Java, especially in genome research. And it was *broken* Java, and they didn't report the bugs. They just ran the programs to completion, without any checkpoints in the processing where they could re-run parts of the programs and verify their results, or verify altered programs as producing the same results as old code. The result was that the "Human Genome Project", with its decades of collected data, effectively had the last five years of its data written by monkeys working on Hamlet. It's only been slowly that researchers have realized "these published sequences are *CRAP!!*" and been willing to re-run the now cheaper, but still quite expensive sequencing work to find out what the protein sequences *actually* are.

The result has been an incredible hindrance to genetic research. It's one of the reasons human genetic sequence has been so slow. The insistence on using the scoping inherent in Java, where programmers couldn't tell if they got their own version of a function or from which upstream library it was selected, led to incredible processing errors.

Re:Article just not true

[petrus4]

While a lot of numerical specialists who aren't computer scientists still code in FORTRAN (or MATLAB or Python with NumPy), most cutting-edge research for large scale parallelism, heterogeneous computing and high performance computing is done in C or C++.

You have just confirmed something, which I have suspected for a while. Namely, that C++ is the programming language of choice for psychopaths; and given that IT managers are also usually psychopaths, that explains why so many programmers are forced to use it.

Re: Article just not true

[loufoque]

R&D software engineers are not subject to IT managers.

FORTRAN

[Anonymous Coward]

It is used because it works and is extended to do the job load of the day. It evolves as necessary.
There is an enormous body of existing FORTRAN code that just keeps going. Why change when one doesn't need to ?
The problems the FORTRAN programmer works on today are expressed the same way in a computer program as the previous problems so there is no need to change the language, just extend it as necessary.
Why not change Mathematics or any of the (applied) sciences ? because it all still applies. One simply extends it.
I've done a lot of work with it and if one asks a Physicist or Statistician about using another language you'll just get blank looks.

Re: Q: Why Are Scientists Still Using FORTRAN in 2

[loufoque]

Pretty much all scientific computing benefits from vectorization. All that's needed to use it is that the code performs the same operation on multiple values of data (SIMD).

Esperanto

[Anonymous Coward]

Esperanto isn't intended to be a language without creeping grammar and jargon and never has been. I'd like a reputable source for your nonsense. There are slang words and non standard grammar gradually changing the language (key words: 'mojosa', 'na'). Words gradually change meaning ('komputilo'). Esperanto is and has been a living, changing language for 100 years.

Re:Esperanto

[Anonymous Coward]

Intended by who? You're completely wrong, since that was exactly what was intended by the progenitors of auxiliary languages (the intent of any other group than that should have been qualified), that they should avoid the irregularities of natural languages, since the purpose was to communicate without miscommunications or regional dialect between two people who speak different native languages. Esperanto specialised in its highly regular derivation and a relatively static base, and without that it's pointless.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[NdotNdot]

My personal experience with large projects:
a) flexible index bases may make it easier to write new code but they are a nightmare to maintain code that was written by multiple scientists over time
b) 1-based arrays may seem natural to mathematicians, but they lead to a significanly larger number of "-1"s and "+1"s within the code. Typically, modifying a 1-based array into a 0-based array reduces the clutter of "-1" and "+1" offsets and enhances readability.

Re:not in the field, eh?

[Mr Z]

I'd argue that if you're programming in processor-specific intrinsics, you're not really programming in C++ any more. Standard C and C++ semantics for pointers and arrays really get in the way of autovectorization. So, you have to go to language extensions and kludges (like C99's restrict keyword) to throw the compiler a bone.

Sure, tricks such as whole-program analysis and run-time alias tests can help the compiler find the guarantees it needs to have in order to vectorize. The fact of the matter (and I heard this straight from the mouths of my employer's vectorizing compiler team members) is that stock FORTRAN is simply much friendlier than stock C/C++ for this due to those semantic differences.

Our compiler will autovectorize C code if you pass it enough hints such as minimum loop trip counts, pointer alignment, pointer aliasing guarantees (aka. restrict) and so forth. Even then, there are limits to what it can do. We offer processor specific intrinsics so you can vectorize the code yourself.

Once you start coding in vector intrinsics, you're taking the vectorization out of the compiler's hands and doing it yourself. Each of those intrinsics usually maps directly to an instruction or small sequence of instructions, so there's little left for the compiler to figure out. The compiler then just schedules and register-allocates the code, and handles the non-vector bits around the edges. Sure, you still compile with the C++ compiler, but the C++ compiler is no longer providing the vectorization: You are.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[mrvan]

Missing out on what, the wonders and simplicity of using git? (/sarcasm)

...and i would like to see statistics on how many git branches are created, yet never merged back in.

which also doesn't necessarily mean anything...

I was contributing to a project and had a branch in my fork. Upstream liked the changes but wanted it split into two separate pull requests. So I made two new branches and cherry picked from my original branch. Then upstream merged in both branches by rebasing. So now I have three branches that are officially not merged back in (because not of the commits are merged, they are all cherry picked / rebased), but all changes from the three branches are in upstream and I can delete the three branches.)

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[mrvan]

Fortunately, (1) more and more scientists (also non-CS) are using github repo's for development, as most of our stuff is public anyway; and (2) It is becoming quite common to release a github page as part of a publication and is also a selling point to the editors/reviewers.

They got it all wrong

[jw3]

Speaking as a scientist with 20+ years of experience in programming: we are unlikely to choose a programming language based on its elegance, ideas behind etc. Two primary factors are (i) who else is using a given language and (ii) what libraries for that language are out there. For example, exactly 0 of the languages mentioned in the original article are used by statisticians. Haskell might be cute to write a generic program with, but in R or SPSS I have all the cutting-edge statistical tools I need for my work.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Kjella]

So one hipster CS graduate who probably thought his degree made him world champion ends up making an over-complicated cluster fuck, don't get me wrong it must be very frustrating for you but it's still very anecdotal. Particularly when it involves XML, re-indenting, renaming, copy-paste programming and all sorts of bad things that obviously is no fault of the language it was written in.

I love OOP when there's lots and lots of state and it's not going anywhere, you're constantly waiting for some event that'll trigger change like user input or network traffic or you have some kind of database or file system watcher. Using global state or dragging the whole old state over into a new state because you make a tiny little change seems horribly awkward to me, it's like passing every object's state as function parameters just to make it functional. And trying to fake OOP in non-OOP languages like C the result is simply horrible, it's like agreeing that a hammer would be the best tool to pound in this nail but insisting on using a flat rock instead for religious reasons.

What I miss in imperative programming is a good way of saying that these odd, different things can be done in parallel. Like if I want to set the table I want to add a plate, fork and knife but the order is really irrelevant. Now maybe I want to add a napkin on top of that plate, but it depends only on the plate. It's more like a gantt diagram with dependencies than a straight start-to-finish order. Still, on the micro level most things are imperative - I have to open the drawer before I can grab a fork, not the other way around so I don't want to program through dependencies, also because of resource contentions and race conditions that you don't realize. I'd rather try to specify some degree of parallelism than specify all forms of non-parallelism.

One of the great weaknesses of imperative programming is that you often want to leave it in a known state. For example imagine I have to grab the fork and knife from the same kitchen drawer. Very often the "grabFork()" will open the drawer, grab the fork and close the drawer. So will the "grabKnife()" function. Obviously there's optimization potential here, really you'd only need to open the drawer once. But if you want it to close again, you'd need some kind of refcounting to know when we've grabbed all we need and can close it again. Obviously in this simple case we can implement a "grabForkKnife()", but what if others are preparing a coffee table with spoons from the same drawer in an entirely different process? I find expressing heterogeneous parallelism hard in all the current tools I've seen, it's not that hard in real life.

Re:not in the field, eh?

[shutdown -p now]

They may well share the same optimizer, but the optimizer can only do so much, and the tighter you constrain the memory model (in particular, aliasing), the better the optimizer can work. Fortran constrains its memory model much tighter than C and C++ by default. In particular, all pointers in C and C++ have to be assumed to be aliased by default; C99 added 'restrict' to work around that, but you have to not forget to use it, and C++ doesn't have anything equivalent at all.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Terje Mathisen]

Fortran has had "higher-order array operators" for _many_ years now (see FORTRAN 90), but even without this most Fortran code is written using simple iterative operations over arrays, with explicit multi-dimension indexing. This tends to make the auto-vectorizers job much simpler.

As the AC noted, Fortran has pretty much no aliasing issues at all, unless you go out of your way with COMMON blocks, this makes it far easier to optimize the code.

Terje

Re:not in the field, eh?

[serviscope_minor]

What?

No that's incorrect.

Both types of compilers attempt to produce *correct* code. Any code written to the standard should come out correct. The C standard specifies strict aliasing in that a float* cannot alias an int*. In C if you violate the standard and pull such aliasing tricks, the compiler is allowed to make your code do funny things, just as if you break other rules like using a poiter after a free, or returning a pointer to a stack allocated variable.

In C, the compiler cannot in general assume that two float*s do not alias without being incorrect. Fortran to a much larger extent can, hence it's faster performance.

C99, and not standard C++11 also has type annotation, restrict which can tell the compiler that two arbitrary pointers do not alias (and woe betide you if they do) and this recovers some of the speed against FORTRAN.

This has nothing to do with compilres sacraficing correctness at all.

Because...

[Anonymous Coward]

...Fortran 90, if you avoid all the old Fortran 77 cruft, is a really nice language. It is clear, concise, and great for writing high performance scientific code. Its array language is second to none.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[fahrbot-bot]

Fortran (yes, that's how it's spelt now, not "FORTRAN")

Actually, FORTRAN -- the original -- is an acronym derived from Formula Translating System, so I'm sure all upper case is still also acceptable, unless you have a bug up your butt.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

I fail to see the point of requiring someone to register an account or identify himself just to express an opinion.

Unless you wish to shoot the messenger, which makes the conversation feel quite repressive.

Costs down the road

[leptonhead]

A previous comment suggests that the lifetime of most FORTRAN code is not necessarily that long (requiring scientists to publish their code might change that). If this is indeed the case, you have a point. However, most programs live very long indeed (several decades is not at all exceptional), so the productivity of the original author is not that important. If we would look at the cost over the lifetime of the code (including testing, debugging and operational cost of bugs), I think there are significant differences between languages.

Re:not in the field, eh?

[Anonymous Coward]

There is more to that. Semantic side effects prevent many optimizations or make them very hard so the speed of the assembly generated can depend on the language.
This is why there are benchmarks where Java is faster than C.

Also:
I don not buy the legacy code argument as you can use Fortran libraries in other languages.

Re:not in the field, eh?

[Anonymous Coward]

I have some experience with this, so I'll chip in about performance.

Modern Fortran produces rather tight machine code, however so does C++. I haven't seen a case so far where Fortran produces measurably faster code, and of course you pay a price in that Fortran is less readable.

Most Fortran code is not modern Fortran, but Fortran 77 or even older and won't compile on modern Fortran compilers. Most new scientific software is written in C++ or even in Java or Python for example, since performance doesn't always matter that much and ease of maintenance is also important, especially for people who'd rather spent their days thinking about physics than debugging software. Fortran code is almost always legacy. I've seen Fortran IV in the late nineties, believe it or not.

Most of the time the real performance bottlenecks are either I/O which you can do fuck all about, or the kind of nested loops that happen inside Fourier transforms and such things. For the latter you almost always use a library, which tends to contain better optimised code than you could ever write yourself.

I find it curious that the summary stresses speed as the advantage of Fortran, not just because in practise C++ is just as fast or sometimes faster, but because nowadays performance of modern languages is generally good enough. When selecting a language you care more about readability, maintainability, does it interface with our discrete maths library, will it allow us to slap together a GUI in an hour so our intern can use it to take measurements on the Big Machine, will the next generation of graduates be able to work with code without retraining, and so on. Practical questions, not theoretical ones like which is faster.

Re:not in the field, eh?

[jones_supa]

I am not a programmer. Wanted to be. Too late to start I think.

Garbage! You can start programming in any age just fine. :)

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Kaz Kylheku]

So, Fortran issues extra instructions and pipeline stalls for accuracy, yet manages to be faster.

That is amazing!

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[nickol]

That's wrong. Aliasing in FORTRAN is exactly the feature that can make optimization very difficult or impossible. Aliasing was invented because computers had small memories.
I've just finished a project in FORTRAN in geophysics, so I have some experience with this language. Why it is still in use? The answer is: scientists know it. No other reason. Projects in FORTRAN are very hard to maintain. Refactoring is also difficult. Half of the project was in FORTRAN, other half in C++. On any feature request we had a meeting to decide whether we are going to implement it in C++ or in FORTRAN and how the interface will look like.
FORTRAN _may_ have better efficiency in some cases. For really simple programs with no memory management and no hardware interaction.
I think that FORTRAN is a good language, but it is also an old language.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[fractoid]

He handed it over to a computer science graduate (i.e. a non-physicist) who really liked all the modern trends in CS.

Why was a graduate fresh out of university put in charge of architecture decisions? You wouldn't put an apprentice in charge of a mechanical workshop and expect them to keep it tidy and efficient, this is no different.

It's my general experience that it takes 5-10 years of commercial experience before someone is capable of making wise architecture choices about small standalone apps, and 15+ before they'll have a hope in hell of doing anything non-destructive with a large legacy application.

Re: Q: Why Are Scientists Still Using FORTRAN in 2

[ceoyoyo]

Doctors don't use Latin. They use their native languages and a bunch of proper nouns that happen to be Latin (or Greek) words or phrases.

Latin (or Greek) used to be the language of academia because it's what the Greeks used and the Romans translated the Greeks into. And the church loved Aristotle and ironically, the church pretty much defined western academia.

Re: Q: Why Are Scientists Still Using FORTRAN in 2

[ceoyoyo]

Interesting. In my experience, rewriting the code is almost always a better approach than making the old stuff work. The old stuff was likely written by a grad student who didn't know much about writing code, to function just well enough to perform his experiment. Perhaps it won't even compile on modern hardware and you need to keep that G3 or SGI running.

There IS some very good, quite old code, mostly written in Fortran, that's been optimized by people who know what they're doing over the years and isn't worth messing with. But it's very different from the spaghetti that grad student wrote ten years ago so he could publish a paper and get a degree.

Re:not in the field, eh?

[angel'o'sphere]

This may have been true decades ago and may still be true in special circumstances. As a general asumption it is wrong. The boost math for C++ clearly show that. Also high performance scientific computing in Java is pretty close to C and FORTRAN.
There is absolutely no reason a simple matrix multiplication should yield different machine code if coded in C versus FORTRAN.
Traditionally however FORTRAN usually recognized vectorization versus scalar operations and used vector operations if the platform supported that and also changed the memory laout of matrices e.g. to take advantage from vector ops. C on the other hand was only needed to compile the fortran compiler etc. ;)
That gcc is creating rather slow code is not surprising considering its history and the amount of platforms it supports. Lets see in what direction LLVM is moving and if they can avoid those pitfalls.

Re:not in the field, eh?

[angel'o'sphere]

you are spouting off about a field in which you do not work, against a well-known fact.
This "well known fact" is decades old and outdated. C++ with booth math libraries is as fast as FORTRAN and often faster. In our days where most computers use general purpose processors (versus vector processors) with a few added simd instructions the difference is mot really existing.

Doing the quite common operations of numeric analysis, machine output of the C compiler will be worse, less optimized, slower than that of Fortran.
That is nonsense in two ways: first there is no reason at all that a simple loop over floats is faster in one _language_ that means: is compiled to different machine code, than in the other. Second optimization is exactly the same, at least on machine code level. I doubt there is any optimiization a fortran compiler can make versus a C compiler as long as we only look at math operations in loops over vectors or matrices. There is definitely no fundamental reason for one being faster than the other. Only perhaps that C compiler vendors don't care for maximum math performance.

...and don't forget C

[silacoid]

I just find it silly when C programmers question why one use Fortran in 2014. The more interresting question is why anyone use C in 2014. It's a language with 3 main design requirements:

- be easily compileable by a compiler that had only 2k of memory

- be able to make PDP11 assembly cross-compileable

- otherwise, delegate most of the work from the compiler to the developers, since developer time was cheaper than CPU time.

None of those requirements are valid in 2014, and it's insanely far behind other languages and current theory on all areas.

Re:...and don't forget C

[Desler]

People still use C for its wide portability. x86 is not the entire world. Micro-controllers with 2k of RAM still exist and are used all over the place. So what do you expect them to be programmed with? Also C89, C99 And C1x have long since evolved beyond Dennis Ritchies' original goals of what C was meant to do. That argument is especially stupid.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[jellomizer]

Legacy code is one part. Non-Computer Scientists in general do not like to write code they much rather adjust an existing program and go on.
Performance is the next part. The newer languages that are considered easy to code: Java, .NET, Python, Perl... Are all interpreted languages and run slower. If you are going to be doing a bunch of number crunching you really want your computer to be focusing on running the program. Not interpreting your command then running what you said.

But Fortran is not faster than C

[Anonymous Coward]

The article mentions strict aliasing as an advantage of Fortran, but C has had strict aliasing optimizations by default since forever ago.

Everything Fortran does, C can do better.

Re:not in the field, eh?

[Anonymous Coward]

so what you're saying is that FORTRAN's mutlidimensional arrays allow the compiler to beat your crude attempts at optimization with SIMD. Use your cute toys for web pages, use a real language for a real computer.

Oh, and when you really want deterministic performance, FORTRAN doesn't need a virtual memory machine.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

No shit, moron. That doesn't change the fact that the standard now spells it "Fortran."

K. S. Kyosuke doesn't like your "software", eh?

[mmell]

Too bad. I'll bet you thought the ability to scratch together a hostfile editor made you a real programmer, eh? Too bad nobody will ever take you seriously. Too bad your software is just a worthless kludge (unless you need to hit up the dark markets, that is). Too bad nobody registered here has any respect for you whatsoever. Just Anonymous Cowards - but I'm pretty sure that's just you, typing madly as fast as you can to create the illusion that you're not actually all alone, friendless, unrespected, unloved. Your imaginary lovers, to be sure.

Yes, too bad. I suppose there are a lot of things that went into this. I suppose we can't even blame you; only pity you. I'm guessing you have no friends out in the real world. It must be hard, doubly hard, to learn some basic programming skills, work hard on writing stuff only to have the world tell you why it's useless. Most of us could fall back on friends, learn to do better, but you - all you can do is scream and yell impotently on the reddits and the slashdots of the internet. Tell me, do you suffer from some physical disability? The level of vitriol you bring to the boards tells me you probably are helpless to defend yourself in the real world. It must be terrible to be almost as impotent here in the online world, the one place where you actually had a chance at being a peer, an equal; only to be relegated even here to the status of a punchline. They took your lunch money and beat you up in school. College was even worse - watching guys with more muscles or more money or just better looks get all the girls, everyone laughing at the geek. Worst was the real world - nobody even pretending that you belonged, nobody ever willing to let you prove that you could actually be important.

How am I doing so far? Tell ya what - log in as a registered user here at Slashdot before you post replies, I'm sure people here will respect that act by itself. Just don't expect us to fall all over ourselves showering you with praise because your magnum opus software project is of no value to the vast majority of the other registered users her at Slashdot. Be ready to read a lot of unpleasant posts. Behave like an adult, you'll be treated like one. Behave like a child, you'll be marginalized and ignored just like you have been all your life.

Re:K. S. Kyosuke doesn't like your "software", eh?

[Anonymous Coward]

Perhaps K.S. kyosucky and your shouldn't have trolled apk first (which you did, I can read you know. Your lying cries of pity me don't work with those of us that read). You show you can dish it out but you can't take it in return. That makes you a punk.

Re:K. S. Kyosuke doesn't like your "software", eh?

[mmell]

Read further. APK definitely started the whole show. It's what emotionally deprived children do.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[wispoftow]

I am embarrassed. You cited my alma mater's course catalog and proved me wrong (a decade ahead of my time, though) :-)

Its not strange

[nurb432]

Most scientists like to use tools that work, and they are proficient in.

FORTRAN falls under both categories.

Perl of the timesharing age, a real Adventure!

[TheRealHocusLocus]

FORTRAN was -- for some still is-- the 'Perl' of scientific computing. Get it in and get it done... and it doesn't always compile down very tight, but always fast because for mainframe developers getting this language optimized for a new architecture was first priority.

At 15, the first real structured program I ever de-constructed completely while teaching myself the language, was the FORTRAN IV source for Crowther and Woods Colossal Cave Adventure, widely regarded as 'the' original interactive text adventure, a genre which would later go multi-user to become the MUD. Read about it here, or play it in Javascript.

Crowther's PDP-11 version was running on the 36-bit GE-600 mainframes of GEISCO (General Electric Information Services) Mark III Foreground timesharing system... this is in the golden age of timesharing and no one did it better than GE. It took HOURS at 300bps and two rolls of thermal paper to print out the source and data files, and I laid it out on the floor and traced the program mentally, keeping a notebook of what was stored in what variable... I had far more fun doing this than playing the game itself.

FORTRAN IV and Dartmouth BASIC (I'll toss in RPG II also) were the 'flat' GOTO-based languages, an era of explicit rather than implicit nesting -- a time in which high level functions were available to use or define but humans needed to plan and implement the actual structure in programs mentally by using conditional statements and numeric labels to JUMP over blocks of code. Sort of "assembly language with benefits".

When real conditional nesting and completely symbolic labeling appeared on the scene, with good string handling, it was a walk in the park.

Re:Perl of the timesharing age, a real Adventure!

[Anonymous Coward]

FORTRAN was -- for some still is -- the 'Perl' of scientific computing

So, essentially you are saying nobody can read anybody else's Fortran code, and it's a horrible choice for a team project, or anybody with a sense of professionalism that understands programming languages?

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

Legacy coders.

The real reason is science is filled with tons of old men that refuse to learn anything new.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

optional since at least Fortran-77

Why are scientists still using LATIN in 2014?

[biodata]

In the cutting edge world of biological research scientists are still using the ancient language latin to name, classify and describe species of organism. The thing is why would they change?

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

Thank you. This is VERY WELL SAID. If it ain't broke, don't fix it. All the "improvements" lack the elegance and clarity of FORTRAN. It is one of several languages for which no worthy successors have yet emerged.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

Let's be real: just about every Fortran code I've heard of is still limited to F77 (with some F90 if you're lucky). It just won't work on later versions, and it's deemed not worth porting over, so the entire codebase is stuck on almost 40 years old code.

Then you have no idea of how to do anything in Fortran. All (except two things no one really needs) Fortran 77 code is still valid in modern Fortran 2008. (Yes, even Fortran 90 is freaking obsolete.) There is no problem of combining fixed and free form code, just put them in separate files and voila, it works just fine.

Stop the presses

[Anonymous Coward]

A programming language expressly designed for numerical calculation is better at numerical calculations that a language designed for systems programming.

Strange indeed

[Anonymous Coward]

> where 'cutting edge' scientific research is going on, strangely the computer language of choice is FORTRAN

What an absolutely moronic statement. Strange indeed, maybe because scientists aren't interested in the latest fashionable language, and fortran is the best tool for the job?

Jesus, submitter is an ignorant fool.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[mark-t]

Because that correctness comes at a cost... a small loss of speed.

Fortran code ignores the very possibility that pointer content can overlap. Modern compilers do not.

Input validation

[tepples]

Huh ? ... why would you write the same application logic on both the client and server ? ... isn't that, by definition, repeating yourself ?

The point of DRY is that you don't write the same application logic twice. You write it once and then use it twice. For example, you'd write validation logic, and then you'd use the same logic to validate on the client before POST that you use to validate on the server after POST.

The 'front-end', on the client, cares about fundamentally different things than the 'back-end', on the server.

For a large part, this is true. But end users have come to expect input validation to happen in part locally before submission, in order to avoid a round trip possibly longer than a second after every submitted change.

Re:not in the field, eh?

[mark-t]

The C standard specifies strict aliasing in that a float* cannot alias an int*.

In C, if I am using a float variable, and then write some other content into the memory occupied by the float without using the variable (possibly a bit pattern that corresponds to a specific float value) and then try to use the float again, its content will have changed... which is the correct behavior, because that's what was instructed. In Fortran, with appropriate speed optimizations enabled, the compiler does not assume this is possible, and the float variable may not necessarily appear to be changed when it is used after the memory it supposedly occupied was overwritten (in Fortran, you'd generally have to do some weird tricks to even make this happen without explicitly using a union type which would disable such optimizations in the first place, while in C all you would have to do is cast a pointer to a different type).

K. S. Kyosuke gets called out & ran

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke = "Run, Forrest: RUN!"

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

Re: Q: Why Are Scientists Still Using FORTRAN in 2

[Anonymous Coward]

This is the same reason they write math formulae as a jumbled mess of greek characters. Legacy code.

K. S. Kyosuke gets called out & ran

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke gets called out & ran

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke gets called out & ran

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke = "Run, Forrest: RUN!"

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Xyrus]

I would also hazard a guess that Fortran tends to be a tad easier to read than C... Especially for scientists...

The way scientists write code, it doesn't matter what language they use it will still come out an undecipherable mess. You'll have a quintuply nested loop populating an array call tlnb1 in a function called abn that takes 8 arguments named t1 to t8. The only documentation will be a single comment just before the loop that says "This should work now".

If you're going to be working with scientific code you'll need at least a Master's degree in software archaeology and software anthropology.

Where's:K. S. Kyosuke's program(s)?

[Anonymous Coward]

They don't exist either. I googled that mere talker. No action or programs.(like you mmell). Quit projecting your own issues.You BOTH RAN like scared little wenches when challenged by apk (a real programmer who has actual wares out there commercially).

Re:Where's:K. S. Kyosuke's program(s)?

[mmell]

Well, at least that was original.

Running? I can be reached as follows:

Michael S. Mell

1725 Associates Drive

Dubuque, IA

I'm tired of arguing. Any time you want to debate these issues, feel free to come talk to me in person. Or file a libel suit in court - I've given you the information you'll need to have me served with a subpoena. Just don't count on your Mommy to come to your rescue when you're beaten.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Xyrus]

ALL CAPS has been optional since 1990, at least.

Fortran has had modularisation, structured code since 1990, Classes and object-orientated since 2003. Please update your prejudices.

And the scientific community is a good 20 years away from effectively utilizing such goodies the steering committee has accepted because software maintainability is often a secondary concern. Scientists aren't software engineers and very few of them I've worked with want to bother becoming one. If the code works, that's enough for them.

Bwahahaha, K.S. Kyosuke != programmer

[Anonymous Coward]

Ask him to show he's coded a program that did well enough to become commercially sold. Go on, ask. You'll get back zero from that zero. Look on Google. You get zero. He's a wannabe!

Blowhard: Show us commercially sold code

[Anonymous Coward]

You can prove you wrote. There isn't any, is there? Big talker wannabe = K.S. Kyosuke, nothing more.

K. S. Kyosuke = "Run, Forrest: RUN!"

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke gets called out & ran

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

We're using up to F95 in our code (~500000 lines IIRC) with only the solver (which we didn't develop ourselves but only modify existing code) being F77 (a nightmare to read). Many of the F03 features would come in handy but, alas, the compilers on some of our target architectures don't support it.

IMO Fortran is quite OK, still I prefer C/C++.

Mmell's like K. S. Kyosuke (both run)

[Anonymous Coward]

Mmell: Yer bein' called out. Why ya runnin', "forrest" http://tech.slashdot.org/comme... ?

Blowhard: Show us commercially sold code

[Anonymous Coward]

That you can prove YOU wrote: There is none. Big talking wannabe = K.S. Kyosuke, nothing more.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Xyrus]

Your problem began when you turned the code over to an inexperienced CS graduate. You don't need to be a good software engineer or even a good programmer to get a degree in computer science. I wish people would stop conflating the two, especially the people in the HR department. :P

You needed a SOFTWARE ENGINEER. Worse, you needed an experienced software engineer familiar with the domain. Instead you handed it over to a fresh graduate who maybe had one or two courses on engineering. What exactly did you expect to have happen?

And what about you? Did you give them a good set of requirements? Did you have frequent reviews? Or did you just drop it in his/her lap and say "make it better"? There's a lot of missing details on exactly how you participated in the process. Again, if you weren't actively giving feedback into the process then you shouldn't be surprised when it isn't what you wanted.

The failure in this case is yours. Next time you need work done, I suggest actually getting the right person for the job and not some cheap fresh grad who happens to have "computer" in their degree description.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[mrchaotica]

That's just for the keycaps. You have to buy the rest of the keyboard separately (for something like $100).

Re:not in the field, eh?

[frank_adrian314159]

... although it is certainly faster, the resulting code will be less robust than code output by a modern most modern C compilers.

This is the best you've got? That some how C is more correct than Fortran? Doesn't seem that way to me. Last I checked, there were very few differences in Fortran or C's numeric operations, both mapping almost directly to whatever the underlying architecture wants to do with the operands, both silently ignoring integer over-/underflow. Both have language primitives (or extensions) that allow you to manufacture a raw pointer to anywhere in memory and allow you to write anything to that address. Any language that lets you do those things without great angst cannot be called "robust" in any normal sense of that word. "Adherent to the spec" is about all you can say of it.

Choice of language is secondary

[gweihir]

Yes, FORTRAN sucks, but it is stable, fast and well understood. It runs on a number of supercomputer architectures. It is way easier to program in FORTRAN than in C for non-CS people. So what is the issue? Oh, maybe that this is not a "modern" language? Here is news for you: Java sucks a lot more than FORTRAN.

Only one problem with Fortran...

[frank_adrian314159]

No one knows how to spell it. In these threads I've seen Fortran, FORTRAN, ForTran, etc. Who the hell can keep track? That's why C is winning! One letter, upper case, C. No muss no fuss. Not to worry, PL\I had the same issue (Forward or backward slash? Better go look it up!) Same with LISP, LisP, Lisp, (or, these days, scheme, Racket, Clojure).- too many letters, too many ways to misspell them. D avoided falling into this trap, but which would you rather have on a paper? A D or a C? And C++ doesn't even look like a real grade? Python? Are we naming a language or a comedy troupe? Same with Ruby - I don't need a bunch of freaking geologists telling how to use a computer.

Jeez, everyone, C just got it right where it counted - its name. Now can we just all agree to use that and move on?

Good point

[davebarnes]

Thanks

I love FORTRAN

[davebarnes]

I refuse to spell it Fortran.
It was FORTRAN when I learned it as my first computer language in 1965 in high school.

Re:not in the field, eh?

[dumael]

Language semantics are the real difference. To get comparable semantics in a C program and a Fortran program solving the same problem, the C program has to use the "restrict" keyword everywhere (or nearly everywhere/or where it counts). Fortran by default disallows aliasing (the purpose of restrict) in contrast to C.

Location aliasing inhibits intermediate code[1] optimization as the optimizer cannot assume that two pointers point to difference locations. If the optimizer can safely make that assumption it can do more with the code.

Aside: during my compiler design class, the lecturer spent time going over some optimizations (obviously). Towards the end of the lecture: "oh but if p aliases q, you cannot use that optimization".

[1] Any compiler worth its use translates input files into some form of intermediate representation for optimization purposes.

Amazingly ...

[Rambo Tribble]

... many programmers still communicate in English, (or German, French, etc.), as well. Of course, English has changed over the last fifty years, but then, so has FORTRAN. The time really is ripe for the Esperanto/Haskell movement to take the world by storm.

Re:Amazingly ...

[jnm11]

Most of the comments here are completely ignorant and referring to Fortran from the 70s and 80s. Modern Fortran is by far and away the best language for most high performance computing. Arrays and Matrices are first class objects in the language so the compiler has much more information to go on and debugging is much easier as bounds can be properly checked. c is a great language for many applications but for most HPC nothing comes close to Fortran.

Re:Amazingly ...

[Rambo Tribble]

Well, if one were to be prevented from arguing on the basis of ignorance, most political commentary would be banned.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[dumael]

> Fortran code ignores the very possibility that pointer content can overlap. Modern compilers do not.

Fortran's language specification doesn't allow pointers to overlap. Inhibiting programmer freedom in this way ironically gives the compiler greater freedom to perform optimizations.

In contrast C & co, give the programmer this freedom, resulting in the compiler having to be more conservative.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[mrchaotica]

Eh, the original works too (especially for robotics)!

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

> No making pointers/references to things which aren't designed to be referred to multiple times

C++ works best IMHO if you use C++, STL, passing by reference to avoid implicit copies (or reference counting), and suitable matrix and other numerical libraries as well so you can minimise the use of pointers in your own code. But then optimisation of this code by the compiler may not be as easy. If the matrix and linear algorithm code is ultimately using hardware optimised BLAS, LAPACK, ATLAS and so on then that shouldn't be too bad, though. You can abstract things with C too, but you have to work a bit harder.

Re:not in the field, eh?

[mark-t]

If you alias one type of object to another through pointer casting in C, and change what is there through the other pointer, when you access the original, the value will have changed. This is the correct behavior (however implementation-defined) because those are the steps that were given. Fortran, when producing optimized code, will not do this unless you use a union type, which explicitly disables such optimizations in the first place.

Using the restrict keyword causes modern C and C++ compilers to produce code no slower than Fortran.... but the side effect of using the keyword is that pointer aliasing will have unexpected side effects, just as it would in Fortran.

The fact that the side effects of pointer aliasing are often not what a programmer may have intended does not change the fact that those effects are still what the computer was instructed to do, and therefore the correct behavior. Compensating for such side effects is what makes more recent compilers produce slower code without the usage of optimizing that allows such side effects to remain unaccounted for.

mmell: tell us how vi can stream data

[Anonymous Coward]

LMAO & how it can reverse dns ping sites to determine their IP address as was asked of you http://slashdot.org/comments.p...

Re:not in the field, eh?

[serviscope_minor]

In C, if I am using a float variable, and then write some other content into the memory occupied by the float without using the variable (possibly a bit pattern that corresponds to a specific float value) and then try to use the float again, its content will have changed... which is the correct behavior, because that's what was instructed.

No. If you write to that location using a float* (or char* which is allowed to alias anything) then the compiler must not assume that the value has not changed. If you write to that location through an int*, it is entirely legal for the compiler to not bother re-reading the memory and to instead use a cached value.

This is known as strict aliasing and is speified by the standard. With -O3, gcc will perform optimizations under the asusmption that the user is not breaking strict aliasing. If you do, your program is not legal C code, and so the compiler is free to give you anything it wants to.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Puff_Of_Hot_Air]

To be fair, you basically set this kid up for failure. What you describe is a significant engineering challenge, and you gave it to a computer science graduate, with no experience. If you gave this to someone with 10 years under their belt, I'm sure they could create a lovely maintainable package; but as it is, you should start over. You may as well have asked him/her to design the Golden Gate Bridge. Computer science does not teach engineering, there is no way this kid could have had the necessary skills.

Re:not in the field, eh?

[Anonymous Coward]

A case in point would be that with boost's ublas implementation, for example, you can specify in an equation A = B * C that the A has no other alias to give the compiler more of a chance by changing the code semantics in the template library.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[mark-t]

Exactly.

Because you are a naive nanny?

[Lawrence_Bird]

Fortran is still used because it works. Becuase it is fast. Because libraries are optimized and well understood. Fortran is still used because gasp it has evolved since FORTRAN 66 and FORTRAN IV. Maybe you and the other language nannies always forcing latest greatest buzz on the rest of us should take the time to actually read about some of the most recent versions?

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[mrchaotica]

If you want to say "But I don't program a UNIX system, I program Windows!", I invite you to explain CoCreateFreeThreadedMarshaler(), and when and why you would use it, when writing multithreaded Windows programs.

But I don't program in either; I program in ASP.NET -- wait, no, I don't even do that: I program against the project-specific API that my more senior coworkers wrote on top of ASP.NET. (Actually, that's not even true either -- there are 3 fucking layers of APIs between me and ASP.NET!)

Now, given all that, please explain to me how the fuck rote memorization of POSIX APIs would have done me any goddamn good at all?!

(This is not to say, by the way, that I'm not also familiar with the POSIX API -- I had to know it for my advanced operating systems (e.g. threading, scheduling, RPC, etc.) and computer graphics classes back in college -- but learning it was tangential to the purpose of learning advanced operating systems and computer graphics respectively, not the goal in and of itself. And that's exactly the way that it should be!)

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[igny]

You confused Fortran with Cobol. Yes, Cobol would stick around for decades because of legacy code in all the banks, insurance, government and other institutions.

On the other hand, Fortran is also a language of choice for cutting edge research where no legacy code exists and program development is done from scratch.

Re:not in the field, eh?

[mark-t]

If you write to that location using a float* (or char* which is allowed to alias anything) then the compiler must not assume that the value has not changed. If you write to that location through an int*, it is entirely legal for the compiler to not bother re-reading the memory and to instead use a cached value.

These two sentences seem to be saying exactly the opposite. If the compiler does not ever assume that the value has not changed then it may assume that it *HAS* changed, and would not use a cached value. This is the normal behaviour in C. You can get the latter with certain optimizations enabled, but in cases where you do, the code won't perform any worse than Fortran produced code anyways. Even then, a modern compiler may be able to detect that a person has used pointer aliasing in a context and disable those optimizations in that context, while in Fortran, the language structure does not permit such things to happen, and thus produces code that makes the assumption it will never happen.

The optimizations that Fortran makes can be explicitly disabled by using a union type, but then it will not ever be any faster than what a C or C++ compiler could produce for manipulating such values.

Nobody has invented something better.

[Anonymous Coward]

There is no language, that is not interpreted, that is as good as Fortran for scientific computing. Yes, when it was invented it was just gotos and arrays, but it used matrices. Unlike C, where you had arrays of arrays, but a good programmer would use indexing like A[ncols*i+j]; which would create errors always, always, always.

People invented new languages that improved upon fortran, but the only thing they did was to give good ideas to fortran to become better. For example, today fortran has array slicing built into it, the same array slicing that matlab has. After using it with matrices operations, I have never been so happy. I can use matrices in a way that makes everything so much easier, clearer, and shorter. I have changed codes with 100 lines to 10. Do you know how important this is if your simulation has a small glitch? If somehow the fluid goes into space and you don't know why? There is a big difference between general code and numerical code. In general code, if you have an error you can start asking yourself where that error might have started. Where am I adding something to the string? Where am I initializing stuff? Etc. Make a bad operation in one of the 100 lines of code that contains many long formulas, and you will cry blood, because you can't just see the number 1.45560e10 in an array of millions of numbers and say... Well, the error seems to have started here.

Fortran

[Anonymous Coward]

I tried Fortran about 7 years ago but I couldn't find a decent GUI for Windows XP. Maybe I was looking in the wrong websites. I just want to create a simple "Calculation" program that performs mathematical calculations. The dialog box should have with a menu and a command button that closes the window.

Re:not in the field, eh?

[rubycodez]

we're not talking about simple loops here, would you happen to know what solving a tensor calculus problem by numeric methods entails?

Re:not in the field, eh?

[rubycodez]

the famous c++ numeric projects have massive blocks of compiled fortran code in them

Re:not in the field, eh?

[rubycodez]

we're not talking about simple matrix multiplication though. The boost math toolkit doesn't prove anything by its mere existence, that's not how the big boys do numeric methods.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[jedidiah]

Latin and ancient Greek was taught because most of the great works were ancient and written in those languages. Only unitl the end of the dark ages did European academia recover enough to make native language works more relevant. Also, Latin was still used by what remaining social order existed. It was not quite dead.

Even today, you might want to learn some other language in order to gain better access to academic works in their original form.

Re:not in the field, eh?

[raxx7]

I suspect Fortran makes it easier for compiler writers, but for the compiler user the difference is tiny.
Both GCC and ICC can vectorize the following piece of code, by generating code with a run-time check for aliasing and two paths: a vectorized path and a scalar path.

This code is pretty trivial, but I think the method is valid for most(all?) possible uses of Fortran arrays.

In my experience, with a bit of care in code writing (and reading the compiler's vectorization reports), ICC can vectorize pretty complex, but readable, standard and portable, loops.

void f(int n, float *a, float *b, float *z)
{
        int i;
        for(i = 0; i

Re:not in the field, eh?

[raxx7]

stupid me... forgot the tags

void f(int n, float *a, float *b, float *z)
{
        int i;
        for(i = 0; i &lt n; i++)
                z[i] = a[i]+b[i];
}

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[StripedCow]

They have no idea about the physics or maths involved (which is the difficult part)

Wrong. The physics and math are the easy part. They are well-documented in books and papers.

The programming and architecture, on the other hand, is the hard part.

Ever seen a textbook on physics without one error? They exist.
Ever seen a program without one bug? No need to answer this.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

"Accurate floating point" is an oxymoron.

FORTRAN goes out of its way to keep IEEE-754 compliance, true, but that's to get reproducibility across machines (i.e. the _same_ inaccuracy for a given calculation).

If you look at the foundational libraries for most FORTRAN programs - LAPACK, SLATEC, etc., you'll see a huge amount of effort going in to keeping iterative calculations numerically stable across floating point values, and in to making sure error terms are bounded and deterministic. The authors were very much aware that FORTRAN could not and cannot 'force' floating point calculations to be 'accurate' to any reasonable degree.

Re:not in the field, eh?

[InfoJunkie777]

I am not a programmer. Wanted to be. Too late to start I think.

Garbage! You can start programming in any age just fine. :)

You are right. I want to learn Javascript. I know there is no typing. But useful for what I want to do: web page creation.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[camperdave]

And you can't even write "I will can")

I will can the peaches tonight. What's the problem?

Re:not in the field, eh?

[Mr Z]

i did give a proviso for run-time alias checks in my comment above. Our compiler will also generate a run-time check for that as well, with a small codesize and runtime cycle penalty.. The FORTRAN equivalent doesn't need the alias check.

I'd expect ICC to be very aggressive, given that Intel has one of (if not the) largest paid, full-time compiler team in the world.

So how about all of FORTRAN's other nifty features, such as array slices? To get the same functionality in C / C++, you have to put explicit strides and bounds everywhere, and sometimes checks to reverse loop directions. In FORTRAN, you can write things like "A(1:100,1:200:2) = B(101:300:2,51:150)", and the compiler is free to choose the best way to do it.

In C / C++, you leave it to the programmer to dictate the loop explicitly and hope the compiler can figure out what you're doing. In my experience, real world programmers get unusually creative with this task, creating awful code. If you write clearly enough and pay enough attention to compiler vectorization reports or other feedback, maybe the compiler + user eventually figures it out. Realistically, most programmers aren't that sophisticated. And even among the ones who are, not all have the time or inclination.

Looking back to my array slice example: Now take those slices across function call boundaries in both languages and see how much work the programmer has to do in each language...

My point is, the more work the programmer has to do to help the compiler succeed, the more evidence it's a poor fit for the problem domain. FORTRAN can make it easier for compiler writers because they start with a higher level specification of what the programmer is trying to achieve. FORTRAN also makes it easier for programmers because they stop at that higher level specification of what they're trying to achieve.

the reason is

[Anonymous Coward]

that when you need quadruple precision complex Bessel functions it's nice to have it built into the language.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[aztectemple1]

A: Legacy code.

Computer science comes up with new languages like a flavor of the month. Fortran is the common language of scientific programming. Computation intensive scientific problems such as electronic structure are as old as Douglas Hartree (i.e. predates computers). These problems can take (and have taken) multiple lifetimes --- a 5 year phd in computational physical science is just getting a warm up. For example, the Gaussian package was started by Nobel laureate John Pople in 1970 and has been continuously developed by research groups around the world ever since --- and its still in Fortran, even though it is a commercial package. That's not a legacy code -- thats a living code that has left (and still leaves!) a legacy!

Re:not in the field, eh?

[serviscope_minor]

These two sentences seem to be saying exactly the opposite. If the compiler does not ever assume that the value has not changed then it may assume that it *HAS* changed, and would not use a cached value.

Yes, that is what I said, but note the caveat. If the varible is a float, then it must only assume change if data has been accessed through a float* or a char*.

Even then, a modern compiler may be able to detect that a person has used pointer aliasing in a context and disable those optimizations in that context, while in Fortran, the language structure does not permit such things to happen, and thus produces code that makes the assumption it will never happen.

I'm not sure if you're talking about strict aliasing (type punning) or regular pointer aliasing. For type punning, the C compiler can assume it doesn't happen with a few minor caveats aside.

Even then, a modern compiler may be able to detect that a person has used pointer aliasing in a context and disable those optimizations in that context, while in Fortran, the language structure does not permit such things to happen, and thus produces code that makes the assumption it will never happen.

More the opposite: the compiler will only enable them if it can prove it doesn't happen. That is very much harder. It's alos why Java will likely always be slower, because escape analysis is exactly alias analysis. If you have to prove it, you will always miss cases when other languages can guarantee it doesn't happen.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[darkonc]

Touche. All European (and colonial) scientists shared latin. Scientists in other great cultures around the world just used their local 'universal' languages.

Still hiding behind "anonymity"?

[mmell]

Five posts. I must've hit a nerve there. All anonymous, all (even the parent of this post) written by Alexander Peter Kowalski, a frightened helpless child, still the victim after all these years.

Must be terrible - even here in cyberspace, you just don't even have the strength to defend yourself. Everyone still spits on you, laughs at you. It's like high school all over again, isn't it? You must be terrified that you'll lose as badly here as you have out there in the real world. Even the few people in school who ever showed you anything like respect eventually betrayed you, didn't they? Here, you've been derided, banned, branded a troll. All you know how to do is make challenges you know you'll never have to live up to. The internet has freed you from being physically hurt. Bullies can't stuff you into a dumpster here on the internet, but even here people you perceive as your inferiors are still able to humiliate you publicly. Even the courts don't want to hear from anyone as insignificant as you - or did you actually ever get that far? The wonderful folks that make Spam Titan certainly haven't felt your wrath. Is that because you discovered that your claims are legally baseless, or did Mommy just tell you she isn't going to spend money just to salve your ego? There's the chance that you actually managed to talk to a lawyer and get told just how worthless your case is; but somehow I don't think you ever even made it that far. All you know how to do is prove that you still exist by repeatedly uttering meaningless challenges via the internet. At your best you show all of the intelligence and thoughtfulness of an eight year old child in the midst of a neverending temper tantrum. Yes, I'm sure you think it's unfair that none of us will bow down to your obviously superior intellect. That's not how this is supposed to work, is it? Here, you're supposed to be in charge, respected and admired for your intellectual prowess - but instead you're derided by people who won't even pretend to be bound by the rules you think should apply here. I do pity you. Your life in the real world must be a hell from which even the cold dark of the grave would be a welcome reprieve, and the promise of finding Shangri La here in cyberspace has turned out to be a lie. It's not a magical alternate universe where your ability to argue even after you've lost is respected and admired, but just another place where you are trivialized, marginalized. Hell, even here you have to sneak around anonymously - must be terrible for you.

Re:Still hiding behind "anonymity"?

[Anonymous Coward]

From now on we shall henceforth call thee "the ProJecTioNiST", hahahaha...

Re:Still hiding behind "anonymity"?

[Anonymous Coward]

Mmell: Yer bein' called out. Why ya runnin', "forrest" http://tech.slashdot.org/comme... ?

Re:Still hiding behind "anonymity"?

[Anonymous Coward]

R O T F L M A O

Re:Still hiding behind "anonymity"?

[mmell]

No, no projection here. I have a wife, kids, a job - friends who like me, professional associates who respect me. I'm not the one spamming websites with infantile prattle and invective-strewn offtopic arguments. I'm not the one crying out "please love my software and me".

But you - the ultimate screen. I could truly project anything I wished onto you, because you're featureless. You continually repost "Run Forrest, Run" as though somehow it will elevate you beyond Forrest Gump's status (and it's obvious you've only seen the movie, never read the book).

Hate to burst your bubble - in the movies, downtrodden heroes always find their strength and redemption. In the real world (and even the cyberworld) the reality is a bit more harsh. If you want to find redemption, it will take more than waiting for some Hollywood deus ex machina device to fix all of the broken endings in your life. It'll take effort on your part; thought and effort. I know you're capable of these things, but until you demonstrate that, you will remain nothing more than a whimpering child, cringing from the attacks of a cruel world which somehow doesn't love you.

Re:Still hiding behind "anonymity"?

[mmell]

And just to take the bait - why would I want to "disprove 17 points of fact on great benefits using a hosts file gives users in added SPEED, SECURITY, RELIABILITY, & even ANONYMITY"? I never once argued that hostfiles have no place in modern IT infrastructure, home computing infrastructure or even modern computing - nor did I ever say or even imply that any of those points (tl;dr) are untrue. I've been very direct in pointing out your behavior is the problem - behavior which can only have originated in the mind of a terribly hurt and abused little boy.

Re:Still hiding behind "anonymity"?

[Anonymous Coward]

You took the bait. They got you. Now they are going to keep trying to get you. Have fun.

Re:Still hiding behind "anonymity"?

[Anonymous Coward]

I took the bait. I looked at your post history. You call his app malware. That's why I say. What's wrong with you?

Re:Still hiding behind "anonymity"?

[Anonymous Coward]

You started the argument with him. I'm the one who looked at your post history and replied. Don't call people's work what it isn't (malware) and you won't have issues next time.

Re:Still hiding behind "anonymity"?

[mmell]

You may be right. But keep looking.

I made the mistake of labelling his hostfile manager 'malware' after he's post-stalked me (and after he'd become insulting). I reacted poorly to his behavior.

That was my mistake, and I'll own up to it here. I permitted anger to cloud my reason, and made misstatements. He has remained quite implacable in post stalking - and using invective and ad hominem freely in his offtopic posts. My behavior hasn't been perfect, far from it.

I wish you the best of luck in getting a similar admission from APK.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Waihinga]

I was really pleased that InfoJunkie777 raised this issue and followed with great interest the ensuing discussion. I suspect that not everyone who contributed comments has actually had much first hand experience with FORTRAN or even Fortran and some therefore are thinking out of the box. That's not a bad thing of course, since new ideas frequently spring from thinking outside the box. However, I would like to offer a few comments from someone who has been firmly inside the box. Take the issue of fast computing. When I started programming in FORTRAN IV back in 1967 processing speed was the least relevant issue because we were required to take part in a procedural loop from which, occasionally, there was no escape. This consisted of punching cards, submit the cards to an operator who ran the program in batch mode, an hour, or even a day, later collect a printout, correct punching and programming errors, resubmit, and keep going around the loop until, with luck, finally escape with real results. Computing speed in this regime was effectively instantaneous. About the same time some bright spark (who would hate to be named now) invented a version of FORTRAN called PORTRAN (Poor man's Fortran) which was used by kids in rural schools with no direct access to a computer. This involved programming by using a paper clip to remove chads in blank punched cards and posting them to a computer operator in a city. I know it sounds dreadful now, but this was a wonderful thing in its time, inspiring many young minds to go further in their education. I notice that many of the contributors to the discussion remarked that Fortran is still considered useful for scientists and mathematical manipulations, but nobody seemed to understand quite why. I think the reason is simply that it remains fit for purpose. All the criticisms of Fortran are perfectly true (horrible at text processing, dreadful with graphics, inconvenient process of compiling, linking etc.), but for number crunching Fortran remains just fine. Right from the earliest days, FORTRAN IV made it really simple to do complex arithmetic (with i imaginary), matrix algebra, and advanced statistical analysis. In this respect access to the freely available IBM SSP made numerical analysis a breeze. Less than 10 years later than PORTRAN saw the advent of widely available make-your-own microcomputers with the S100 bus allowing one to simply plug in whatever card was relevant to your needs. This was instant opportunity for someone bright to upstage FORTRAN forever. But it did not happen. Instead, FORTRAN-80 was born which ran on the Z80 chip. The entire software library of mainframes became available in your own private room. I don't find it in the least surprising that Fortran is still relevant today. It began life with a strong supporting library and has evolved and adapted to remain fit for purpose. Code portability is still an attractive feature. I am still programming 47 years later, and there is little need for me to write any new Fortran code because it is already all written and running perfectly. The only need is minor manipulation of new data for the same old programs. Finally, it be plainly absurd for me to think of using Fortran for other aspects of my academic work and research, such as interactive graphics, programming hardware, and writing simulation software. Fortran is not fit for purpose here, so I use Pascal and, reluctantly C.

Easy to pick nits in this one

[Anonymous Coward]

Its easy to pick nits in this one (and I read most of it). C might not be quite as fast as fortran, but you can get to the 'bare metal' very easily with C, and you can't do that with the others. Also you can add inline fortran into C (and have C run the fortran, compiled as tight as anything), and inline Fortran runs at Fortran speeds, then you get the benefit of both worlds. Next is GOTO. If all you can do is BASIC, then GOTO is a dirty word. Nicklaus Wirth first decried the use of GOTO because he saw newbies and neophytes using it all over the place instead of good functional programming. He insisted GOTO was from the Devil! But reality is bad. In Assembly language, there is no "While-Do" or "Do-Until". There are machine instructions like Jump and Jump-Relative, which basically loads a new address into the instruction pointer register, and that sure looks like a GOTO. Also seeing Wirth's comments, Edgar Dijkstra wrote a reply: not damning Wirth eternally, but giving some pointed remarks, causing Wirth to recant a bit. And its true, if you are a newbie, GOTO is bad. If you are a systems programmer, its hellish to write an operating system without GOTO as the data structures built within the language do not support all of the needed data structures required by an operating system (and these data structures are rarely needed elsewhere), and also normal returns from built in data structures suffer badly from timing requirements (logic races), which are problems that are *NEVER* seen by application programmers. The author takes Wirths initial view (perhaps never having read Dijkstra or Wirths recant).

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[cyn1c77]

A: Legacy code.

and

B. Legacy scientists.

Nothing pisses a team off faster than a young, new engineer coming in and writing code in a new language that no one else knows. No one can proof it. No one can compile it. No one understands why the new guy needs to be different. No one wants to rewrite the old programs (which have been working fine for 30+ years) in the new language.

They teach engineers C++, Java, and Fortran in school. C++ and Java so that they can learn programming and Fortran so that they can actually keep a job.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

Right, the best case here would have been to write some sane fortran methods with basic unit tests, then wrap them with python ctypes calls. Viola! Everyone is happy - the CS guy that can do 'web' thing, the old school physicists that can re-use the basic, known to work, simulation code, and the new-school physicists that are doing everything in an iPython shell.

Re:not in the field, eh?

[angel'o'sphere]

I assume: no loops?

Re:not in the field, eh?

[angel'o'sphere]

Sure ...
What is your problem? You invented Fortran and are now pissed? Why do you write such nonsense?

Re:not in the field, eh?

[angel'o'sphere]

Sigh, if you define 'big boys' by doing numeric methods ... perhaps you should get a bit more respect for the rest of the comp sci community. After all: we write the fortran compilers you are so in love with.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[jc42]

ALL CAPS has been optional since 1990, at least. Fortran has had modularisation, structured code since 1990, Classes and object-orientated since 2003. Please update your prejudices.

Reminds me of a quip I heard back in the early 1980s: We don't know what language the scientific community will be using 40 years from now, but we know it'll be called "Fortran".

We might also note that the most common implementations of Fortran are now part of a package that also contains C and several other languages. They all effectively have the same capabilities, because if something isn't "doable" in one language, you can just call a subroutine in a language that makes it easy. The first-level parsers translate into a common internal language, and the modules past that level don't care what the surface syntax was.

I've seen a number of "Fortran" programs that were 90% coded in other languages. But the top-level entry-point routine was in Fortran, so the "program" was in Fortran. I once spoofed this on a project by writing an app "in C", meaning that the entry point was a C main(ac,av) routine, but everything else was in other languages. I actually used all the languages that we had "installed" in the compiler package, including Fortran. This got me tongue-in-cheek accusations of being a major geek show-off.

Re: Q: Why Are Scientists Still Using FORTRAN in 2

[russotto]

The program I graduated from at a large state school in the US isn't even accredited by ABET. Seeing as how ABET is mostly known as an engineering accreditor I would expect this to be the case for many computer science degrees not part of an engineering program.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

Why?

No real need for change.

New languages has niceties like "object orientation", making it easier to train novice programmers. Nice for corps that need cheap programmers for writing 'apps'.

Scientists however, are experts. The can use a more cumbersome language, if it provides more speed. And no need for "GUI" or other app-oriented features. The features of modern languages is thus unnecessary for science - raw power is what matters.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

I started looking at the videos on the Julia website and kept thinking how that language reminded me of the very high level of APL but with normal ASCII characters. I remember how IBM did work on a special vectorizing APL, but it never caught on like Fortran. Julia might have a better go at it--it's pretty new, though.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Forever Wondering]

Well, consider that APL was originally based on an [alternate] mathematical notation developed by Kenneth E Iverson.

BTW, I was writing APL programs in 1972 [and I already knew Fortran] ... The real problem with APL, aside from needing an alternate keyboard, was that the equations were so dense that proper commenting was difficult. And, if you did proper commenting, it broke up the equations, defeating the purpose ...

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[tlambert]

So, Fortran issues extra instructions and pipeline stalls for accuracy, yet manages to be faster.

That is amazing!

It's faster in areas not involving floating point, and in floating point on hardware that has a good floating point implementation.

It's easier to branch-predict fortran code, and the lack of pointer support makes the boolean algebra a lot simpler for the complier. Given the calling conventions and limits, it's actually a lot easier to optimize fortran, and given that oist matrix math involves linear loops, it's easier to autovectorize things like the Berkeley Physics package. E.g. if you are attempting to do montecarlo simulations of P-P and N-P collisions in a relativistically invariant reference frame while simulating pair production events constrained by the matrix solution to the intersection of multiple Feynman-Dyson diagrams, it will almost universally run faster if the code is in FORTRAN.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[ttucker]

That's just for the keycaps. You have to buy the rest of the keyboard separately (for something like $100).

I run a Unicomp Ultra Classic keyboard. It cost $80, and is worth at least twice as much. Try one out someday.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[ttucker]

Also "legacy training". Student learns from prof. Student becomes prof. Cycle repeats.

Also Fortran didn't stagnate in the 60s, it's been evolving over time.

Other languages are highly optimizable too. However most of the new and "cool" languages I've seen in the last ten years are all basic scripting languages, great for the web or It work but awful for doing lots of work in a short period of time. It's no mystery why Fortran, C/C++, and Ada are still surviving in areas where no just-in-time wannabe will flourish.

Do not drag genuine JIT/intermediate bytecode compiling languages through the mud by grouping them with scripting languages. AFAIK there is no cool language that is ever compiled, JIT or not.

Re:not in the field, eh?

[raxx7]

First, my comment wasn't generally about whether C or Fortran is better.
I just just illustrating that C's aliasing isn't as much as an obstacle for vectorization as it's often said (and I probably said so in the past, so I'm also guilty).
In general, Fortran arrays and slicing map to pretty trivial C code. Most people can write decent stuff for that. Getting it to vectorize isn't hard.

Secondly, AFAIK, arrays and array slices in Fortran need to be used with a bit of care.
In some situations it can lead the compiler to copy the data into a temporary array (eg, passing a slice as a function parameter).
Another issue is that in a array with 2 or more coordinates, only one coordinate has a memory layout suitable for vectorization in a CPU without scatter/gather (which you may want to avoid anyway if seeking ultimate performance).
Dealing with this issues requires a good understanding of these issues, the language and the compiler's modus operandis.
Fundamentally, arrays in any language are trivial when at the microscopic language but choosing the right strategy for the full program can be a challenge in any language.

Third, having spent more time that I'd like trying to hammer into a few scientists that you need to avoid loops and use array operations to get good performance out of MATLAB®, I would say that some scientists' brains are better suited to hand writing loops than array manipulation.

What a lousy liar (proof inside)... apk

[Anonymous Coward]

"Don't listen to APK. He's trying to sell his particular brand of snake-oil. Let's face it - he's just out to substitute his (proprietary, non-standard, non-best-practices) method for DNS." - by mmell (832646) on Friday May 02, 2014 @03:42PM (#46902201) FROM http://tech.slashdot.org/comme...

Per my subject-line: It's that, or you're brain-damaged & can't remember what you said this past week only a day or so ago quoted above!

Now, you're saying THIS BELOW quoted instead?

"why would I want to "disprove 17 points of fact on great benefits using a hosts file gives users in added SPEED, SECURITY, RELIABILITY, & even ANONYMITY"? I never once argued that hostfiles have no place in modern IT infrastructure, home computing infrastructure or even modern computing - nor did I ever say or even imply that any of those points (tl;dr) are untrue." - by mmell (832646) on Saturday May 10, 2014 @04:23PM (#46968547)

"?"

"Satan turns to Christ" trying to play "innocent"?? Please...:

(THAT above's on top of calling my app a malware repeatedly & it's the FARTHEST THING from it, saying I am selling it too? Sorry - learn to read: IT IS FREE!)

* Get real!

(The "trying to play innocent here" or "victim" type b.s.? Come on... really/seriously! Lmao... you're unbelievable -> http://www.youtube.com/watch?v... )

APK

P.S.=> THIS seriously "takes the cake" from you, especially AFTER the above:

"I've been very direct in pointing out your behavior is the problem - behavior which can only have originated in the mind of a terribly hurt and abused little boy." - by mmell (832646) on Saturday May 10, 2014 @04:23PM (#46968547)

Speak for yourself & as was said to you before? Quit "projecting"... & answer this question -> http://slashdot.org/comments.p...

Which is yet another you 'evaded' with troll maneuvers of which the ABOVE TAKES THE F'ING CAKE for nerve (lol, you won't)

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

If it isn't IEEE-754 compliant, you pretty much can't trust it. FORTRAN goes way the heck out of its way, including issuing additional instructions and introducing pipeline stalls, in order to force IEE-754 compliance.

That's the compiler, not the language. IEEE-754 wasn't published until 1985, so the older [1977] spec doesn't say anything about it.

In any case, if you care about the difference between 80-bit extended precision and IEEE double precision, then you're either writing a compiler, dealing with an extremely stiff differential equation, or [most often] have made a poor algorithm choice and are trying to paper over algorithmic instability by throwing more bits at it.

-JS

Re:not in the field, eh?

[rubycodez]

no, I mean those who run very large models - lattice guage theory, quantum chemistry of proteins, astrophysical fluid dynamics

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[mysidia]

Why reinvent the wheel?

Fortran 2003 has ISO_C_Binding for complete access to the C library functionality.

So you definitely have file and network I/O available in Fortran, much as you have in C.

This might not in itself be reason to use Fortran; however, Fortran does have many interesting properties, which may enable writing code for numerical and computational algorithms that in the real world will run faster than even C code.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[mcswell]

I once worked on a CDC Cyber 170/750, where you could not have spelled it Fortran. That's because it had a 6-bit character encoding system, with room for only upper case letters. (Ok, you could have printed in all lower-case letters, but the line printers only had upper case letters.) It was originally designed for numeric processing, so who needed a case distinction? Hence FORTRAN. Then someone actually hacked it to allow both upper and lower case letters: a slash before any alphabetic character meant the lower case version of that character. Luckily, they also hacked the text editor to display '\A' as 'a' etc. And I wrote my linguistics dissertation on that system. This was in 1984.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

Real APL programmers don't need a special keyboard. They just use a keymap and remember where all the symbols are.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

Awww... That's why it's funny. You fail at humor.

Re:not in the field, eh?

[mark-t]

the compiler will only enable them if it can prove it doesn't happen. That is very much harder.

Yes... and here is where we enter into the kinds of optimizations that -O3 does with gcc.

Fortran compilers don't even try, however... with appropriate optimizations enabled, it always assume that it will never happen, unless you are explicitly using a union type, which almost invariably results in faster code, end will 99 times out a hundred exhibit the behavior that the code author expected, except in a case where different object pointers might overlap in their content, where the behavior is defined by the implementation and the author can exploit this fact to achieve certain techniques that more resemble assembly language optimization than high level coding. C allows this, Fortran does not... but allowing it comes as a performance cost.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[tlambert]

That's the compiler, not the language. IEEE-754 wasn't published until 1985, so the older [1977] spec doesn't say anything about it.

In any case, if you care about the difference between 80-bit extended precision and IEEE double precision, then you're either writing a compiler, dealing with an extremely stiff differential equation, or [most often] have made a poor algorithm choice and are trying to paper over algorithmic instability by throwing more bits at it.

-JS

Or I want reproducible results. It's one of the reasons that, if you are using a PRNG as an input to a montecarlo algorithm, that you want to seed it the same way each time, and you probably want to carry around your own PRNG, rather than trusting that some idiot didn't change drand48 to "make it have better entropy", rendering your computations non-reporducible.

It turns out that in Science(tm), being able to reproduce someone else's results independently ends up being "kinda important".

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[bemymonkey]

Also (according to the professor who taught my advanced mathematics course), FORTRAN compilers are easy to trick into doing exactly what you want in Assembly. In languages like C, it's apparently much more difficult to predict what the compiler will end up spitting out, but in FORTRAN they are (or were - my prof's experiences with FORTRAN date back to the 80s) able to pretty much able to optimize the actual Assembly quite well without actually needing to touch Assembly...

I found that tidbit quite interesting...

Re:not in the field, eh?

[serviscope_minor]

I think we're now in agreement.

Apparently despite lots of Karma, however I can't send this message without waiting 5 minutes.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[lee1]

Thanks for sharing the story of PORTRAN: that's really interesting history that I'd never heard before (I'm the author of the OA).

That's all I wanted to see/hear... apk

[Anonymous Coward]

Mmell - my program PROTECTS YOU vs. malware (if it does anything) for FREE by essentially using the principle of the forcefield really in "What you can't touch, can't hurt you",,, & yes it works.

Hairyfeet (/. user) can tell you the same!

In fact - He & I "had it out" on hosts files vs. DNS!

(Until I pointed out downsides of it vs. hosts such as the fact hosts can cure its problems - redirects by Kaminsky flaw since 99.999% of ISPs aren't patched vs. it oddly even though a patch has been around for more than 1/2 a decade++ now, & vs. "FastFlux" &/or Dynamic DNS using botnets + power consumption, CPU cycles, RAM, & other forms of I/O too being less with hosts along with electricity consumption).

So, He went to AdBlock & noticed his customers (owns a PC repair shop) didn't get infected anymore - & hosts do a FAR BETTER JOB of protecting you not only vs. ads, but also vs. known sites-servers/hosts-domains serving ads AND malicious content too!

(Hosts do more for the end user in added speed, security, reliability, & anonymity @ a faster level of operations BEFORE browser addons even BEGIN to operate!)

That's ALL I wanted to hear from yourself & the "beatings will no longer continue"...

* At least YOU'RE man enough to admit you did it out of anger + made a mistake... I'll give you that!

(However - DO *try* to see MY "pov" here, that's all - & yes, there are 2 more guys on this board I am pressing who OUTRIGHT said my app was a "malware" & it's DEFINITELY not!)

APK

P.S.=> PER MY SUBJECT-LINE ABOVE:

Write Mr. Steven Burn of Malwarebytes' hpHosts website here http://hosts-file.net/?s=Downl... & he can verify that APK Hosts File Engine 9.0++ 32/64-bit http://start64.com/index.php?o... is CLEAN, no threat & free of malicious content (heck - it's a portable app, & doesn't TOUCH your OS other than hosts itself)... apk

K. S. Kyosuke = "Run, Forrest: RUN!"

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke gets called out & ran

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke = "Run, Forrest: RUN!"

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke gets called out & ran

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke gets called out & ran

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke = "Run, Forrest: RUN!"

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke gets called out & ran

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke = "Run, Forrest: RUN!"

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

Bwahahaha: K.S. Kyosucky != programmer

[Anonymous Coward]

Ask him to show he's coded a program that did well enough to become commercially sold. Go on, ask. You'll get back zero from that zero since he's ALL talk, nothing more.

K. S. Kyosuke = "Run, Forrest: RUN!"

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke gets called out & ran

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke gets called out & ran

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke gets called out & ran

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke = "Run, Forrest: RUN!"

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke gets called out & ran

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke = "Run, Forrest: RUN!"

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke gets called out & ran

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K. S. Kyosuke = "Run, Forrest: RUN!"

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

K.S. Kyosucky = sockpuppeteer (mods himself up)

[Anonymous Coward]

+5's on his posts = sockpuppets use (mods himself up, & detractors down). This site's full of pigs that do that. His "kind" (online scum) truly have no shame. The little jackass posts utter bullshit and yet when confronted to show he's actually done any programming? You see him down mod those posts to "hide them" (or so his deluded mind thinks).

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[mrchaotica]

I'm still kicking myself for giving up my Tandy Enhanced keyboard (I donated it to Goodwill when I was a teenager and didn't know any better)... : (

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[goarilla]

Only 8 arguments, I've seen monstrosities with > 20 arguments all with 2 or 3 letter names.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[gzuckier]

Ixnay on the atinlay

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[gzuckier]

Don't forget Fortran 66's handy capacity to use constants as variables. You could say 1=2 And from then down in the code 1+1 would equal 4. That was pretty handy, although only when you wanted to play a mean joke on somebody.

Order of operations

[ZincProgrammer]

One reason is that, unlike other languages, you have control over the order of operations in a formula. This is important when executing the operations in the wrong order will cause an overflow. For example if A, B, and C are very large, (A - B) * C would give an overflow if executed as A*C - B*C. Whereas (presumably) D = A - B, then D * C would not. Some languages will " optimize" these statements and thus cause overflow.

Math

[Anonymous Coward]

I always liked Fortran because it was very straightforward for soling mathematical equations. Way back in the 60's I wrote Fortran programs to solve differential equations, very easily without any programming training of any type. I wrote the programs to verify the results of my slide rule calculations and was pleased that my slide rule results were accurate three places to the right of the decimal, which means splitting a small space between marks on the ruler mentally into the correct fraction of the hair line position in that space. So I can see why scientists would still use Fortran.

No, I'm afraid it's not over.

[mmell]

Initially, I maintained a more neutral stance, until you started post stalking me - as you have done to several other users. You have also been spamming Slashdot, often posting your personal advertisement for your software in threads where it is completely inappropriate. My mistakes were to take a non-neutral stance and to judge your software based on the fact that you are shilling for it here on Slashdot.

I won't spampost here, nor will I post stalk you - but if I see you using these techniques, I will respond directly. "The beatings will no longer continue"? We'll see. I am aware of your point of view in this; however, I have no intention of tolerating your abuse of the Slashdot bulletin board. If I have made a mistake (and I have) I am prepared to correct it. I insist you do likewise.

The beatings may or may not continue at your discretion, of course. However, I reserve the right to respond to what I perceive clearly to be an abuse of this forum - and I still find your abuse of this forum to be intolerable. My analysis concludes that you are in fact a fairly good programmer and have written several quite interesting pieces of software. However, your inappropriate marketing techniques (offtopic "spam" posts of your advertisement for your software, immediate and vociferous post-stalking of anyone who posts a negative opinion of you, your posts or your software) are irremediably attached to the very software products you're attempting to promote.

I will not knowingly download or use software you've written, specifically because you have demonstrated here in this forum that you are neither stable nor trustworthy. I don't know you and can't say personally whether or not this is accurate, but it is a perception which I (and apparently several other Slashdot readers) have formed based on our experiences with you here. There is a parallel - the Reiser Filesystem was once a widely noted and even commercially adopted piece of software - right up until Hans Reiser was convicted of murder. The quality of RFS no longer matters, even though Hans Reiser is no longer directly involved with it. The reputation of RFS is now irreparably sullied. Your reputation and software are not as badly off. Begin behaving yourself and find another mechanism for advertising - you will find that even her at Slashdot, people will respond to that. Even in your post above you have proferred an olive branch, but accompanied by another pitch for your hostfile manager (yes, I know - it's a non-trivial piece of work which provides data normalization for hostfiles as well as several useful functionalities). Offtopic posts are not a reputable mode of behavior. It's still shilling. Is this truly an offer of peace, or just another chance for self promotion?

Re:No, I'm afraid it's not over.

[Anonymous Coward]

WP had to block him too.

Why are MY LEGITIMATE FACTS ON HOSTS FILES BEING BLOCKED? apk This edit request has been answered.

74.106.199.117 (talk) 03:55, 24 December 2011 (UTC)

  Thank you for coming to the talk page to discuss this. Your additions have been removed (twenty times now) because they are not suitable. Wikipedia is an encyclopaedia. It is not a manual on how to tune your hosts file, or how to use it to aid your computer's security, or any other "how to" guide.

So proud!

[alfino]

Dear father-in-law, I am very proud to see you write here! ;)

Re: Q: Why Are Scientists Still Using FORTRAN in 2

[Anonymous Coward]

I'm scientist and fortran IS legacy code. No one younger than 40 yo can stand reading fortran code anymore. New projects start with C/ C++ (or python if speed is not a concern). CERN converted almost all of its libraries or programs to C/C++, other labs are doing the same. If Julia is gonna be THE language of the future in science only time will show us.

You brought "the beatings" on yourself... apk

[Anonymous Coward]

"Initially, I maintained a more neutral stance" - by mmell (832646) on Sunday May 11, 2014 @02:51PM (#46973999)

NOT very "neutral" & VERY WRONG - I work WITH DNS fixing its faults in security actually (only keeping top 50 sites I like @ the TOP of my hosts file - to offset index loss on large hosts & it works - the rest IF/WHEN I miss a lookup = OpenDNS (rare since 95% of my time online IS in my favs hostsfiles hardcoded)) - http://tech.slashdot.org/comme...

(THAT was the 1st time I have EVER seen YOU reply, to me...)

---

"You have also been spamming Slashdot, often posting your personal advertisement for your software in threads where it is completely inappropriate" - by mmell (832646) on Sunday May 11, 2014 @02:51PM (#46973999)

Show me once where I've posted where hosts don't apply when I posted... Clue: I ONLY POST where hosts fix things or do a better job than competitors & ONLY after they post first (usually Adblock or Ghostery, both 'souled out' & INFERIOR).

---

I have no reason to continue... you were man enough to say you said my ware = malware out of anger, I can forgive that... but?

YOU BROUGHT IT ON YOURSELF (see link above).

APK

P.S.=> Good day... apk.

Re: K. S. Kyosuke gets called out & ran

[Anonymous Coward]

Oh please just fuck off and take your meds. I'm sick of having every thread on this site polluted by your script-posted rants.

Legacy?

[Anonymous Coward]

It's funny how we call code legacy yet there is no such thing as legacy math.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[hawk]

And optimization has a lot to do with why Fortran is still used, and preferable to c/c++ in many cases.

Fortran can make some strong assumptions that it uses for optimizations. It is not as general purpose as c, for which those assumptions might or might not be correct. Yes, you can do nearly anything in either language, but some will be easier to do in one, and some in the other.

Expecting c to smash arrays into one another as well as a language designed for that purpose is silly--as would be expecting the time it takes to code in the more general purpose language to be comparable to the custom language.

hawk

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[stoatwblr]

Nice answer but I work in a space lab and more new code is written in Fortran than every other language put together.

It works. That's the main reason. We have people who can write in multiple languages, but the language of choice for most heavy lifting is Fortran.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[stoatwblr]

The cure for this kind of inanity is a slap around the head and telling them it isn't going to be accepted until it's readably documented.

There's a lot of whining when they get told this, but aftee a few rounds they tend to get into the habit of documenting as they go.

Re: Q: Why Are Scientists Still Using FORTRAN in 2

[Anonymous Coward]

I think that it comes down to usability, and the simplicity of the language.

FORTRAN

[Anonymous Coward]

I have used both FORTRAN 66 and FORTRAN IV. The difference between the 2 are significant. Since then have come FORTRAN 77, FORTRAN 90, FORTRAN 95,
FORTRAN 2003, AND THE CURRENT FORTRAN 2008. There is a lot of code and subroutine libraries written in FORTRAN which keeps FORTRAN alive. There were various variations on the listed versions of FORTRAN also. I expect FORTRAN to outlast me.

The end of an era

[EstelleRW]

My son (2nd-year Physics undergraduate at the University of Surrey) is in the last generation to be taught coding using Fortran. This year's intake went straight to C++.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[stenvar]

Why are you telling me? Do you have a point to make?

It works

[OrdinarySoul]

Scientists tend to stick with what works instead of what's new.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

that's how it's spelt now, not "FORTRAN"

I'm actually more interested in how the world "spelt" is spelled.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

Oh please, Esperanto was invented for completely different reason: for quick learning. Esperanto is just the BASIC of second languages.

You didn't answer my question

[Anonymous Coward]

Show me a post on /. where my posting on hosts didn't apply. Pretty simple (obviously, you can't, & that's that).

APK

P.S.=> There's NO WAY you fools can win here: Get THAT thru your heads - I have you outthought, outsmarted, & yes, "outed" easily by facts + truth I state that YOU cannot get the better of - period!

... apk

K. S. Kyosuke = "Run, Forrest: RUN!"

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

Re: K. S. Kyosuke gets called out & ran

[Anonymous Coward]

You say you're sick? Take your own advice (and your meds) & quit projecting!

K. S. Kyosuke gets called out & ran

[Anonymous Coward]

From a fair challenge like a chickenshit blowhard http://slashdot.org/comments.p...

Make me, & to quote Ultron?

[Anonymous Coward]

"Shutdown code, rejected: My programming ( http://start64.com/index.php?o... ) has advanced beyond YOUR commands: Beyond YOUR weakness" - Ultron 6 FROM -> http://www.youtube.com/watch?f...

* Not a thing you can do vs. it - & trolls most CERTAINLY can't disprove my points on hosts files giving users added speed, security, reliabliity, & anonymity online!.

(You know it, I KNOW IT - Anyone with 1/2 a brain on /. the past 2 yrs. does also, seeing you trolls harass me to no end - only to end up with EGG ON YOUR FACES!)

APK

P.S.=> Why you'd troll me used to boggle my mind. It's a good program that does the job & offers the benefits I enumerate in its download link. HOWEVER - It doesn't boggle my mind anymore why you trolls do:

You're malware makers/botnet masters (I block them refreshed daily from 12 reputable & reliable sources in the security community), advertisers (I block their ads which steal speed you PAID for & infect you with malicious scripts + track you), inferior competitors (Ghostery/AdBlock/RequestPolicy), or webmasters (Pissed I block ads - they're being exploited + I held off on letting my app out (not anymore after that)) & it isn't "Souled-Out" INFERIOR (Adblock & Ghostery) & it shores up security faults in DNS & speeds up resolution of your fav. sites hardcoded in it (faster than remote DNS lookups + secures you vs. DNS request logs + DNSBL)

.. apk

K. S. Kyosuke brought it on himself

[Anonymous Coward]

For being an offtopic illogical ad hominem attack using troll: See post parent to this http://slashdot.org/comments.p... as it says it all. You can thank K.S. Kyosucky for it.

unlike "C"?

[Anonymous Coward]

I might ask why everyone is still using some variant of the C programming language...it was developed in the 60s!

Why is everyone else still using C?

[Anonymous Coward]

Why is everyone else still using C? It is 40+ years old.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Mike Van Pelt]

If you haven't seen or used modern Fortran and think it's anything like Fortran 66/77 then you're mistaken.

As Seymore Cray said, when asked what the scientific programming language of the 21st Century would be, "I have no idea what it will look like, but I'm sure it will be called Fortran."

Re: Q: Why Are Scientists Still Using FORTRAN in 2

[FreedomFirstThenPeac]

Even better is to use matrices in native form, as in (x')*A*'x meaning the vector x, the matrix A and quadratic form thereof. Very handy for teaching n-dimensional minimization (hint, take the deriviative of the term). How to write that in a formula translation language is the trick, we used t() to get the transpose, explicit typing to ensure A was a matrix and x a vector, etc. Fortran is a pretty handy form but it did not let us redefine operators like * back in the day. Now I am in R, so cannot really comment on modern Fortran.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[FreedomFirstThenPeac]

Yes, until the compiler changes the interior of a loop thinking it was doing it right. We were engineers doing orbital mechanics, did not pay attention to the switches on the compiler, it took a greybeard who looked at our core dump (remember those?). He spotted that a line of code had been moved outside of the loop because it did not look like it was necessary to have it inside. I think the function call used used a pass by reference variable that was being changed within the function. The optimizer did not see that change so it made sense to call the function just once outside the loop. Maybe I have detail wrong (it was back in 1978 or so), but the fact that the optimizer goofed has made me suspicious of these sorts of promises ever since.

People still pay to use FORTRAN

[bbsalem]

About 11 years ago I was working at Sun Microsystems working on getting patches to customers from legacy compiler engineering for escalated bugs against FORTRAN and CC++. I know that sales of the compilers exceeded $1 Million a year even though Sun was giving Java away for free and not competing very well with its IDE against IBM and others. I hadn't coded in FORTRAN for about 15 years at that point and had to learn about developments in the language while I had redirected me experience to C/C++. and I was surprised by the demand, but quickly learned that our customers liked FORTRAN because of the overall performance of legacy numerical analysis libraries. It would be interesting for people at Oracle to comment on this.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[cwsumner]

Fortran, apart from being a brilliant language for numerical math, has the added benefit of keeping CS graduates at bay. I'd rather have a physicist who can't program, than a CS type who can.

The problem was not the CS major, it was hiring a fool right out of school to run a project that large. He may grow out of being a fool, most do. But not yet.

I hope you don't assign your Physics students that way...

Simple

[Anonymous Coward]

It is much easier to describe complex mathematics in Fortran and the resulting executable is faster than C.

Perhaps OCaml can come close but I doubt it.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

Everything in computing is mathematics.

All computers are turing machines. All computer programs are a Turing machine.

Turing machines are mathematical and equivalent to lambda calculus which of course is math.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[cwsumner]

Latin was the one language that all academics shared.

...you mean, those who didn't speak Hebrew, Greek, or Arabic?

Actually, the Arabic scientists of the time -did- speak Latin, Greek and other languages, and so did most of the Hebrew or Greek ones. But the Euroupeans did not generally speak Arabic.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[cwsumner]

ALL CAPS has been optional since 1990, at least.

Fortran has had modularisation, structured code since 1990, Classes and object-orientated since 2003. Please update your prejudices.

...modularisation, structured code since Fortran IV, about 1973 (?). FTFY...

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

Learning Latin is a great mind building exercise.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Jeremiah Cornelius]

So is learning Mandarin - and a bit more useful. ;-)

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[stevesliva]

I will be able to, no?

Re:not in the field, eh?

[Anonymous Coward]

You are right that aliasing is one of the main differences. But Fortran compilers, like all other (real) compilers, are concerned with correct output first and foremost. It's not that they don't care about producing correct output, it's that they can safely make certain assumptions that C/C++ compilers cannot.

  Fortran compilers have the edge over C and C++ compilers because, among other things, the Fortran language has certain constraints on things like arrays passed as parameters, which allows the Fortran compiler to safely perform some optimizations that the C/C++ one's can't because C/C++ allows more things to be aliased. Aliasing introduces uncertainty which restricts optimization, and it's not always possible to remove those uncertainties.

The other big reason is that many Fortran libraries have been tuned far better than C/C++ equivalents, and so when concerned about speed for a certain domain of problems, using the highly tuned Fortran ones is a no-brainer. Additionally, sometimes there is no C/C++ equivalent library, so productivity-wise Fortan can also be the obvious choice.

Disclaimer: I worked for 17 years on C/C++/Fortran/JIT compilers for IBM.

The right language

[Anonymous Coward]

It's a matter of the right language for the job. Better than a language that tries to do everything.

Answer a question, don't downmod hide it again

[Anonymous Coward]

Any commercially sold code you can show us you did?? Downmodding it to hide it before was low!

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

Your statistical model is only correct with one specific set of random data?

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[stenvar]

I realize that depriving people of their beloved imperative loops might seem cruel, but designing the language in a way that would make obvious coding styles easily executed on vector machines seems a bit saner to me than allowing people to write random loops and then either hope that the vectorizer will sort it out

People do write large scale numerical code using functional abstractions, automatic vectorization, pipelines, data flow, and all that. There are excellent libraries for those purposes for both C++ and Fortran.

The reason people still stick to C++ and Fortran rather than going to a fully automatic system is threefold. First, it isn't necessary: modern versions of C++ and Fortran already have all the necessary high level support; except for an unfamiliar syntax, Nile doesn't add any functionality. Second, there is tons of legacy code that people want to interoperate with easily and without much hassle; switching to a new language with new conventions makes that hard. Third, with tools like Nile, sooner or later, users hit cases where the automated tools don't work anymore, and then they have to go back to figuring out how to link in C/C++/Fortran anyway.

Language and systems people often have the notion that numerical and parallel software developers do what they do out of ignorance, when in fact it's a rational decision to stick with the tried-and-true existing languages and tools. When improvements are needed, they need to be made incrementally and in a backwards-compatible fashion, and that's how they are happening.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[stenvar]

Furthermore, nowhere have I made the claim that the semantics of Nile in its current form is a perfect replacement for any language for scientific computation, as opposed to the thought that there could be some lessons to be learned.

You assume incorrectly that these are "lessons" people working in these areas don't already know and still need to learn.

On the other hand, you'll find that actually implementing something like Nile correctly and efficiently is extremely hard; so hard, that by the time you're done, the world has already moved on to other tools.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[Anonymous Coward]

And the scientific community is a good 20 years away from effectively utilizing such goodies the steering committee has accepted because software maintainability is often a secondary concern.

That may or may not be true, but either way, it's a language-independent problem.

If anything, scientists are a lot more likely to use OOP in Fortran because it's a lot more straightforward to use than in C++, while providing much of the same power, and often better performance.

Re:Q: Why Are Scientists Still Using FORTRAN in 20

[zildgulf]

Since almost all hardware can run compiled Fortran code why not keep it if you have lots of legacy stuff that rarely gets reprogrammed. I am a CS grad but my consultant experience shown me that "upgrading" is not always the best thing for my clients. I would say if an upgrade was required that the perfect language to go to is C, not C++, and migrate it faithfully, not using the latest hot CS trend because in such programs reliability is job one. If you can't rely on the migrated program then the migration is a complete failure, as you witnessed.

mmell LIBEL classics

[Anonymous Coward]

Saying I use hosts to evade police while I surf little boy porn http://slashdot.org/comments.p...

Libeling me saying my WARE IS A VIRUS etc. too? Please -> http://slashdot.org/comments.p... (1 of 2)

Libeling me saying my WARE IS A VIRUS etc. too? Please -> http://slashdot.org/comments.p... (2 of 2)

THEN RECANTING THAT LIBEL HERE http://slashdot.org/comments.p...

?

ERRONEOUSLY saying I was creating a DNS replacment (which it's not, it shores up DNS redirect security issues & resolves FASTER locally in RAM vs. remote lookups) -> http://tech.slashdot.org/comme...

Saying VI can do all my APK Hosts File Engine can do (not) & running -> http://slashdot.org/comments.p... when VI can't?

* Please... lol!

APK

P.S.=> You have SERIOUS issues - get over your ''geek angst" already (you're not even much of a 'geek' based on your technical screwups above)... apk

mmell LIBEL classics

[Anonymous Coward]

Saying I use hosts to evade police while I surf little boy porn http://slashdot.org/comments.p...

Libeling me saying my WARE IS A VIRUS etc. too? Please -> http://slashdot.org/comments.p... (1 of 2)

Libeling me saying my WARE IS A VIRUS etc. too? Please -> http://slashdot.org/comments.p... (2 of 2)

THEN RECANTING THAT LIBEL HERE http://slashdot.org/comments.p...

?

ERRONEOUSLY saying I was creating a DNS replacment (which it's not, it shores up DNS redirect security issues & resolves FASTER locally in RAM vs. remote lookups) -> http://tech.slashdot.org/comme...

Saying VI can do all my APK Hosts File Engine can do (not) & running -> http://slashdot.org/comments.p... when VI can't?

* Please... lol!

APK

P.S.=> You have SERIOUS issues - get over your ''geek angst" already (you're not even much of a 'geek' based on your technical screwups above)... apk

mmell LIBEL classics

[Anonymous Coward]

"I never once argued that hostfiles have no place in modern IT infrastructure, home computing infrastructure or even modern computing - nor did I ever say or even imply that any of those points (tl;dr) are untrue. I've been very direct in pointing out your behavior is the problem - behavior which can only have originated in the mind of a terribly hurt and abused little boy." - by mmell (832646) on Saturday May 10, 2014 @04:23PM (#46968547)

No, you fucking liar? See above, & see your UTTER LIE shown for what is really is, next below:

ERRONEOUSLY saying I was creating a DNS replacment (which it's not, it shores up DNS redirect security issues & resolves FASTER locally in RAM vs. remote lookups) -> http://tech.slashdot.org/comme...

THEN?

Saying I use hosts to evade police while I surf little boy porn http://slashdot.org/comments.p...

Libeling me saying my WARE IS A VIRUS etc. too? Please -> http://slashdot.org/comments.p... (1 of 2)

Libeling me saying my WARE IS A VIRUS etc. too? Please -> http://slashdot.org/comments.p... (2 of 2)

THEN RECANTING THAT LIBEL HERE http://slashdot.org/comments.p...

?

Saying VI can do all my APK Hosts File Engine can do (not) & running -> http://slashdot.org/comments.p... when VI can't?

* Please... lol!

APK

P.S.=> You have SERIOUS issues - get over your ''geek angst" already (you're not even much of a 'geek' based on your technical screwups above)... apk

mmell LIBEL classics

[Anonymous Coward]

Saying I use hosts to evade police while I surf little boy porn http://slashdot.org/comments.p...

Libeling me saying my WARE IS A VIRUS etc. too? Please -> http://slashdot.org/comments.p... (1 of 2)

Libeling me saying my WARE IS A VIRUS etc. too? Please -> http://slashdot.org/comments.p... (2 of 2)

THEN RECANTING THAT LIBEL HERE http://slashdot.org/comments.p...

?

ERRONEOUSLY saying I was creating a DNS replacment (which it's not, it shores up DNS redirect security issues & resolves FASTER locally in RAM vs. remote lookups) -> http://tech.slashdot.org/comme...

Saying VI can do all my APK Hosts File Engine can do (not) & running -> http://slashdot.org/comments.p... when VI can't?

* Please... lol!

APK

P.S.=> You have SERIOUS issues - get over your ''geek angst" already (you're not even much of a 'geek' based on your technical screwups above)... apk

mmell LIBEL classics

[Anonymous Coward]

Saying I use hosts to evade police while I surf little boy porn http://slashdot.org/comments.p...

Libeling me saying my WARE IS A VIRUS etc. too? Please -> http://slashdot.org/comments.p... (1 of 2)

Libeling me saying my WARE IS A VIRUS etc. too? Please -> http://slashdot.org/comments.p... (2 of 2)

THEN RECANTING THAT LIBEL HERE http://slashdot.org/comments.p...

?

ERRONEOUSLY saying I was creating a DNS replacment (which it's not, it shores up DNS redirect security issues & resolves FASTER locally in RAM vs. remote lookups) -> http://tech.slashdot.org/comme...

Saying VI can do all my APK Hosts File Engine can do (not) & running -> http://slashdot.org/comments.p... when VI can't?

* Please... lol!

APK

P.S.=> You have SERIOUS issues - get over your ''geek angst" already (you're not even much of a 'geek' based on your technical screwups above)... apk

mmell LIBEL classics

[Anonymous Coward]

Saying I use hosts to evade police while I surf little boy porn http://slashdot.org/comments.p...

Libeling me saying my WARE IS A VIRUS etc. too? Please -> http://slashdot.org/comments.p... (1 of 2)

Libeling me saying my WARE IS A VIRUS etc. too? Please -> http://slashdot.org/comments.p... (2 of 2)

THEN RECANTING THAT LIBEL HERE http://slashdot.org/comments.p...

?

ERRONEOUSLY saying I was creating a DNS replacment (which it's not, it shores up DNS redirect security issues & resolves FASTER locally in RAM vs. remote lookups) -> http://tech.slashdot.org/comme...

Saying VI can do all my APK Hosts File Engine can do (not) & running -> http://slashdot.org/comments.p... when VI can't?

* Please... lol!

APK

P.S.=> You have SERIOUS issues - get over your ''geek angst" already (you're not even much of a 'geek' based on your technical screwups above)... apk

mmell caught supporting hmself by ac posts

[Anonymous Coward]

ROTFLMAO http://slashdot.org/comments.p... You're a fool that projected his own modus operandi doing it no less.

mmell busted supporting himself by ac posts

[Anonymous Coward]

ROTFLMAO http://slashdot.org/comments.p... You're a fool that projected his own modus operandi doing it no less.

mmell: How'd "eating your words" taste?

[Anonymous Coward]

Saying I use hosts to evade police while I surf little boy porn http://slashdot.org/comments.p...

Libeling me saying my WARE IS A VIRUS http://slashdot.org/comments.p... (1 of 2)

Libeling me saying my WARE IS A VIRUS http://slashdot.org/comments.p... (2 of 2)

THEN RECANTING THAT LIBEL HERE - "EATING YOUR WORDS" http://slashdot.org/comments.p...

?

ERRONEOUSLY saying I was creating a DNS replacment (which it's not, it shores up DNS redirect security issues & resolves FASTER locally in RAM vs. remote lookups) -> http://tech.slashdot.org/comme...

Saying VI can do all my APK Hosts File Engine can do (not) & running -> http://slashdot.org/comments.p... when VI can't?

* Please... lol!

APK

P.S.=> You have SERIOUS issues - get over your ''geek angst" already (you're not even much of a 'geek' based on your technical screwups above)... apk

Re:mmell: How'd "eating your words" taste?

[Anonymous Coward]

Alexander Peter Kowalksi is unemployed and unemployable.

Alexander Peter Kowalksi's low intelligence, extreme narcissism, and lack of technical ability make him unsuited for anything but menial labor.

Alexander Peter Kowalksi agrees with each and every one of the statements made above.

Alexander Peter Kowalksi will now prove these statements to be factually correct.

mmell: How'd "eating your words" taste?

[Anonymous Coward]

Saying I use hosts to evade police while I surf little boy porn http://slashdot.org/comments.p...

Libeling me saying my WARE IS A VIRUS http://slashdot.org/comments.p... (1 of 2)

Libeling me saying my WARE IS A VIRUS http://slashdot.org/comments.p... (2 of 2)

THEN RECANTING THAT LIBEL HERE - "EATING YOUR WORDS" http://slashdot.org/comments.p...

?

ERRONEOUSLY saying I was creating a DNS replacment (which it's not, it shores up DNS redirect security issues & resolves FASTER locally in RAM vs. remote lookups) -> http://tech.slashdot.org/comme...

Saying VI can do all my APK Hosts File Engine can do (not) & running -> http://slashdot.org/comments.p... when VI can't?

* Please... lol!

APK

P.S.=> You have SERIOUS issues - get over your ''geek angst" already (you're not even much of a 'geek' based on your technical screwups above)... apk

mmell: How'd "eating your words" taste?

[Anonymous Coward]

Saying I use hosts to evade police while I surf little boy porn http://slashdot.org/comments.p...

Libeling me saying my WARE IS A VIRUS http://slashdot.org/comments.p... (1 of 2)

Libeling me saying my WARE IS A VIRUS http://slashdot.org/comments.p... (2 of 2)

THEN RECANTING THAT LIBEL HERE - "EATING YOUR WORDS" http://slashdot.org/comments.p...

?

ERRONEOUSLY saying I was creating a DNS replacment (which it's not, it shores up DNS redirect security issues & resolves FASTER locally in RAM vs. remote lookups) -> http://tech.slashdot.org/comme...

Saying VI can do all my APK Hosts File Engine can do (not) & running -> http://slashdot.org/comments.p... when VI can't?

* Please... lol!

APK

P.S.=> You have SERIOUS issues - get over your ''geek angst" already (you're not even much of a 'geek' based on your technical screwups above)... apk

mmell: How'd "eating your words" taste?

[Anonymous Coward]

Saying I use hosts to evade police while I surf little boy porn http://slashdot.org/comments.p...

Libeling me saying my WARE IS A VIRUS http://slashdot.org/comments.p... (1 of 2)

Libeling me saying my WARE IS A VIRUS http://slashdot.org/comments.p... (2 of 2)

THEN RECANTING THAT LIBEL HERE - "EATING YOUR WORDS" http://slashdot.org/comments.p...

?

ERRONEOUSLY saying I was creating a DNS replacment (which it's not, it shores up DNS redirect security issues & resolves FASTER locally in RAM vs. remote lookups) -> http://tech.slashdot.org/comme...

Saying VI can do all my APK Hosts File Engine can do (not) & running -> http://slashdot.org/comments.p... when VI can't?

* Please... lol!

APK

P.S.=> You have SERIOUS issues - get over your ''geek angst" already (you're not even much of a 'geek' based on your technical screwups above)... apk

mmell: How'd "eating your words" taste?

[Anonymous Coward]

Saying I use hosts to evade police while I surf little boy porn http://slashdot.org/comments.p...

Libeling me saying my WARE IS A VIRUS http://slashdot.org/comments.p... (1 of 2)

Libeling me saying my WARE IS A VIRUS http://slashdot.org/comments.p... (2 of 2)

THEN RECANTING THAT LIBEL HERE - "EATING YOUR WORDS" http://slashdot.org/comments.p...

?

ERRONEOUSLY saying I was creating a DNS replacment (which it's not, it shores up DNS redirect security issues & resolves FASTER locally in RAM vs. remote lookups) -> http://tech.slashdot.org/comme...

Saying VI can do all my APK Hosts File Engine can do (not) & running -> http://slashdot.org/comments.p... when VI can't?

* Please... lol!

APK

P.S.=> You have SERIOUS issues - get over your ''geek angst" already (you're not even much of a 'geek' based on your technical screwups above)... apk

mmell: How'd "eating your words" taste?

[Anonymous Coward]

Saying I use hosts to evade police while I surf little boy porn http://slashdot.org/comments.p...

Libeling me saying my WARE IS A VIRUS http://slashdot.org/comments.p... (1 of 2)

Libeling me saying my WARE IS A VIRUS http://slashdot.org/comments.p... (2 of 2)

THEN RECANTING THAT LIBEL HERE - "EATING YOUR WORDS" http://slashdot.org/comments.p...

?

ERRONEOUSLY saying I was creating a DNS replacment (which it's not, it shores up DNS redirect security issues & resolves FASTER locally in RAM vs. remote lookups) -> http://tech.slashdot.org/comme...

Saying VI can do all my APK Hosts File Engine can do (not) & running -> http://slashdot.org/comments.p... when VI can't?

* Please... lol!

APK

P.S.=> You have SERIOUS issues - get over your ''geek angst" already (you're not even much of a 'geek' based on your technical screwups above)... apk

mmell: How'd "eating your words" taste?

[Anonymous Coward]

Saying I use hosts to evade police while I surf little boy porn http://slashdot.org/comments.p...

Libeling me saying my WARE IS A VIRUS http://slashdot.org/comments.p... (1 of 2)

Libeling me saying my WARE IS A VIRUS http://slashdot.org/comments.p... (2 of 2)

THEN RECANTING THAT LIBEL HERE - "EATING YOUR WORDS" http://slashdot.org/comments.p...

?

ERRONEOUSLY saying I was creating a DNS replacment (which it's not, it shores up DNS redirect security issues & resolves FASTER locally in RAM vs. remote lookups) -> http://tech.slashdot.org/comme...

Saying VI can do all my APK Hosts File Engine can do (not) & running -> http://slashdot.org/comments.p... when VI can't?

* Please... lol!

APK

P.S.=> You have SERIOUS issues - get over your ''geek angst" already (you're not even much of a 'geek' based on your technical screwups above)... apk

mmell: How'd "eating your wrods" taste?

[Anonymous Coward]

Saying I use hosts to evade police while I surf little boy porn http://slashdot.org/comments.p...

Libeling me saying my WARE IS A VIRUS http://slashdot.org/comments.p... (1 of 2)

Libeling me saying my WARE IS A VIRUS http://slashdot.org/comments.p... (2 of 2)

THEN RECANTING THAT LIBEL HERE - "EATING YOUR WORDS" http://slashdot.org/comments.p...

?

ERRONEOUSLY saying I was creating a DNS replacment (which it's not, it shores up DNS redirect security issues & resolves FASTER locally in RAM vs. remote lookups) -> http://tech.slashdot.org/comme...

Saying VI can do all my APK Hosts File Engine can do (not) & running -> http://slashdot.org/comments.p... when VI can't?

* Please... lol!

APK

P.S.=> You have SERIOUS issues - get over your ''geek angst" already (you're not even much of a 'geek' based on your technical screwups above)... apk