4 ms·

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.

by 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.

by dwc 9y ago

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.