Yes, those are valid and important considerations. In this case it didn't need to be a shippable binary, it was just run internally. We had the infrastructure t

Yes, those are valid and important considerations. In this case it didn't need to be a shippable binary, it was just run internally. We had the infrastructure to seamlessly handle a mix of Python and C++, and the team members were familiar with both languages - other than the exceptions noted above. This was a set of geographic data importers for some messy data in a variety of formats from multiple countries. The data quality was so bad that north and south were sometimes reversed, or even worse, north and west would be reversed, among many other problems. This required a lot of ad hoc code to clean up the data. It was originally written in C++, with all the data importers linked into a monolithic binary with an eight-minute build time for a one-line change. (Or a half-hour for a full build.) So if you spotted one data error and wanted to clean it up, it was an eight-minute wait to try your code. When I changed it to use a Python front end that cleaned up the data and fed it to a simplified C++ back end for the compute intensive part, the C++ code hardly ever had to be rebuilt, and there was no build time at all for the Python part. So you could explore the data interactively and easily figure out how to clean it up. Technically, this was a huge win. Socially, not so much. OTOH, if you ever interview me and ask the "behavioral" questions: "Tell me about a time when a project went really well" and then "Tell me about a time when a project didn't go so well", I can use this episode for both questions!