In looking at your responses in several of the comments I don't know if you realize that what you are experiencing is quite common, particularly when working in specialty fields where it takes domain experts (let's call them the scientist) to figure out how to incorporate and tailor algorithms for problems at hand.
Rather than complain about the scientist and expected them to change, just realize that you shouldn't expect the scientist to care much about "code quality". It is frequently hard to get other software developers to care about "code quality" let alone someone whose main interests lie in the domain and not the programming.
Where you go from here depends largely on the degree of confidence the "scientist" has in your ability to understand their work. If they have confidence that you can understand their code and won't muck it up when you modify things then there usually isn't an issue. They'll rely on your expertise.
However, if the scientist does not want you changing their code then it is highly likely that you haven't "earned" their confidence yet. If that is the case then rather than focusing on fixing the scientist, you should focus on "fixing" yourself. What I mean by that is to take steps towards gaining their confidence. Probably the easiest way to do this is as follows:
As part of your testing process:
- Start turning the algorithms into something easier to understand (e.g. diagrams, PDL, math notation)
- Learn to understand the algorithms.
- Be sure to identify the edge cases.
- Ask the scientist if your simplified "alternate" representation is correct
- AND MOST IMPORTANTLY identify problems that you found; AND without sounding "accusatory" say something like "I was looking at the algorithm and noticed XYZ is it supposed to do this or is it supposed to do that?". Nothing will gain their confidence better than this bullet.
Once you start finding bugs AND have demonstrated an interest in their area of interest then the odds become much higher that at the very least they'll let you start modifying the code to make it more "professional". Frequently, they won't even feel the need to code up a prototype any longer. They'll just write something up in one of those "alternate" notations that you've taught them (without them even realizing it) and they'll have confidence that you'll know what they mean.
By all means, my first attempt would be to offer some suggestions on how the scientist could best help "communicate" better in order to help you; but it sounds like you've tried that. So the only step that you have control over is what you do. Earn their confidence and almost always the domain expert will be relieved to pass coding off to someone else and not have to worry about all the little details that go into writing code. They'd much rather be focusing on improving algorithms.
Sometimes, all you can do is offer a suggestion and leave it be after that. You won't impress your boss or a senior if you keep harping on something that they've already rejected or decided they don't want to do, even if you are 100% correct. In fact, this will damage a relationship, whether you are the suggestor or suggestee. Just focus on what YOU can do to make your job easier.