Only fortran doesn't suck

Pajaro · 2012-02-22 22:07:52

A physics high school teacher from Barcelona says that only fortran doesn't suck for computational programming. I've found that there are libraries like doubeldouble that report to give the advantages of fortran to c++. Also, python has the bigfloat package. Are they really by no means real competitors to the fortran programming language in what computational programming regards?

/dev/zero · 2012-02-22 22:27:43

Hi Pajaro,

This seems like an interesting topic, but I think you should focus it a bit more. Can you provide some literature which would support whatever claims have been made? Can you do some benchmarking of your own to illustrate your specific points or queries?

GERGE · 2012-02-22 22:55:36

Just because a language is used in HPC more than; well, Python, let's say; it doesn't mean that it is better than Python. Or worse for that matter. You can't really say One Language to bring them all and in the central processing unit bind them.

ANOKNUSA · 2012-02-22 22:58:52

I know practically nothing about programming languages, honestly. However, I do know a thing or two about blowhards in academia. This teacher likely has reasons for his opinion that are highly subjective, and years of having a captive audience who can't object to his assertions and don't know any better--basically, protection from real dissent--have likely strengthened his opinions. This is the very reason we have as many programming languages as we do, not to mention non-standardized electronics parts/form-factors, wine vintages, "X-Best-Everything-Ever" lists, car models, political ideologies...

The truth is, there is no one "best" anything with regard to the things I listed, as what's best in any given application likely doesn't fit well with other applications Which may in fact be what his comment concerned--only specific physics computations; we'll never know without any context. Besides, the word of "A teacher from Barcelona" isn't convincing in the least.

mcmillan · 2012-02-22 23:22:35

I'm pretty much in agreement with the others saying that the blanket statement that for all uses "only fortran doesn't suck" is wrong. I use fortran for quite a bit of my work since my advisor has never really wanted to learn anything new. That means if I write something both of us intend to use it pretty much has to be in fortran, though I've certainly found times I'd much rather used simpler languages available. Other than some languages being a better fit for certain purposes, there's also the consideration of how long goes into writing versus using it. If there's a fraction of more efficiency in running the program it's not necessarily worth taking a much longer time to write, and I've found my fortran subroutines tend to need more debugging than most of my perl and python scripts.

Trilby · 2012-02-23 00:09:43

As others have said, different tasks require different tools.

Fortran absolutely does suck for many tasks. But by purely computational standards fortran is at the head of the pack. Years ago - quite possibly when that teacher was learning programming - fortran did had a susbtantial lead over the competitors (again, within its niche of mathematical computation). But C compilers have come a long long way since then. Now, by the (admittedly limited amount of) tests I've read, good C code and good Fortran code perform comparably.

C++ may be a whole different beast though. I don't know why anyone would try to compare fortran and C++, let alone fortran and python. That's not even like comparing apples and oranges, it's like comparing apples and orangutans - they're completely f***ing different.

Edit: addendum: I would say learn some fortran - it builds character! ;o) But then learn a lot of C, some python, some of anything else. I've just ordered a Haskell book. I really have no opinion of Haskell on way or the other yet - but it has certainly peaked my curiosity. It does seem to be quite a different way of thinking about programming - and anything that can make you think in new ways is always good in my book.

Last edited by Trilby (2012-02-23 00:12:54)

Pajaro · 2012-02-23 07:13:47

ANOKNUSA wrote:

This teacher likely has reasons for his opinion that are highly subjective, and years of having a captive audience who can't object to his assertions and don't know any better--basically, protection from real dissent--have likely strengthened his opinions.

ANOKNUSA points very well what I am afraid is the real answer.

Also, many of you point that there is not enough background on the statement. The point is that there is not much information about it. It is a recent statement. When I studied, more than 10 years ago, and I didn't know much programming, they talked about more precision in calculations.

Trilby wrote:

But C compilers have come a long long way since then. Now, by the (admittedly limited amount of) tests I've read, good C code and good Fortran code perform comparably

This is what I am afraid that may have turned that statement invalid. As an example, when I was a kid I programmed in QBasic, and operations between integers that should return an integer had a chance to return a decimal number very close to the expected integer (i.e: 1/1 = 0,9999999). So, fortran was better than qbasic.

Also, I talked about c++ and python because they are programming languages that I use and implement FLOAT*16. The question does not care about performance. Performance is another subject.

Folllowing your answers and adding additional background, I believe the question could be rewritten like this:

"Using C++ gcc 4.6 or python 2.7 (cython), and implementing FLOAT*16 equivalents, is there still any advantage for fortran in computational programming, leaving performance aside?"

PS: I could write some programs that do some tests, but I don't have enough background with compilers to know what are the optimal tests to perform.

Last edited by Pajaro (2012-02-23 07:19:37)

Trilby · 2012-02-23 11:28:23

If performance is not a concern I'm not sure there's anything that would make fortran even an attractive options. You can get the same precision in nearly any language now and many take far fewer lines of code than fortran.

Performance is what fortran does.

litemotiv · 2012-02-23 13:13:24

I have a vacuum cleaner that doesn't suck, it's really annoying...

nsb · 2012-02-23 13:19:53

I am currently working in computational science and I had to program with python, C, C++ and Fortran.

If performance is not such a big problem (run time below 1h or so), you should use python, since the code is (or better: can be) really nice, and the nicer the code, the less mistakes you do. And in computational science it is more about making no mistakes, than producing wrong results.

That said, programming in Fortran (especially Fortran77) is a pain in the ass and you tend to make a lot of mistakes (note: code is more often read, than written).
Performance wise, it is no such a big deal, whether your program runs for 6 or 7 days: CPU hours are cheap, but the time you spend hacking and debugging the code is not.

Further, I searched a lot for performance differences between Fortran and C and there are almost none. C++ might have some overhead because of object oriented programming (OOP), but on the other hand, if you have a big program, nice structuring thanks to OOP can make you life as a hacker much easier. Usually the program spends a lot of time in some functions, where the OOP overhead does not really matter.

Trilby · 2012-02-23 16:33:59

Well ... performance can matter for some things.

I've recoded some R (statistical package) scripts that previously had to run overnight. I rewrote them in C, and had the running time down to a couple minutes. The person I did this for now thinks I'm a magician.

nsb · 2012-02-23 21:26:34

But then, this guy must have done something really wrong, or not? I usually find R pretty fast for what it does. Just the for loops are a bit slow.

Trillby wrote:

I rewrote them in C.

So I think -- as I said -- it is justified to assume, that with Fortran you would not save more time than with C.

Pajaro · 2012-02-24 22:11:13

very illustrating, nsb. Thank you.

bsilbaugh · 2012-02-26 00:15:15

When it comes to writing computer code, it is important to remember that the source code is effectively an engineering specification that describes the program to be built by the compiler. A source code is to a computer program as a blue-print is to a house. Accuracy and run-time performance are ultimately dictated by quality of compiler and the underlying hardware. Of course, it is harder to write optimizing compilers for some languages; thus, there may be cases where an algorithm written in C may result in a slower running program than an equivalent algorithm written in Fortran. Then again, many of the "Fortran is better" conclusions are based on linear algebra benchmarks, which only require (simple) array data structures; it would be interesting to see how the performance of a program expressed using the OOP features of modern Fortran (Fortan 2003) compares to that of C++. In terms of floating point accuracy, the only place that language choice would play a role is in the available data types, and I believe modern C, C++, and Fortran compilers support equivalent floating point types.

My current dissertation work is in field of computational aeromechanics (Computational Fluids Dynamics coupled with flexible multi-body dynamics). The codes that I help to develop typically fall into the category of high-performance scientific computing. From my experience over the past 5+ years, I would say we spend way more time (and mental energy) revising, debugging, and extending our codes than we do running them. That said, I've come to appreciate more expressive languages like C++ and Python, which are much easier to maintain and extend. Modern Fortran is becoming more expressive, but the language is still very clumsy compared to C++.

It is worth noting that the array features of modern Fortran work very well for linear algebra and certain numerical algorithms. And since the array is a language feature of Fortran, a Fortran compiler can easily optimize expressions involving arrays. (C/C++ does have a native array but it is much more primitive than the Fortran 90/95 array; e.g. C/C++ arrays do not support slicing, nor does C/C++ support array expressions.) The issue is that not every problem can be easily modeled using arrays. This is where the argument for using Fortran begins to loose traction--even in the scientific computing world.

Last edited by bsilbaugh (2012-02-26 00:16:06)

Avant-texte · 2012-02-26 01:52:21

Pajaro wrote:

Are they really by no means real competitors to the fortran programming language in what computational programming regards?

There's Lisp!

*lol*
But seriously, there's no one language that's good for everything. The vast number of language specs reflect the vast number of approaches that can be taken when processing information and as I'm sure you know, different types of problems call for different approaches.

Fortran makes it easy for the programmer to handle big and small computational problems in a way that's friendly enough to conventional *human* perspectives on mathamatics rather than dealing with how a computer processes things. This is one big reasons you find Fortran big in areas such as astronomy. Non-IT academics have good reasons for liking Fortran. They're studied in X, not computer science. Fortran is more accessable to such an audience. Many languages stand out not because of their internal implementation but for the approach they provide to human interaction.

Lisp was (and to a large degree, still is) known for being good in AI programing, providing an adaptable programing evironment via 'macros', and being comparitively quick for a high level language (even when matched against lower level languages).

C is good for telling a computer how to precisely do much of the low level tasks it must do in order to function without resorting to Assembly. This is why you find it the dominant force in system programming (kernels, drivers, etc).

An assembly language is meant to provide humans with an easier to remember mnemonics for the various machine code instructions so humans can have an easier time telling a computer what to do in it's native language.

C++ is a fork of C. It's intended to included the lower level advantages of C with the addition of easier to use high level constructs. It's become a long standing giant in game programing as that tends to require the use of special hardware in addition to complex graphical elements that would be near binding to deal with on the lower levels. Some find it appealing to have one language to handle both of those aspects.

Python is meant to be a very general purpose, 'batteries included' high levellevel utility with strong emphasis on readability and maintainability of code for users (programers). This makes it good for system administration, interfaces, and other traditionally scripted tasks. However, with the computing power of modern computers, 'easy languages' such as Python find themselves being given more & more interesting tasks that high level languages were originally too slow for.

Obviously these are just summaries and this list is an abreviated one, but I think it illustrates the situation well enough. It's a messy and crowded playing field and many drawn to the idea of a simpler set or single perfect language that can clean it up, but all our computational (and human) needs have yet to be solved by a single language.

Arch Linux

#1 2012-02-22 22:07:52

Only fortran doesn't suck

#2 2012-02-22 22:27:43

Re: Only fortran doesn't suck

#3 2012-02-22 22:55:36

Re: Only fortran doesn't suck

#4 2012-02-22 22:58:52

Re: Only fortran doesn't suck

#5 2012-02-22 23:22:35

Re: Only fortran doesn't suck

#6 2012-02-23 00:09:43

Re: Only fortran doesn't suck

#7 2012-02-23 07:13:47

Re: Only fortran doesn't suck

#8 2012-02-23 11:28:23

Re: Only fortran doesn't suck

#9 2012-02-23 13:13:24

Re: Only fortran doesn't suck

#10 2012-02-23 13:19:53

Re: Only fortran doesn't suck

#11 2012-02-23 16:33:59

Re: Only fortran doesn't suck

#12 2012-02-23 21:26:34

Re: Only fortran doesn't suck

#13 2012-02-24 22:11:13

Re: Only fortran doesn't suck

#14 2012-02-26 00:15:15

Re: Only fortran doesn't suck

#15 2012-02-26 01:52:21

Re: Only fortran doesn't suck

Board footer