12 ms·

"Professors usually have this legacy code on hand (often code they wrote themselves decades ago) and pass this code on to their students. This saves their stude

"Professors usually have this legacy code on hand (often code they wrote themselves decades ago) and pass this code on to their students. This saves their students time, and also takes uncertainty out of the debugging process." This is so true. I'm a PhD student in physics using Fortran for pretty much that reason. At the start of my PhD, in response to my supervisor telling me I should learn Fortran to modify our current codebase, I asked if I could rewrite what I'd be working on into C++ first, since I was already familiar with it and wanted to bring future development into a more "modern" language. His response was "You could do that and it would probably be enough to earn your PhD, since it'll take you at least three years. But I suspect you'll want to work on something else during that time". He was right. I later learnt one of our "rival groups" attempted the same thing and it took three phd students working full time for a year to rewrite their code from fortran to C++.

sidlls 9y ago
Yep. Most of my programming classes were either in pascal or c when I was in undergrad, but in my physics courses, all the way through my graduate education, I used FORTRAN. It's because physics doesn't change that much over the years, FORTRAN code that is time-tested and that works exists and there's no need to re-invent the wheel in another language when more interesting and important problems exist to solve.
- scottlegrand2 9y ago
  David Baker's Rosetta code, which made him a pile of money, is IMO a spectacular example of craptastic C++ written by people who really didn't understand C++ but didn't let that deter them from using every single feature of the language, badly. Some years back we tried to port it to CUDA but there were so many levels of indirection, dereferencing, and virtual functions that it was nearly impossible to make any progress. In contrast, porting the 30+ year old molecular Dynamics package AMBER to CUDA took about 3 months and probably established me as a CUDA expert. In my opinion its well-maintained Fortran 90 code was far easier to understand and refactor. While my primary languages today are C++ and CUDA, there is something clean about Fortran when it comes to understanding underlying algorithms. I have a similar opinion about well written C code.
  - jacquesm 9y ago
    That's the whole trick. Good code makes complex stuff look simple. Bad code makes simple stuff look complex.
    - derefr 9y ago
      I wonder if you can formalize this. Assume TDD, and then measure the compressed size of the codebase vs. the compressed size of the test suite. Code is "worse" when it requires more "stuff" (informational entropy) to do less "stuff" (pass test cases.) The compression would presumably remove the redundancy of the language itself as a factor (including differences in idiomatic cyclomatic-complexity "depths" of various stdlibs), and also remove any redundancy in the way the test cases were specified. So it'd be down to a measure of how much circumlocution and over-engineering you did in the process of implementing the solution. I'd worry slightly that code-golf solutions would be rewarded, though. Maybe pass everything through an obfuscator + linter before computing the metric, so that things like identifier lengths and spaces aren't considered.
    - aswanson 9y ago
      That quote should be the metric by which code/languages are judged.
      - S4M 9y ago
        How do you measure the complexity of the code, and most importantly, of the problem that the code is solving?
        aswanson 9y ago
        Complexity analysis.
  - WalterBright 9y ago
    > using every single feature of the language I constantly run into code where someone takes an obscure corner case in the language, and builds an entire edifice around it.
quadruplebond 9y ago
Potentially your "rival groups" will have a long term advantage now though. This might be bad for the graduate students that did the work, but could be good for the professor and group over the next decade. Graduate students need to think in terms of 4-6 years while forward looking professors might want to think in terms of 5-15 years.
- PascLeRasc 9y ago
  That was without a doubt pretty bad for those grad students' careers. That kind of work shouldn't have been done by anyone without tenure.
  - quadruplebond 9y ago
    Not necessarily. It was definitely bad if they want to become academics and needed to publish papers. But if they knew from the start what they were getting into and wanted to transition from physics to software development then it might not have been so bad (although there might have been a more optimal path). A bad advisor wouldn't care what his students wanted, but a good advisor might still have students work on this kind of project as long as they were aware it wasn't going to help them get a tenure track position in the future. If they wanted to go work at a national lab doing HPC work and programing it might have been plenty ok for their career (This is what I am transitioning to now) or if they want to go work for a hedge fund or apple it might also be an okay option.
  - thicknavyrain 9y ago
    I might actually disagree on this one. If it was the first year of their PhD, then yes, it does seem like grunt work which is dissatisfying, but they will have fully learned the ins and outs of their group's code framework. In the process, they would have understood nearly every approach taken by the group towards producing the results that it does, and I bet that has helped them when they've ended up modifying that same code later for their research. And with fewer supervisor meetings to work out exactly what X, Y and Z part of the code does because they will have worked on it themselves. I'd say I've easily spent 6 months just spending time getting my head around all the code we work with anyway, so at the very least, I hope that made their following years of research more productive.
serf 9y ago
His response was "You could do that and it would probably be enough to earn your PhD, since it'll take you at least three years. But I suspect you'll want to work on something else during that time". as someone who had contact with that codebase, do you have any insights as to why that is? Was it the sheer size of the thing? Was it some nuance that Fortran had as an advantage over other languages? was the math just difficult to follow? Genuine curiousity.
- thicknavyrain 9y ago
  Pretty much just size! There was about 20,000 lines of it, it's legacy code that has been gradually added to since the 1980s, so it would have taken a while to rewrite all the parts to work with each other. Perhaps some day though.
  - pbhjpbhj 9y ago
    What's the code do? [physics grad level description would be fine] It must surely be generic equipment management, you're not running experiments in physics that are > 30 years old, surely?
    - euyyn 9y ago
      Started in the 80s doesn't mean the code is 30 years old, as they keep adding to it and modifying it in Fortran. Plus most of the analysis part is probably just math routines that don't need modification ever after.
      - pbhjpbhj 9y ago
        Doesn't mean it isn't c.37 years old either ... I think we need specifics to progress this conversation usefully.
  - walshemj 9y ago
    Only 20k I have worked on bigger Fortran systems doing billing systems for a telco oddly enough.
ChuckMcM 9y ago
Now you need to do a follow on study to see how much science the 'rival' group does with a more modern codebase than your 'legacy' group does. Would you know if there are enough examples of two groups who have diverged like this to get meaningful (as in statistically significant) results on the cost benefit of porting / not porting?
- sampo 9y ago
  > Now you need to do a follow on study to see how much science the 'rival' group does with a more modern codebase than your 'legacy' group does. I would guess that a C++ codebase written by PhD students, not by seasoned C++ experts, is more complicated and much slower to debug, than a corresponding Fortran codebase.
  - adrianN 9y ago
    Well, that Fortran codebase probably also was written in large parts by PhD students, not export Fortran programmers.
    - sitkack 9y ago
      C++ is a more efficient language to write difficult to track down bugs in than Fortran.
    - sampo 9y ago
      Fortran is a much simpler and safer language than C++. And faster to learn. Fortran is even somewhat simpler than C or Java, whereas C++ is probably the most complicated language in the known universe. So especially in the hands of non-experts, Fortran should produce less bugs.
      - aswanson 9y ago
        Funny as hell. Perl, though.
      - HelloNurse 9y ago
walshemj 9y ago
I recall that a local aerospace outfit was looking for C++ programmers to re do a metric F%^K ton of Fortran into c++. I actually rang the recruiter to query why would not be simpler to train your existing staff to use Fortran - the add stayed up for years and years I always wonder if it ever got ported.
- andai 9y ago
  Did you get an answer about why not just train them to use Fortran?
  - walshemj 9y ago
    Not really its very odd as when I worked at on of this organisations peers straight from high school I was told to get a fortran book from the company library and learn it I also had an hours basic instruction in how to boot the PDP11
dwc 9y ago
When I was working for LROC, most of the planetary geologists used IDL (Fortran-ish in many ways) but there was still plenty of actual FORTRAN floating around. Oh, look, in the last couple of years this legend of photometry worked up this new method and here's the associated Fortran code. That kind of thing. I did actually rewrite both IDL and Fortran, but it was always smallish, single-purpose programs or functions. Note that the SPICE Toolkit[1] is still written in Fortran today, translated to C using f2c, and the C version used as the base for other language support. The Fortran part is unlikely to ever go away, since support for processing past missions is crucially important and all that processing code was written in Fortran. Also, talk about your stable, backward compatible APIs... 1. https://naif.jpl.nasa.gov/naif/toolkit.html https://naif.jpl.nasa.gov/naif/toolkit.html
- aleph_naught 9y ago
  Just before I left JPL, the SPICE team had announced a plan for a complete rewrite in C++. The SPICE team is exceptionally small (especially considereing how widely used and impactful the software has been). IIRC since the team’s inception, to the time I left, it has been about 4-5 people. Their primary goal has always been stability and correctness over speed. Recalling a conversation with Boris, they have something like 2.5 million lines of test code. So it would take some time to port over. The codebase is probably the most documented I have ever seen, every mathematical deduction is described in great detail. That being said, as someone who has integrated CSPICE into several C++ and python projects, the modernization would be a very welcome change. The current arch depends far too much on global state, and none of it is threadsafe. https://naif.jpl.nasa.gov/naif/Toolkit_evolution_R2 https://naif.jpl.nasa.gov/naif/Toolkit_evolution_R2
  - dwc 9y ago
    > Recalling a conversation with Boris Good to know Boris is still there! Was Chuck still heading up the team when you left? > a plan for a complete rewrite in C++ Oh, no! That's a real shame. I'd be all for a rewrite, especially considering their insane test coverage, but that decision worries me. > That being said, as someone who has integrated CSPICE into several C++ and python projects, the modernization would be a very welcome change. As someone who worked mostly with CSPICE in C but also with some other non-Fortran toolkits, I agree.
klipt 9y ago
Lawrence Berkeley Lab has a C++ to Fortran compiler called FABLE: http://cci.lbl.gov/fable/ http://cci.lbl.gov/fable/ Curious if anyone in your group considered using it?
osteele 9y ago
"Within a month of his arrival, Randy solved some trivial computer problems for one of the other grad students. A week later, the chairman of the astronomy department called him over and said, “So, you’re the UNIX guru.” "At the time, Randy was still stupid enough to be flattered by this attention, when he should have recognized them as bone-chilling words. Three years later, he left the Astronomy Department without a degree, and with nothing to show for his labors except six hundred dollars in his bank account and a staggeringly comprehensive knowledge of UNIX." – Neal Stephenson, _Cryptonomicon_ (p. 78). HarperCollins.
- LeifCarrotson 9y ago
  I am unfamiliar with the passage. But it describes two options: 1. "A staggeringly comprehensive knowledge of UNIX", three years of domain-specific education, and a network of people who trust you to--no, who depend on you to be able to get things done with that knowledge 2. A piece of paper just like everyone else in the department. And while the former might be more difficult to make use of, I think it could be much more valuable in the long run.
  - robotresearcher 9y ago
    No, he left without a degree.
  - blacksmythe 9y ago
    A good point, but the text suggests there are ways to get this knowledge. >> except six hundred dollars in his bank account
    - blacksmythe 9y ago
      >> are ways to get this knowledge. Edit: are ways 'better' to get this knowledge.
  - newen 9y ago
    More like two options: 1. "A staggeringly comprehensive knowledge of UNIX", three years of domain-specific education, and a network of people who trust you to--no, who depend on you to be able to get things done with that knowledge 2. A piece of paper just like everyone else in the department, three years of domain-specific education, and a network of people who trust you to--no, who depend on you to be able to get things done with that knowledge (and probably a girlfriend)
bluedino 9y ago
>> Professors usually have this legacy code on hand (often code they wrote themselves decades ago) and pass this code on to their students So cut-n-paste code. The students are running code that they don't really know what it does, it might not even be correct...it's like StackOverflow in academia.
- robotresearcher 9y ago
  Did you write your own libc and libm? Compiler? We are ALL using code we didn't write.
  - spc476 9y ago
    Daniel J. Bernstein did that for all of his projects (qmail, daemontools, etc) and I don't see him getting a ton of flack over doing that.
    - dagw 9y ago
      He certainly used to back when qmail vs postfix as the better sendmail replacement was a real debate 'we' where regularly having. If he's not getting any flack today it's most likely because he's fallen more or less into irrelevance when it comes to practical day to day operations.
ptero 9y ago
Yes, C++ does not buy you that much. Sure, it is a more modern language, but when used by scientists (not software engineers) the advantages are hardly earth shattering. Much of complexity is hidden (as it should be) into libraries. IMO, Python stands a better chance of breaking the Fortran's lock on physics related computing. Give it a few more years and enough numpy-based libraries might make Python a real competitor. My 2c
- dsacco 9y ago
  I have to be honest with you, as someone who writes in both C++ and Python, I really do not see Python being more of a candidate than C++ for displacing Fortran. Can you clarify why you think Python might be able to do it? For scientific computation with high performance requirements, Python is not competitive with Fortan or C++. For work that continues to happen in Fortran due to "academic inertia", my impression (and vague experience) is that researchers find the convenience of what they're accustomed to (Fortran) to be greater than the convenience of things like rapid prototyping offered by the various Python scientific computing and data analysis libraries. There is a mental overhead is switching, and I think most academics are sort of okay writing code in whatever is familiar and battle-tested if it means they can focus more on the research at hand. In other words, I'm not saying you're wrong, but I'm not following your reasoning.
  - vacri 9y ago
    In a previous discussion of this kind (I'm not in this area myself), a scientist had said that the speed of the languages is less important than iterating the algorithms, and it was a lot easier for non-developer scientists to work with python than with C++.
  - cknight 9y ago
    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.
felipemnoa 9y ago
>>I later learnt one of our "rival groups" attempted the same thing and it took three phd students working full time for a year to rewrite their code from fortran to C++. I wonder if there are any transcoders for Fortran to C++? I wonder if there is even a market for something like that? I've written alpha versions of transcoders for C to Java and Java to Objective-C and I think I could do the same for Fortran to another language but why? Writing a transcoder first is the right way to do it and it should take you a couple of months to do it, especially if you already have some experience with this kind of stuff. Definitely less than a year for a single person. I would not try to translate the code by hand. It would be a never ending project full of bugs. Edit: Apparently there are plenty of Fortran to C++ transcoders. Here is just one I found during my google search: http://cci.lbl.gov/fable/ http://cci.lbl.gov/fable/ No idea how good they work.
guitarbill 9y ago
Trusting legacy code with few users is a dangerous proposition. My roommate was given some "state-of-the-art" code and told to run simulations with it. The only graphical output was postscript (for some reason), so every frame was 150 MiB and took minutes to dump - so usually, this was only done at the end to show the result. I managed to hack in a step which just dumped the memory of resulting frame to a file, and then we wrote a Python script to read that and produces a PNG. We combine the PNGs into an animation and show someone else in the department because the supervisor wasn't in that day. "Cool! But, hrmm, those boundary conditions look wrong." Sadly, this was 2/3s into his Masters. Like much now in Physics, the original code was simply incorrect. This happens all the time, and papers get retracted because of it - well, that's the best case if somebody notices. At the end of the day, programming languages come with eco-systems, and must be chosen solely as a tool. The problem is not with Fortran, but that often Fortran == outdated development practices and in Physics horrible code hacked on by 10+ people without prior programming experience.
- cryptonector 9y ago
  It's going to have few users anyways, since it's so specialized. And that's also why it will be legacy.
- EvgeniyZh 9y ago
  Another problem is that most people who wrote this code aren't programmers - they don't write clean code, no tests, etc. They don't really know those are important. Sometimes the code that is used and updated for years looks like a dirty prototype. I don't know what can be done about it except hiring programmers to write code, which wouldn't be either easy or cheap
  - guitarbill 9y ago
    Well, I guess one moral of the story is that doing image manipulation is easier in Python than Fortran, so it's again using the right tool for the job. And I think the push for Physicists to use Python if possible is good, as the learning curve is less steep. And once you have that tool at your disposal, you might use it more often (instead of Excel). I can see many projects being improved by providing a Python pre-processor that writes out e.g. a binary config file, the hard-code Fortran/C simulation code reads that, and spits out the simulation results, and then having a Python post-processor that does the pretty stuff at the end. Academically, it seems that pairing CS undergrads with Physics undergrads to do e.g. a molecular dynamics (MD) course would be cool. The Physics behind MD isn't too hard, and given the right parameters the programming part would be manageable. Then again, CS undergrads aren't necessarily great programmers either... Clean code and tests are overrated. Version control and a big eco-system is underrated. It's like maths, physicists don't understand maths, they just use it like a carpenter uses a nail without understanding metallurgy, or a programmer uses a CPU without understanding solid-state physics. And that's okay.
jordanpg 9y ago
It's not just that the code is already written and debugged; in many cases results have been published using analysis done with this legacy software. Using the same code ensures a certain amount of consistency between experiments from the same lab. From this point of view, rewriting code is an extremely high-risk proposition. As we know, the likelihood of discovering bugs during this process is quite high.
bluetwo 9y ago
Why isn't Julia a good choice?
hilbert42 9y ago
"...and it took three phd students working full time for a year to rewrite their code from fortran to C++" There's a salient lesson here. Clearly, this was a stupid decision for two reasons: (1) there are many thousands of scientific routines that have had 40-60 years of fine honing and careful debugging and they just work! (For instance, we send voyagers—Voyager, Cassini, etc.—to the end of the solar system and they invariably get there; the Fortran routines that get them there do exactly what they're supposed to do (unlike much of today's poorly written C code)! (2) Rewriting that already-reliable fully-debugged Fortran code into any other language will almost certainly make it far less reliable, thus it's a no-brainer to stick with the original .F source. Yes, Fortran is simpler than C [consider it BASIC on steriods] and years ago it had long since evolved well past John Backus's 1954 incarnation of the language into solid workhorse that both physicists and engineers use regularly. Just because something is old and out of fashion doesn't mean that it's broken or doesn't work well. (Longevity ensures that there's been sufficient time for many hands to make it reliable.) (Oh, BTW, I'm reminded that decades ago when I was just beginning to learn Fortran using punch cards on an IBM360 mainframe with the WATFOR FORTRAN-IV compiler, that I made four errors in only six lines of code. After dutifully printing ERROR against each offending line, the compiler finished with the message: "YOU NEED TO SEEK ANOTHER CAREER " or words to that effect [yes, it was in uppercase]. Eventually, I got considerably better.)

sidlls 9y ago

Yep. Most of my programming classes were either in pascal or c when I was in undergrad, but in my physics courses, all the way through my graduate education, I used FORTRAN. It's because physics doesn't change that much over the years, FORTRAN code that is time-tested and that works exists and there's no need to re-invent the wheel in another language when more interesting and important problems exist to solve.

scottlegrand2 9y ago
David Baker's Rosetta code, which made him a pile of money, is IMO a spectacular example of craptastic C++ written by people who really didn't understand C++ but didn't let that deter them from using every single feature of the language, badly. Some years back we tried to port it to CUDA but there were so many levels of indirection, dereferencing, and virtual functions that it was nearly impossible to make any progress. In contrast, porting the 30+ year old molecular Dynamics package AMBER to CUDA took about 3 months and probably established me as a CUDA expert. In my opinion its well-maintained Fortran 90 code was far easier to understand and refactor. While my primary languages today are C++ and CUDA, there is something clean about Fortran when it comes to understanding underlying algorithms. I have a similar opinion about well written C code.
- jacquesm 9y ago
  That's the whole trick. Good code makes complex stuff look simple. Bad code makes simple stuff look complex.
  - derefr 9y ago
    I wonder if you can formalize this. Assume TDD, and then measure the compressed size of the codebase vs. the compressed size of the test suite. Code is "worse" when it requires more "stuff" (informational entropy) to do less "stuff" (pass test cases.) The compression would presumably remove the redundancy of the language itself as a factor (including differences in idiomatic cyclomatic-complexity "depths" of various stdlibs), and also remove any redundancy in the way the test cases were specified. So it'd be down to a measure of how much circumlocution and over-engineering you did in the process of implementing the solution. I'd worry slightly that code-golf solutions would be rewarded, though. Maybe pass everything through an obfuscator + linter before computing the metric, so that things like identifier lengths and spaces aren't considered.
  - aswanson 9y ago
    That quote should be the metric by which code/languages are judged.
    - S4M 9y ago
      How do you measure the complexity of the code, and most importantly, of the problem that the code is solving?
      - aswanson 9y ago
        Complexity analysis.
- WalterBright 9y ago
  > using every single feature of the language I constantly run into code where someone takes an obscure corner case in the language, and builds an entire edifice around it.

quadruplebond 9y ago

Potentially your "rival groups" will have a long term advantage now though. This might be bad for the graduate students that did the work, but could be good for the professor and group over the next decade. Graduate students need to think in terms of 4-6 years while forward looking professors might want to think in terms of 5-15 years.

PascLeRasc 9y ago
That was without a doubt pretty bad for those grad students' careers. That kind of work shouldn't have been done by anyone without tenure.
- quadruplebond 9y ago
  Not necessarily. It was definitely bad if they want to become academics and needed to publish papers. But if they knew from the start what they were getting into and wanted to transition from physics to software development then it might not have been so bad (although there might have been a more optimal path). A bad advisor wouldn't care what his students wanted, but a good advisor might still have students work on this kind of project as long as they were aware it wasn't going to help them get a tenure track position in the future. If they wanted to go work at a national lab doing HPC work and programing it might have been plenty ok for their career (This is what I am transitioning to now) or if they want to go work for a hedge fund or apple it might also be an okay option.
- thicknavyrain 9y ago
  I might actually disagree on this one. If it was the first year of their PhD, then yes, it does seem like grunt work which is dissatisfying, but they will have fully learned the ins and outs of their group's code framework. In the process, they would have understood nearly every approach taken by the group towards producing the results that it does, and I bet that has helped them when they've ended up modifying that same code later for their research. And with fewer supervisor meetings to work out exactly what X, Y and Z part of the code does because they will have worked on it themselves. I'd say I've easily spent 6 months just spending time getting my head around all the code we work with anyway, so at the very least, I hope that made their following years of research more productive.

serf 9y ago

His response was "You could do that and it would probably be enough to earn your PhD, since it'll take you at least three years. But I suspect you'll want to work on something else during that time". as someone who had contact with that codebase, do you have any insights as to why that is? Was it the sheer size of the thing? Was it some nuance that Fortran had as an advantage over other languages? was the math just difficult to follow? Genuine curiousity.

thicknavyrain 9y ago
Pretty much just size! There was about 20,000 lines of it, it's legacy code that has been gradually added to since the 1980s, so it would have taken a while to rewrite all the parts to work with each other. Perhaps some day though.
- pbhjpbhj 9y ago
  What's the code do? [physics grad level description would be fine] It must surely be generic equipment management, you're not running experiments in physics that are > 30 years old, surely?
  - euyyn 9y ago
    Started in the 80s doesn't mean the code is 30 years old, as they keep adding to it and modifying it in Fortran. Plus most of the analysis part is probably just math routines that don't need modification ever after.
    - pbhjpbhj 9y ago
      Doesn't mean it isn't c.37 years old either ... I think we need specifics to progress this conversation usefully.
- walshemj 9y ago
  Only 20k I have worked on bigger Fortran systems doing billing systems for a telco oddly enough.

ChuckMcM 9y ago

Now you need to do a follow on study to see how much science the 'rival' group does with a more modern codebase than your 'legacy' group does. Would you know if there are enough examples of two groups who have diverged like this to get meaningful (as in statistically significant) results on the cost benefit of porting / not porting?

sampo 9y ago
> Now you need to do a follow on study to see how much science the 'rival' group does with a more modern codebase than your 'legacy' group does. I would guess that a C++ codebase written by PhD students, not by seasoned C++ experts, is more complicated and much slower to debug, than a corresponding Fortran codebase.
- adrianN 9y ago
  Well, that Fortran codebase probably also was written in large parts by PhD students, not export Fortran programmers.
  - sitkack 9y ago
    C++ is a more efficient language to write difficult to track down bugs in than Fortran.
  - sampo 9y ago
    Fortran is a much simpler and safer language than C++. And faster to learn. Fortran is even somewhat simpler than C or Java, whereas C++ is probably the most complicated language in the known universe. So especially in the hands of non-experts, Fortran should produce less bugs.
    - aswanson 9y ago
      Funny as hell. Perl, though.
    - HelloNurse 9y ago

walshemj 9y ago

I recall that a local aerospace outfit was looking for C++ programmers to re do a metric F%^K ton of Fortran into c++. I actually rang the recruiter to query why would not be simpler to train your existing staff to use Fortran - the add stayed up for years and years I always wonder if it ever got ported.

andai 9y ago
Did you get an answer about why not just train them to use Fortran?
- walshemj 9y ago
  Not really its very odd as when I worked at on of this organisations peers straight from high school I was told to get a fortran book from the company library and learn it I also had an hours basic instruction in how to boot the PDP11

dwc 9y ago

When I was working for LROC, most of the planetary geologists used IDL (Fortran-ish in many ways) but there was still plenty of actual FORTRAN floating around. Oh, look, in the last couple of years this legend of photometry worked up this new method and here's the associated Fortran code. That kind of thing. I did actually rewrite both IDL and Fortran, but it was always smallish, single-purpose programs or functions. Note that the SPICE Toolkit[1] is still written in Fortran today, translated to C using f2c, and the C version used as the base for other language support. The Fortran part is unlikely to ever go away, since support for processing past missions is crucially important and all that processing code was written in Fortran. Also, talk about your stable, backward compatible APIs... 1. https://naif.jpl.nasa.gov/naif/toolkit.html https://naif.jpl.nasa.gov/naif/toolkit.html

aleph_naught 9y ago
Just before I left JPL, the SPICE team had announced a plan for a complete rewrite in C++. The SPICE team is exceptionally small (especially considereing how widely used and impactful the software has been). IIRC since the team’s inception, to the time I left, it has been about 4-5 people. Their primary goal has always been stability and correctness over speed. Recalling a conversation with Boris, they have something like 2.5 million lines of test code. So it would take some time to port over. The codebase is probably the most documented I have ever seen, every mathematical deduction is described in great detail. That being said, as someone who has integrated CSPICE into several C++ and python projects, the modernization would be a very welcome change. The current arch depends far too much on global state, and none of it is threadsafe. https://naif.jpl.nasa.gov/naif/Toolkit_evolution_R2 https://naif.jpl.nasa.gov/naif/Toolkit_evolution_R2
- dwc 9y ago
  > Recalling a conversation with Boris Good to know Boris is still there! Was Chuck still heading up the team when you left? > a plan for a complete rewrite in C++ Oh, no! That's a real shame. I'd be all for a rewrite, especially considering their insane test coverage, but that decision worries me. > That being said, as someone who has integrated CSPICE into several C++ and python projects, the modernization would be a very welcome change. As someone who worked mostly with CSPICE in C but also with some other non-Fortran toolkits, I agree.

klipt 9y ago

Lawrence Berkeley Lab has a C++ to Fortran compiler called FABLE: http://cci.lbl.gov/fable/ http://cci.lbl.gov/fable/ Curious if anyone in your group considered using it?

osteele 9y ago

"Within a month of his arrival, Randy solved some trivial computer problems for one of the other grad students. A week later, the chairman of the astronomy department called him over and said, “So, you’re the UNIX guru.” "At the time, Randy was still stupid enough to be flattered by this attention, when he should have recognized them as bone-chilling words. Three years later, he left the Astronomy Department without a degree, and with nothing to show for his labors except six hundred dollars in his bank account and a staggeringly comprehensive knowledge of UNIX." – Neal Stephenson, _Cryptonomicon_ (p. 78). HarperCollins.

LeifCarrotson 9y ago
I am unfamiliar with the passage. But it describes two options: 1. "A staggeringly comprehensive knowledge of UNIX", three years of domain-specific education, and a network of people who trust you to--no, who depend on you to be able to get things done with that knowledge 2. A piece of paper just like everyone else in the department. And while the former might be more difficult to make use of, I think it could be much more valuable in the long run.
- robotresearcher 9y ago
  No, he left without a degree.
- blacksmythe 9y ago
  A good point, but the text suggests there are ways to get this knowledge. >> except six hundred dollars in his bank account
  - blacksmythe 9y ago
    >> are ways to get this knowledge. Edit: are ways 'better' to get this knowledge.
- newen 9y ago
  More like two options: 1. "A staggeringly comprehensive knowledge of UNIX", three years of domain-specific education, and a network of people who trust you to--no, who depend on you to be able to get things done with that knowledge 2. A piece of paper just like everyone else in the department, three years of domain-specific education, and a network of people who trust you to--no, who depend on you to be able to get things done with that knowledge (and probably a girlfriend)

bluedino 9y ago

>> Professors usually have this legacy code on hand (often code they wrote themselves decades ago) and pass this code on to their students So cut-n-paste code. The students are running code that they don't really know what it does, it might not even be correct...it's like StackOverflow in academia.

robotresearcher 9y ago
Did you write your own libc and libm? Compiler? We are ALL using code we didn't write.
- spc476 9y ago
  Daniel J. Bernstein did that for all of his projects (qmail, daemontools, etc) and I don't see him getting a ton of flack over doing that.
  - dagw 9y ago
    He certainly used to back when qmail vs postfix as the better sendmail replacement was a real debate 'we' where regularly having. If he's not getting any flack today it's most likely because he's fallen more or less into irrelevance when it comes to practical day to day operations.

ptero 9y ago

Yes, C++ does not buy you that much. Sure, it is a more modern language, but when used by scientists (not software engineers) the advantages are hardly earth shattering. Much of complexity is hidden (as it should be) into libraries. IMO, Python stands a better chance of breaking the Fortran's lock on physics related computing. Give it a few more years and enough numpy-based libraries might make Python a real competitor. My 2c

dsacco 9y ago
I have to be honest with you, as someone who writes in both C++ and Python, I really do not see Python being more of a candidate than C++ for displacing Fortran. Can you clarify why you think Python might be able to do it? For scientific computation with high performance requirements, Python is not competitive with Fortan or C++. For work that continues to happen in Fortran due to "academic inertia", my impression (and vague experience) is that researchers find the convenience of what they're accustomed to (Fortran) to be greater than the convenience of things like rapid prototyping offered by the various Python scientific computing and data analysis libraries. There is a mental overhead is switching, and I think most academics are sort of okay writing code in whatever is familiar and battle-tested if it means they can focus more on the research at hand. In other words, I'm not saying you're wrong, but I'm not following your reasoning.
- vacri 9y ago
  In a previous discussion of this kind (I'm not in this area myself), a scientist had said that the speed of the languages is less important than iterating the algorithms, and it was a lot easier for non-developer scientists to work with python than with C++.
- cknight 9y ago
  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.

felipemnoa 9y ago

>>I later learnt one of our "rival groups" attempted the same thing and it took three phd students working full time for a year to rewrite their code from fortran to C++. I wonder if there are any transcoders for Fortran to C++? I wonder if there is even a market for something like that? I've written alpha versions of transcoders for C to Java and Java to Objective-C and I think I could do the same for Fortran to another language but why? Writing a transcoder first is the right way to do it and it should take you a couple of months to do it, especially if you already have some experience with this kind of stuff. Definitely less than a year for a single person. I would not try to translate the code by hand. It would be a never ending project full of bugs. Edit: Apparently there are plenty of Fortran to C++ transcoders. Here is just one I found during my google search: http://cci.lbl.gov/fable/ http://cci.lbl.gov/fable/ No idea how good they work.

guitarbill 9y ago

Trusting legacy code with few users is a dangerous proposition. My roommate was given some "state-of-the-art" code and told to run simulations with it. The only graphical output was postscript (for some reason), so every frame was 150 MiB and took minutes to dump - so usually, this was only done at the end to show the result. I managed to hack in a step which just dumped the memory of resulting frame to a file, and then we wrote a Python script to read that and produces a PNG. We combine the PNGs into an animation and show someone else in the department because the supervisor wasn't in that day. "Cool! But, hrmm, those boundary conditions look wrong." Sadly, this was 2/3s into his Masters. Like much now in Physics, the original code was simply incorrect. This happens all the time, and papers get retracted because of it - well, that's the best case if somebody notices. At the end of the day, programming languages come with eco-systems, and must be chosen solely as a tool. The problem is not with Fortran, but that often Fortran == outdated development practices and in Physics horrible code hacked on by 10+ people without prior programming experience.

cryptonector 9y ago
It's going to have few users anyways, since it's so specialized. And that's also why it will be legacy.
EvgeniyZh 9y ago
Another problem is that most people who wrote this code aren't programmers - they don't write clean code, no tests, etc. They don't really know those are important. Sometimes the code that is used and updated for years looks like a dirty prototype. I don't know what can be done about it except hiring programmers to write code, which wouldn't be either easy or cheap
- guitarbill 9y ago
  Well, I guess one moral of the story is that doing image manipulation is easier in Python than Fortran, so it's again using the right tool for the job. And I think the push for Physicists to use Python if possible is good, as the learning curve is less steep. And once you have that tool at your disposal, you might use it more often (instead of Excel). I can see many projects being improved by providing a Python pre-processor that writes out e.g. a binary config file, the hard-code Fortran/C simulation code reads that, and spits out the simulation results, and then having a Python post-processor that does the pretty stuff at the end. Academically, it seems that pairing CS undergrads with Physics undergrads to do e.g. a molecular dynamics (MD) course would be cool. The Physics behind MD isn't too hard, and given the right parameters the programming part would be manageable. Then again, CS undergrads aren't necessarily great programmers either... Clean code and tests are overrated. Version control and a big eco-system is underrated. It's like maths, physicists don't understand maths, they just use it like a carpenter uses a nail without understanding metallurgy, or a programmer uses a CPU without understanding solid-state physics. And that's okay.

jordanpg 9y ago

It's not just that the code is already written and debugged; in many cases results have been published using analysis done with this legacy software. Using the same code ensures a certain amount of consistency between experiments from the same lab. From this point of view, rewriting code is an extremely high-risk proposition. As we know, the likelihood of discovering bugs during this process is quite high.

bluetwo 9y ago

Why isn't Julia a good choice?

hilbert42 9y ago

"...and it took three phd students working full time for a year to rewrite their code from fortran to C++" There's a salient lesson here. Clearly, this was a stupid decision for two reasons: (1) there are many thousands of scientific routines that have had 40-60 years of fine honing and careful debugging and they just work! (For instance, we send voyagers—Voyager, Cassini, etc.—to the end of the solar system and they invariably get there; the Fortran routines that get them there do exactly what they're supposed to do (unlike much of today's poorly written C code)! (2) Rewriting that already-reliable fully-debugged Fortran code into any other language will almost certainly make it far less reliable, thus it's a no-brainer to stick with the original .F source. Yes, Fortran is simpler than C [consider it BASIC on steriods] and years ago it had long since evolved well past John Backus's 1954 incarnation of the language into solid workhorse that both physicists and engineers use regularly. Just because something is old and out of fashion doesn't mean that it's broken or doesn't work well. (Longevity ensures that there's been sufficient time for many hands to make it reliable.) (Oh, BTW, I'm reminded that decades ago when I was just beginning to learn Fortran using punch cards on an IBM360 mainframe with the WATFOR FORTRAN-IV compiler, that I made four errors in only six lines of code. After dutifully printing ERROR against each offending line, the compiler finished with the message: "YOU NEED TO SEEK ANOTHER CAREER " or words to that effect [yes, it was in uppercase]. Eventually, I got considerably better.)