<div dir="ltr"><div>"In IPOL we have already experimented this. With the new version of the<br>
compiler, some source codes won't compile. Therefore, the only<br>
solution if to maintain them. Even if the modifications are not<br>
performed by the authors, but by IPOL as updates and bug fixes."<br></div><br>If c++ code also needs to be maintained, then do you think c++ is easier to maintain than python code? Lets focus on the language and assume for the discussion that the c++ libraries allowed by IPOL exist and are stable in python.<br>
<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 20, 2013 at 12:16 PM, Miguel Colom <span dir="ltr"><<a href="mailto:colom@cmla.ens-cachan.fr" target="_blank">colom@cmla.ens-cachan.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
this is the classic problem of software libraries changing their<br>
interfaces along the time and breaking the code that depends upon it.<br>
It's not related only to Python, but to any software using libraries.<br>
<br>
Indeed, we have the same problem in IPOL with the C libraries. We<br>
decide that libraries are "stable" because the haven't changed the<br>
interfaces for a long time, but we can never be sure that this will<br>
remain true for the long term.<br>
<br>
After all, this troubles have to do with software lifetime. All<br>
software need to be maintained and this isn't optional, but mandatory.<br>
If the software is not longer maintained, it's finished it's lifetime.<br>
After that point, it might be still executed and be useful, but<br>
without any warranty that it won't break, be incompatible with the<br>
newer interfaces of the components it relies on, or contain bugs that<br>
will never be fixed.<br>
<br>
In IPOL we have already experimented this. With the new version of the<br>
compiler, some source codes won't compile. Therefore, the only<br>
solution if to maintain them. Even if the modifications are not<br>
performed by the authors, but by IPOL as updates and bug fixes.<br>
<br>
To summarize, my opinion is that Python is an excellent tool for<br>
reproducible research and it's got no more problems with libraries<br>
than any other system. And of course, as a language is way far more<br>
powerful than C/C++ and allows fast prototyting. Of course, the<br>
problem is that, as any VM-based language, it's really slow executing<br>
operations out of the C/C++ compiled code of the libraries.<br>
<br>
Best,<br>
Miguel<br>
<div class="im"><br>
Quoting Nicolas Limare <<a href="mailto:nicolas.limare@cmla.ens-cachan.fr">nicolas.limare@cmla.ens-cachan.fr</a>>:<br>
> Hi everyone,<br>
><br>
> Here is an excerpt from a blog post by Kohnrad hinsen abour how Python<br>
> is not a perfect solution for long-term software stability, even when<br>
> only using the numerical computation Python package. The full text is<br>
> at<br>
> <a href="http://khinsen.wordpress.com/2013/11/19/python-as-a-platform-for-reproducible-research/" target="_blank">http://khinsen.wordpress.com/2013/11/19/python-as-a-platform-for-reproducible-research/</a><br>
><br>
> 8<----------8<----------8<----------8<----------8<----------8<----------<br>
><br>
> Python as a platform for reproducible research<br>
><br>
> The other day I was looking at the release notes for the recently<br>
> published release 1.8 of NumPy, the library that is the basis for most<br>
> of the Scientific Python ecosystem. As usual, it contains a list of<br>
</div>> new features and improvements, but also sections such as ?dropped<br>
> support? (for Python 2.4 and 2.5) and ?future changes?, to be<br>
<div class="im">> understood as ?incompatible changes that you should start to prepare<br>
</div>> for?. [...]<br>
<div class="im">><br>
> From the point of view of reproducible research, all these changes are<br>
> bad news. They mean that libraries and scripts that work today will<br>
> fail to work with future NumPy releases, in ways that their users, who<br>
> are usually not the authors, cannot easily understand or fix. Actively<br>
> maintained libraries will of course be adapted to changes in NumPy,<br>
> but much, perhaps most, scientific software is not actively<br>
> maintained. A PhD student doing computational reasearch might well<br>
> publish his/her software along with the thesis, but then switch<br>
> subjects, or leave research altogether, and never look at the old code<br>
> again. There are also specialized libraries developed by small teams<br>
</div>> who don?t have the resources to do as much maintenance as they would<br>
<div class="im">> like. [...]<br>
><br>
> One popular attitude is to say: Just run old Python packages with old<br>
> versions of Python, NumPy, etc. This is an option as long as the<br>
> versions you need are recent enough that they can still be built and<br>
> installed on a modern computer system. And even then, the practical<br>
> difficulties of working with parallel installation of multiple<br>
> versions of several packages are considerable [...]<br>
><br>
> --<br>
> Nicolas LIMARE<br>
> <a href="http://nicolas.limare.net/" target="_blank">http://nicolas.limare.net/</a> pgp:0xFA423F4F<br>
><br>
<br>
<br>
</div>--<br>
IPOL - Image Processing On Line - <a href="http://ipol.im/" target="_blank">http://ipol.im/</a><br>
<br>
contact <a href="mailto:edit@ipol.im">edit@ipol.im</a> - <a href="http://www.ipol.im/meta/contact/" target="_blank">http://www.ipol.im/meta/contact/</a><br>
news+feeds twitter @IPOL_journal - <a href="http://www.ipol.im/meta/feeds/" target="_blank">http://www.ipol.im/meta/feeds/</a><br>
announces <a href="mailto:announce@list.ipol.im">announce@list.ipol.im</a> - <a href="http://tools.ipol.im/mm/announce/" target="_blank">http://tools.ipol.im/mm/announce/</a><br>
discussions <a href="mailto:discuss@list.ipol.im">discuss@list.ipol.im</a> - <a href="http://tools.ipol.im/mm/discuss/" target="_blank">http://tools.ipol.im/mm/discuss/</a><br>
</blockquote></div><br></div></div></div></div>