[IPOL discuss] Python as a platform for reproducible research (... not!)

[Miguel Colom]

Quoting Pascal Monasse <monasse at imagine.enpc.fr>:
> Hi Miguel,
Hi Pascal,

>
> I do not quite agree with your statements :
> - C/C++ are languages that have passed international standards. That  
> is why if
> your code respects  such standard, the compilers being compliant, you should
> never have to change a single line of code.

The problem is that programs depend on components (libraries) that  
might change their interfaces. The libraries may evolve faster than  
the program than uses them, making the compilation fail.

 From a realistic point of view, adapting the sources of the program  
to the components it relies on and fixing bugs makes maintenance  
mandatory.

> - Concerning the libraries, it is precisely the reason why IPOL has a very
> conservative set of allowed external libraries. These are libraries whose API
> is very stable.

Yes, but a major change in their APIs might happen at any time,  
forcing the need of maintenance (modification) of the programs.

> - The changes we had to make with IPOL codes and newer versions of compilers
> where all related to the build procedure, not to the source code itself
> (correct me if I am wrong). For example, there was an important  
> restriction in
> gcc 4.7 with respect to the order of link libraries (former versions  
> were more
> forgiving). Such a kind of change does not require understanding the code
> itself.

Yes, it's nothing to do with the understanding of the code, but it's  
anyway a modification of the source code (the Makefile).
It's an evidence that maintenance/modification of the codes is needed.  
In this case, a small modification.

> - By contrast, python is still a young language and a moving target  
> : consider
> the changes between python 2 and python 3 in the core language itself.
> - Yes, python comes with "batteries included" and may be easier for
> prototyping an algorithm. But many of its libraries are still changing with
> often no care about API stability.

I agree with this and it's one of the reasons I wouldn't recommed the  
use of Python at this moment.

Best,
Miguel