It’s worth mentioning that Maya actually has a Python wrapper for the C++ API (well, two actually), and no less than two Python wrappers for its MEL API. Every other major DCC has been in the process of replacing their built-in languages with Python, or at least wrapping them in Python. The trend in the industry is towards Python. Hell, the trend in C++ is towards Python, too! Now Blender is the first and maybe the only DCC app that supports Python natively in a Pythonic way. Just try writing a Maya script with Python- its completely backwards syntax makes it a wrestling match with your own instincts.
I think the answer to the C/C++ question is to improve the Python API. The bpy_struct.as_pointer() method should be sufficient to pass the data to a compiled module that operates directly on the memory address within Blender. Perhaps more work needs to be done to make this process less painful, but Python isn’t too slow to query memory locations and pass int’s back and forth.
I’d like to see a minimum version of Blender or a more officially supported
bpy build for compiling C/C++ modules against to be used in a Python ctypes plugin/interface. I’d love to see it implemented in the Apache license like Cycles, to attract developers that wish to make money from the software. Although I’d also love to see it enforce software freedom via the GPL2, but it’s a hypothetical anyways… Perhaps this is easy to do already, in which case documentation is what is needed.
On the opposite, an API is generally stable for some years
But at what cost? Take a look at some of the “industry standard” softwares- what you’ll find is bloated, buggy, slow softwares that have to remain compatible with decades-old APIs. Take Maya as an example- its node-based architecture and extensive MEL API were groundbreaking in the late 90’s when Blender didn’t even have undo support yet. But MEL hasn’t aged well, and Maya is too deeply wedded to this extremely poorly designed language to refactor. Despite being an object-oriented C++ program, Maya’s entire interactive structure is based around a strictly imperative language with only five data types-- and barely any ability to handle exceptions or write structured programs. To be fair, this isn’t a C++ API, but I’d be willing to bet Maya has the same problem in its C++ API. Having to keep compatibility to an API is limiting for the future of a project. That’s why we see such slow development in the proprietary world- they didn’t plan for the future and now they can’t take big steps without losing their customers by breaking compatibility. It also underscores the folly of writing software in a proprietary language/API, but that’s off topic.
One of my favorite things about Blender is the bravery of its development cycle- we’re not afraid to change the architecture of the software in a major way if it leads to improvements. We’re not afraid to spend months or years designing things to be sure we won’t have to refactor again anytime soon. Unlike proprietary tools, we don’t have to worry about losing customers, meeting yearly feature release deadlines, or pleasing shareholders. Free software means that we’re free to focus on the future of Blender, rather than the short-term. There’s no risk of going out of business. Autodesk can’t buy us and shut us down, like they did with SoftImage.
Well… I’ve gone off topic myself now.