Question

I often write codes in MATLAB/Python to test whether my algorithm is feasible (& actually works). I then need to convert the entire code into C and sometimes, in FORTRAN90.

What would be a good way to manually convert a medium sized code from one language to another?

I have tried :

• Converting the entire code from one into another and then testing it.
  (Sometimes, there are errors and bugs which just won’t go away and the finding the source of the error becomes a problem)

• Go line by line and check for consistency of outputs every few lines.
  (Too time consuming)

• Use converters like f2c.
  (In my experience, they are extremely horrible. I link to a lot of libraries which have different function calls for C and Fortran)

Also,:

• I am fairly conversant with the programming languages I deal with so I don’t need manuals or reference guides for my work (i.e. I know the syntax).

• I am not asking this question specifically about MATLAB and C but rather as a translation paradigm.

• Regarding the size, the codes are less than 100 lines long.

• I dont want to call the code of one language to another. Please don’t suggest that.

Answer 1

Different languages call for different paradigms. You definitely don’t write and design code the same way in eg. Matlab, Python, C# or C++. Even object hierarchies will change a lot depending on the language.

That said, if your code consists in a few interconnected procedures, then you may go away with a direct line by line translation (every language allow you to write two or three interconnected functions while remaining idiomatic). But this is the case only for the simplest programs.

Prototyping in a high level language and then implementing the same idea in a robust and clean way in a “production” language is a very good practice, but involves two very different things :

1. Prototype in whatever language you want. Test, experiment, and convince yourself that the idea works. Pay attention to the big picture, don’t focus on performance but on the high level ideas. Pay also attention to difficulties that you encounter when implementing, as you’ll face them again in step 2.
2. Implement from scratch the idea in the production environment in language X. It will be quicker than if you did not do the prototyping stage, since most of the difficulties have been met in stage 1. Use idiomatic X, and focus on correctness. Pay attention to corner cases, general robustness, and once it works correctly, performance. You’ll notice that roughly half of your code is made of new things which did not appear in 1. (eg. error checking, corner case handling, input/output, unit testing, etc).

You can see that line by line translation is obviously not a good idea, since you don’t translate into the same program.

Also, when not prototyping, I find myself throwing away the first version and making another one that I like better, ie. I find myself prototyping ! Implementing the same thing twice is not a loss of time, it is normal development flow.