Heard you like IronPython, so I got you IronPython inside IronPython.

Why did the doctor suggest the python to shift to ironpython?

--Because it couldn't C#

When they decided to deprecate the old app that went back to early DOS, they decided to use VB.NET because they'd used some VBA and were familiar with it. Except they had a vague idea that C# was faster and decided to write the OpenGL code in that. Also they had some C++ code and decided to write more of it, accessed by the main program via COM.

I come in and the decision is made to integrate some third-party libs via a C++/CLI layer. On one hand screw COM, but on the other we're now using two non-standard MS C++ extensions. Then we decide we need scripting, so throw in some IronPython.

I'm the build engineer for all this, by the way. No fancy package managers since almost all the third-party dependencies are C++; a few of them are open source with our own hacks layered on top of the regular code, a few are proprietary. When I first started here you couldn't build on a fresh SVN checkout (ugh) without repeatedly building the program, copying DLLs manually, building again, ad nauseum. I finally got sick of being called in to do this process and announced that I was fixing it, which took a solid week of staring at failed compiler output.

Every so often someone wants to update that damn COM library and has to sacrifice a goat to figure out how the hell you get it to accept a new method. Maybe one day I'll do a whole rant just based on COM.