Much as i would love for the power of Python in Excel it is important that whatever is done is consistent across the office experience. Some of us old enough to remember the multiple versions of VB-whatever across Excel, Word, Access and that in itself was a blow to productivity.
Yes they should choose Python, and in the process decide if it will be Python with a .Net library (standard and core as seperate libs please!) or IronPython. This in itself is an important first choice.
Then it has to be done in a mechanism that enables the exact same libs and user written python code to work in the same way across all the Office products.
Other languages have been suggested, all good choices with their own merits. Lua is a good chocie for compactness and speed. C# is lingua franca of commercial developers so would suit ISVs but i think too heavy for end user scripting. Nim or even freepascal maybe? Lastly whatabout just using VB.net consistently? VB is a great language for newbs and casual/adhoc programmers .... but it gets ignored because of problems with consistency of implementation by MS.
Last point i would like to make is IMHO the choice needs to be based on:
- ability to transpile to javascript so that Excel365 can be scripted from webapps
- install-free deployment; should be built into Excel in a way it can be used without any user install for dev or runtime
- standard vanilla language, not a variant
Disclaimer: A huge fan and long time user of python here. I also spent largest part of working life in ISV world rather than end user land.
The reason Python is a popular choice is because it's a very polyvalent language (not specialized for any task but quite good at a lot of them) BUT the data analysis tookit in the Python ecosystem rocks (numpy, pandas, etc). Lua doesn't have a good data anaylisis story. C# is not made for scripting. VBA is not great outside of Office.
Now given that cPython 3.6 has f-string, and that you probably will use string formatting a lot if you script a MS product, I would implement this version specifically. It's the most recent stable version of the standard implementation anyway.
Actually no, I would not implement anything. I would embed the cPython 3.6 interpreter and stdlib, and just provide a binding to it. This limit the problem of bad / inconsistent implementations that crippled MS products in the past.
Then I would say "we guaranty to provide a 3.6 compatible cPython + stdlib for the next x years" so that people can be confident to write Python stuff. Otherwise, a bad implementation would be worst than no implementation at all.
The office 365 support could be implemented using the jupyter kernel protocols rather than transpiling to javascript. That would give them a consistent behavior across desktop and web and even open the door to support more languages in the future if they really wanted to.
> VB is a great language for newbs and casual/adhoc programmers
Is it, though? For example, VB puts four different ways of passing arguments right in your face: values by reference, values by value, object references by reference and objects references by value. Python only has the last one and doesn't make you think about it.
And without "Option Explicit" VB does something very unhelpful (also seen in PHP): misspelled variables are created on read and silently converted to the required type, giving you nonsense results. (With "Option Explicit" enabled it gets verbose and tedious instead.)
C# Scripting is a thing now. I've used it on projects. C# makes an excellent scripting language, and in the MSFT space there's probably more of an established practice in that language. I can't imagine why they would use any other language - except perhaps F# or PowerShell.
Yes they should choose Python, and in the process decide if it will be Python with a .Net library (standard and core as seperate libs please!) or IronPython. This in itself is an important first choice.
Then it has to be done in a mechanism that enables the exact same libs and user written python code to work in the same way across all the Office products.
Other languages have been suggested, all good choices with their own merits. Lua is a good chocie for compactness and speed. C# is lingua franca of commercial developers so would suit ISVs but i think too heavy for end user scripting. Nim or even freepascal maybe? Lastly whatabout just using VB.net consistently? VB is a great language for newbs and casual/adhoc programmers .... but it gets ignored because of problems with consistency of implementation by MS.
Last point i would like to make is IMHO the choice needs to be based on: - ability to transpile to javascript so that Excel365 can be scripted from webapps - install-free deployment; should be built into Excel in a way it can be used without any user install for dev or runtime - standard vanilla language, not a variant
Disclaimer: A huge fan and long time user of python here. I also spent largest part of working life in ISV world rather than end user land.