This could be one of those things that definitely grabs developers attention in a good way. I disagree it needs to be for all Office apps - if it was just Excel and Access that would be plenty.
I find it easy to express myself in the language and I think it is a good fit for the problem domain at least in terms of what Perl was traditionally good for, "glue" and data processing.
I honestly feel that Lua would be a better fit, since the Lua table maps pretty nicely to Excel cells... but I'm sure there's some reason that it would unsuitable?
I'm guessing the popularity of Python is why they're going with it. Quants and other power users are starting to drop Excel and moving on to Python, so they figure they might be able to keep some market share this way.
Otherwise I'd guess they'd try to push one of their .net languages, probably C#.
Yeah, who cares about some dumb list? The point is why can't we put any - and all/other - of these languages in the Excel runloop by now? You say Python, I say Lua, someone else says Go.. seems to me that all of the above oughta have a go at it. Excel is freakin' everywhere.
They have had .net support for many many many years although not as a scripting language, but you have been able to write your "macros" in .net for a long time, deploy the assembly to a web server and have excel, word, etc download the code from there there. Its a little harder to deploy that an inline macro but gives you a central location to update the code instead of trying to tracking down and update all the copies of your word/excel documents.
In case people aren't aware - you can use any language with COM bindings to script Excel/Word/PowerPoint/Adobe/etc from outside the application.
Python has pywin32. Usually I have a python prompt and Excel open side by side and highlight cells I'd like to modify in Excel and then switch to Python to run the appropriate functions.
The COM API can be used interactively (attach to an existing instance or launch the GUI) or automatically (launch an Excel instance but turn off visibility).
>> from outside the application.
> And that's the thing holding back adoption, I bet.
That, plus the painfully verbose and unintuitive COM API. If they add a Python layer to Excel I would really like to see COM replaced with a simpler (pythonic?) interface.
20 comments
[ 0.28 ms ] story [ 44.2 ms ] threadhttps://news.ycombinator.com/item?id=15927132
https://news.ycombinator.com/item?id=15996753
https://news.ycombinator.com/item?id=15938873
https://github.com/Azure/azure-webjobs-sdk-script/wiki/Azure...
But you _can_ use Python right now in the stable runtime--it's just not as nice or full-featured, because of the way the 1.x runtime works.
(I work for Microsoft on an unrelated team, and I too am waiting for Python to be back, hoping for 3.6 and asyncio)
Otherwise I'd guess they'd try to push one of their .net languages, probably C#.
https://stackify.com/popular-programming-languages-2018/
Python has pywin32. Usually I have a python prompt and Excel open side by side and highlight cells I'd like to modify in Excel and then switch to Python to run the appropriate functions.
The COM API can be used interactively (attach to an existing instance or launch the GUI) or automatically (launch an Excel instance but turn off visibility).
And that's the thing holding back adoption, I bet.
That, plus the painfully verbose and unintuitive COM API. If they add a Python layer to Excel I would really like to see COM replaced with a simpler (pythonic?) interface.