Bad programming skills = biggest hurdle to astronomy research

[Deadstar]

This seems like a good thread to ask this question but what languages would you guys say are the 'best' for writing astrophysics tyoe simulations (i.e. 3+ body problem simulations).

I began with Maple before I had any intentions to program these types of problems and have moved onto Matlab as maple isn't the best for high end computing. I have a feeling C++ would perhaps be a good shout but since I have a course on Matlab this year I'll be mainly working with that. I also find that the more I work with languages like Matlab the more I seem to understand C++ code despite never having worked with it.

I read somewhere that you should look at programming less in terms of learning a language and more in terms of learning the basics and fundementals of programming such as OOP.

 

[jsiples]

This is a website I found a while back, its a great comparison of programming languages and their speed.

http://shootout.alioth.debian.org/fastest-programming-language.php

I think you're right in choosing C++ as a language, as you can see, C is minimally faster, but slightly more annoying to code at times so C++ is a happy medium. Speaking of happy medium, I tend to fall into that category when it comes to this topic, my schooling (while not finished) was for Astro-Engineering, but I now hold a job as Linux Sysadmin and have done a rather extensive amount of programming. I think what someone mentioned before its like we have to learn all over again, we've gotten so used to fast computers and not caring about efficiency, but when you are dealing with this large of numbers, it is like going back 30 years with computing power. Unfortunately, I agree that it's a vicious cycle of astronomers not being programmers and vice versa, it makes it hard to program efficiently when you don't know what you're programming, and it takes years of practice to know how to program efficiently.

while(astronomer == programmer)
{
printf(&efficient_program);
}

EDIT: Coming from a background in a variety of languages, I agree with what you said about learning the basics of programming over the language, you'll learn quickly most languages are very similar and you can adapt to them quickly.

 

[Simfish]

Wow, very interesting link! Why is FOTRAN Intel so slow? My professors always told me to use either C/C++ or FORTRAN since they were the fastest.

FORTRAN is nice for MPI/OpenMP integration too (if you want to parallelize things). I'm sure C also has MPI/OpenMP integration, but I'm not sure if it's as fluid.

 

[D H]

This is a website I found a while back, its a great comparison of programming languages and their speed.

Eh. The question raised by Simfish immediately arises on seeing stuff like that:

Wow, very interesting link! Why is FOTRAN Intel so slow? My professors always told me to use either C/C++ or FORTRAN since they were the fastest.

The answer is (at least) twofold:

1. They are combining metrics from multiple programs, some of which are not Fortran's forte. Who cares how well Fortran performs in handling strings?
2. The programs appear to be not so well-written. Some of the so-called benchmarks are so poorly written that they don't even compile. This is a failure of the benchmarking, not of the language.

The tests in which Fortran fares very poorly are in part a reflection of the limitations of Fortran (yes, Fortran isn't so good at handling strings), but also appear to be in part due to giving the programming assignment to someone not well-versed in Fortran.

Note well: I am not a Fortran advocate. Far from it; I gladly abandoned the language a couple of decades ago. One doesn't have to be a Fortran advocate to say that those benchmarks are more than a bit suspect. That said, Fortran does not always look so bad at debian.org. In the n-body problem Fortran is the winner: http://shootout.alioth.debian.org/u32q/performance.php?test=nbody .