5 ms·

I worked as a programmer in a molecular dynamics research group for a while. I was asked to work in Python because it was what the boss was familiar with - so t

I worked as a programmer in a molecular dynamics research group for a while. I was asked to work in Python because it was what the boss was familiar with - so there's some of the same inertia happening again, just with a new(er) language, I guess. Speed is not a huge issue if you're happy to leave your simulation running overnight anyway, or if you have the option to just throw more and more cores at the problem (or in our case, both). The goal is to get your papers published. Code developing/interpreting/debugging time is generally far more serious an obstacle to that goal than simulation speed. I was the only developer there. Everyone else in the group coded on an almost daily basis, but none of them considered themselves programmers, and very few of them actually learn about good programming practices. They're biophysics researchers. Having not worked in Python much before I was also pretty pleased to find that, having determined that I needed to use Dijkstra's algorithm for path-finding and then working out the smallest Standard Deviation between certain sets of data points, Python came with libraries to do both of those things off the cuff. It's just so easy, I can see why it has a favoured place in this field.

War_Machine 9y ago
As long as Fortran is able to keep up with Python's capabilities (or any other language's for that matter), there seems to be absolutely no reason to make a change considering Fortran's history and familiarity in Physics. In other words, other languages need to make a big enough leap forward or Fortran to lag behind enough to justify a change. Your example just shows that it's fine to use other languages, and I agree, but it's not very compelling in promoting a change in language.
hzhou321 9y ago
> Speed is not a huge issue if you're happy to leave your simulation running overnight anyway, or if you have the option to just throw more and more cores at the problem What about those cases that it's the matter between throwing at 1000 core cluster and wether we can have results before next conference in a couple months. That is what really defines the scientific programming -- it's about feasible and infeasible. For other jobs, isn't it just matter of taste?
- lostboys67 9y ago
  Depends not all scientific programming is at universities when I worked for BHR group (a Hydro dynamics research organisation) some times we had emergency projects that had < 24 hour turn around. I recall one where a clinet had had a serious issue at a plant and we ran the simulation and produced a report in a single day

War_Machine 9y ago

As long as Fortran is able to keep up with Python's capabilities (or any other language's for that matter), there seems to be absolutely no reason to make a change considering Fortran's history and familiarity in Physics. In other words, other languages need to make a big enough leap forward or Fortran to lag behind enough to justify a change. Your example just shows that it's fine to use other languages, and I agree, but it's not very compelling in promoting a change in language.

hzhou321 9y ago

> Speed is not a huge issue if you're happy to leave your simulation running overnight anyway, or if you have the option to just throw more and more cores at the problem What about those cases that it's the matter between throwing at 1000 core cluster and wether we can have results before next conference in a couple months. That is what really defines the scientific programming -- it's about feasible and infeasible. For other jobs, isn't it just matter of taste?

lostboys67 9y ago
Depends not all scientific programming is at universities when I worked for BHR group (a Hydro dynamics research organisation) some times we had emergency projects that had < 24 hour turn around. I recall one where a clinet had had a serious issue at a plant and we ran the simulation and produced a report in a single day