Jonas Hegemann

Hi Golodh, thanks for your detailed comment. Let me briefly respond to some of the points you made.

(2) We already had an existing implementation in Wolfram Mathematica, but it was marginally automated and much too slow to push large data sets through it. Especially the numerical methods slowed down the process and optimization was really necessary, since the used equations are hard to solve and unstable. This becomes even worse with decreasing quality of the input sequences. The decision to use C++ was actually not mine, it was part of the task, but we got a speed up from a few weeks in Wolfram Mathematica to a few hours in C++, so I think the decision was not too bad. I definitely agree with you in using existing libraries as far as possible, but I made the experience that "blind" usage of libraries might also lead to issues. Sometimes you have to change, tune, modify, or adapt a library function. Sometimes this can be done by writing a wrapper function, but in some cases, its faster to write the whole function yourself. I see the benefits of Matlab and Python concerning rapid prototyping, but being a trained C++ programmer with the possibility to draw on a large existing pool of code makes this advantage in some way less important. Of course you are better off in programming Matlab if you don't now how to manage memory in C++ efficiently, but you should agree that in principle Matlab or any other math software can not be faster than a customized C++ implementation. I know a PhD project, which consists of writing highly optimized C++ code intended to beat Comsol Multiphysics in performance. It's really worth the effort for runtime critical applications.

(3) You are probably right if you call it a waste of time regarding there are no benefits for my current work. Up to now, it is just a hobby and I'm not spending too much time on it. Yes, I'm doing a PhD in physics, but I'm not inevitably connected to academic research. Actually I'm planning to get a job in software development or a related field.

(4) Instead of a gui, I have a config file setting all relevant parameters, but only few of them have to be adapted after changing the input files. So usually its fairly simple to run the program, and results are wrapped into a large html report showing all relevant informations. So this is not too far from a gui from my point of view. We already share the code with some chemists. They normally use Windows but have no issues while using the CLI in a virtual machine yet.

Thanks for your comment! Actually many of my colleagues use python for this purpose, and I do so as well from time to time. Concerning readability your definitely right. My bash script collection is kind of a historical heritage, since I began with bash and henceforth proceeded with it. For the future, I'll definitely consider python as an alternative to bash.