COM was a disaster but it was forced down people's throats. Then MSFT introduced new technologies every half an hour and heralded them as the next thing. That was the time when I had enough of it.Why not?
Traditionally developers used VBA, C (XLL), C++ (ATL) and C# (native and Excel-DNA) to create worksheet and COM addins. Some options are easily than other. Excel has a COM history and .NET creates wrappers for them.
How interoperable will it all be, and how efficient? (AFAIK VBA is reasonably fast?(?))
C++/CLI is a C++ extension and allows access to the .NET libraries. It also speaks ISO C++11.
My gut feeling/first impressions is Python-Excel is not the most ideal interop. I could be very wrong.
COM was something else, indeed.COM was a disaster but it was forced down people's throats. Then MSFT introduced new technologies every half an hour and heralded them as the next thing. That was the time when I had enough of it.
VBA blows chunks too but that's a conversation for another day.
I on the opposite side of the spectrum regarding Python-Excel. I'm 100% sure is going to work because I have used it very often and it does wonders even though it's not a native solution. I think there is a more than 50% chance of sticking if it ever comes to life.
This is the package I have been using:COM was something else, indeed.
Do you have any nice links on what Python-Excel can do?
I'm note sure about 'instead' but who knows. Python developers will love it (fair enough) but does that means VBA/C/C++ programmers will need to learn VBA?This could be interesting. So we can use Python instead of VBA and open realms of opportunity.
Microsoft Considers Adding Python as an Official Scripting Language to Excel