
Excel team considering Python as scripting language: asking for feedback - smortaz
Folks, Microsoft is officially considering providing Python support in Excel (finally).  If you are interested in this, please visit their uservoice page and let them know what you think. Thank you!<p>https:&#x2F;&#x2F;excel.uservoice.com&#x2F;forums&#x2F;304921-excel-for-windows-desktop-application&#x2F;suggestions&#x2F;10549005-python-as-an-excel-scripting-language
======
zoom6628
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.

~~~
ptx
> 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.)

~~~
Scarblac
I'd say what Python does is passing object references by value.

~~~
ptx
Right. I listed them in the wrong order and wasn't quick enough with my edit.
:)

------
_e
Dear Excel team,

Take a look at the top three results for "excel python" on bing.com for some
great ideas on how to incorporate python into excel.

\---

1.) [https://www.python-excel.org](https://www.python-excel.org)

2.) [https://www.pyxll.com/](https://www.pyxll.com/)

3.) [https://www.xlwings.org/](https://www.xlwings.org/)

~~~
askvictor
There is also pyspread as a full spreadsheet implementation using and for
Python: [https://manns.github.io/pyspread/](https://manns.github.io/pyspread/)

~~~
vanderZwan
> _Pyspread expects Python expressions in its grid cells, which makes a
> spreadsheet specific language obsolete. Each cell returns a Python object
> that can be accessed from other cells. These objects can represent anything
> including lists or matrices._

Huh, on the one hand sounds like a such a simple way to deal with it that I
can have trouble imagining a more elegant approach.

On the other hand, does it still respect the ways that Excel updates cells?
Sicne that kind of requires immutability I think.

------
smortaz
Clickable Link:

[https://excel.uservoice.com/forums/304921-excel-for-
windows-...](https://excel.uservoice.com/forums/304921-excel-for-windows-
desktop-application/suggestions/10549005-python-as-an-excel-scripting-
language)

[disclaimer+bias: on Python team @ msft & would love to see this happen!]

~~~
odonnellryan
So what's the strategy here re: security? I assume it'd be a fairly stripped-
down version of Python ... or will you just design the UI to say "you probably
shouldn't execute files from people you don't know" etc?

~~~
esmi
From a security point of view how is embedding python different from embedding
Visual Basic? This is not my area of expertise so I’m genuinely curious.

~~~
Groxx
Potentially different. .NET allows signed binaries / libs / a fully signed
execution context, Python has nothing equivalent AFAIK.

~~~
auxym
Excel VBA is not .Net though. It's plain old VB code in text files inside the
.xlsx, and you just have to trust it (or not).

~~~
Groxx
Aaah. Then probably about the same, yea :) Maybe less of a nightmare around
dependencies than the pip world...?

------
jimnotgym
Imagine all of those simple tasks that you could do in seconds with a python
script. Export to csv in UTF-8 with double quoted fields. Loop through cells

    
    
      for row in rows:
         do some cool stuff
    

Pull data from a REST API using requests rather than some VBA hack. I'm
getting over excited already. Edit data for your ERP and then post it back to
the API and update the db... This is exactly what finance/data people want.
Write custom functions (with numpy maths!)! No more nested If's. This will
keep Excel as the premium spreadsheet app. I love it

~~~
discreditable
I already find myself reaching for Google Sheets quite frequently just to do
this. I'd love to be able to use Python instead of JavaScript.

------
chrisaycock
Does Excel have a "plugin framework" for new languages the way Jupyter does?
Ideally _any_ language (Python/Julia/R/whatever) can be added by a third party
without Microsoft's direct involvement.

The plugin authors would only need to map a language or library's DataFrame
mechanics to Excel's table layout. (Microsoft could even use Apache Arrow to
represent the data.)

I imagine there would be lots of possibilities by providing "hooks" for
language designers to connect to.

~~~
cm2187
You can pretty much already do what you want with VSTO or XLLs. However having
a standard scripting language installed on everyone's machine is a all
different thing. It means you can add some scripted logic in your spreadsheet,
give it to someone else, and know it will run without having to install or
maintain anything.

~~~
blendo
This is incredibly important. When I worked at BigFinCorp, we always used
vanilla Excel (VBA and ODBC to RDBMSs). So our sheets would always "just
work".

Python would be great in this role, but to avoid separate configuration, you'd
need to ship the runtime with the spreadsheet, right?

Or would this new Excel capability be built on .NET? In that case, C# (for the
enterprise folks) and F# (for the bleeding edgers) would be fun, too.

Bottom line, the Developer mode of Excel should support more than VBA.

------
craigyk
I'd vote for Lua: faster and less heavy than Python... Plus my biggest concern
for Python would be how well the team can sandbox it. I know in this regard
Lua also has advantages. Disclaimer: I am _way_ more proficient in Python than
Lua, I just think Lua is a better choice.

~~~
jimnotgym
Does Lua have anything like Numpy or Scikit-learn?

~~~
petre
Yes, it has Torch.

~~~
carlmr
Pandas?

~~~
petre
[https://github.com/AlexMili/torch-
dataframe](https://github.com/AlexMili/torch-dataframe)

------
cm2187
Might be worth reminding everyone of a dead Microsoft project called VSTA,
which was basically a live .net IDE embedded in Office. Effectively a mini
visual studio inside any office application, where you can write any .net
language. This would have allowed people to script in VB.net, C# or F#.
Microsoft killed the project before it shipped (but licensed VSTA as a
scripting tool for third party apps for a while). It's a pitty. I think this
would have been a better solution than python.

~~~
smortaz
Good point that the tooling would've been awesome. However, I don't think .net
would have spawned the rich ecosystem of Python pkgs that we enjoy today. And
/that/ is a huge part of the whole Python value prop. From astronomy to
finance to bioinformatics to ML & everything in between, there's a pkg for
that. We even did sponsored a port of numpy+scipy to .Net (via Anaconda). At
the end of the day, there were just too many corner cases & too many pkgs to
port for it to make sense.

------
cm2187
What is interesting is also the implications of them now considering python.

First if it is python, it is not javascript, which seemed to have been their
previous favorite candidate until now (not sure if it really picked up).

Second, the writing on the wall for VB as a language starts to look like a
time square billboard. They basically put VB.net in maintenance /
compatibility mode like webforms and winforms. I think it is clear that a new
scripting language would be meant to ultimately replace VBA (which has been on
maintenance / compatibility mode for 20 years!).

~~~
contextfree
excel already supports javascript for custom functions, add-ins, etc

~~~
cm2187
I wasn't aware one could do UDF with javascript. Thought it was for addins
only.

------
olympus
VBA's one saving grace is that it's been available on every company computer
I've ever used. Alt+F11 and I have an IDE. It's probably responsible for
getting a few people involved in programming.

But it had some serious limitations and some unexpected behavior compared to
"real" programming languages. I hope that adding Python to Excel can be my new
"guaranteed to be there" language on coworker's computers and get even more
people involved in programming.

------
mschwaig
So when I google how to do something in Python I will have to comb through
solutions specific to v2, v3 and now also Excel? ;)

Aside from that it sounds like a cool idea.

------
tenryuu
I've probably mentioned this before on another news article. Not like it
really matters. Python is nice as a beginner scripting language since it's (to
my own judgement) the most easily readable language to its function set.

When working with software like office, you are going to have a lot of users
that don't exactly spend their days programming, or studying syntax. Excel is
a little different in their own regard. The functions system has a lot of
depth to it, and makes sense to a cell system, but for some it can be a but
overwhelming in terms of how its written, since everything has to be written
exactly as a function. I guess you also have generic office macros, haven't
used them since high school.

In saying that, could this somehow be a reason why the office team have
decided on a python interpreter, instead of say JavaScript or Microsoft's work
on Typescript. Because python is easy to write, fast to learn, therefore users
or even really employees in large data management positions don't have to
worry about their time input?

------
cessor
I use PANDAS in Jupyter Notebooks a lot. Sometimes, exploring large data
frames can get tedious and I find myself loading up excel to explore and
browse around, usually when deciding how to normalize or clean things up.
Using Excel as a PANDAS Gui this way would be really great, but also using
Python to script excel would be useful. And I guess I would love to call bokeh
/ seaborn after making an excel cell selection.

I am looking forward to what a Python & Excel marriage will look like.

------
rhelmer
This post suddenly reminded me of Resolver Systems, who made a Python/.Net
spreadsheet back in the '00s:

[http://www.prweb.com/releases/spreadsheet/competition/prweb1...](http://www.prweb.com/releases/spreadsheet/competition/prweb1826304.htm)

I thought it was a good idea at the time, especially after having read "A
Small Matter of Programming" which makes the case that spreadsheets are one of
the very few successful end-user programming systems (the other being CAD):

[https://mitpress.mit.edu/books/small-matter-
programming](https://mitpress.mit.edu/books/small-matter-programming)

------
harry8
Port it as a plug in to old versions of excel as first class citizens on
release.

There's been far too much, "here's a feature people will use so you're going
to have to pay us yet again to open spreadsheets" in the history of excel.
It's shit. It's awful. Don't do it. Using rich customers desires to extract
money from those who neither need nor want the new feature is a crook's game.
If microsoft aren't evil don't do it.

------
ropeladder
This would be great but it's a bit surprising given the move to add support
for R in SQL server, Power BI, etc...

~~~
scottmcdot
Yes I agree.

------
Glench
I made a prototype programming environment that is more like a spreadsheet
interface into Python called Flowsheets that y'all might be interested in:
[https://www.youtube.com/watch?v=y1Ca5czOY7Q](https://www.youtube.com/watch?v=y1Ca5czOY7Q)

Flowsheets has become my preferred data manipulation environment.

------
zwieback
My biggest issue hasn't been VBA but the poor documentation of the Excel
(Office) object model and the weird way of accessing cells and cell ranges.

Would this get better in Python? I hope so.

------
salmo
OK, I'll be honest. I usually avoid excel, except for excel to csv conversion.
Then I write a python3 script starting with `import csv`.

This would make the product actually useful for me. VB is terrible. I don't
even want to think about it. JS is a language I put up with when I have to
work in a browser. Python is a joy to use especially in situations like this.

I can't tell you how many little apps I've had to write against CSV dumps from
some stupid proprietary app without an API for Infosec or Capacity Planning or
whatever that is essentially a report. I would do this instead in a heartbeat
to avoid maintaining a service that gets used weekly/monthly/whatever.

------
dragonwriter
I'm actually more concerned with good tools for working with code than the
language, but Python would be an improvement over VBA, and conceptually allow
them to use Python tooling they've developed for other uses in Office.

------
logicallee
here's my feedback: embed sqlite in it and you're done. Nobody needs any more
servers, you can literally replace a hundred thousand dollar "big data" center
and team of PhD data scientists with a business school dropout. And you will
get prettier, more actionable results.

~~~
willhslade
Can everyone read this and vote this up in the survey? This is the real LPT.

------
datpuz
This would be awesome! I've built some tools using VBA and found it to be the
most painfully unpleasant programming language I've ever used. Python is by
contrast the most pleasant!

------
sixothree
No love for C#? Imagine the power of LINQ in Excel.

~~~
icos
For C# and LINQ in Excel there is my ESharper add-in
[https://vlasovstudio.com/esharper/](https://vlasovstudio.com/esharper/)

------
floki999
Unless the Excel team somehow integrates Python with the existing GUI design
tool already found in Excel, it wouldn’t bring anything new to the table.
There are already existing solutions such as DataNitro, which allow to code
Python macros and functions and make use of Numpy, Pandas and Matplotlib.
Microsoft is so far behind the curve it’s not funny. Their integration of
either Python or IronPython in Visual Studio has been a mess for years.

See Http://www.datanitro.com

------
euske
It would be great for a scripting language, but for field functions I would
have preferred something that's more akin to FRP-oriented language (e.g.
Scheme).

~~~
vanderZwan
Excel itself is functional and reactive already, wouldn't adding an FRP
language on top of that be a bit superfluous? Check out Felienne Hermans' work
if you haven't already:

[https://www.youtube.com/watch?v=0yKf8TrLUOw](https://www.youtube.com/watch?v=0yKf8TrLUOw)

[http://www.felienne.com/publications](http://www.felienne.com/publications)

~~~
euske
Excel is reactive already, but its field functions can't have variable
bindings or procedural operation as far as I know (unless, of course, you
write your own separate VBA function). I sometimes want to write in a complex
one-liner and thought lisp/scheme would be a great choice.

~~~
vanderZwan
Ah, fair enough. I mean, I'm not debating the power of Lisp, and it would be
great first languages for someone not trained in programming. OTOH, there is
of course the trade-off to make it as useful for as broad a selection of users
as possible; Python has a lot more mind-share, and the SciPy ecosystem would
be a great complement.

If Excel adds some practical convenience functions to the global namespace,
would it be that hard to make Python fit the reactive paradigm in this
context?

About those variables: maybe the Bumblebee tool she and her team made[0][1][2]
would work for you

    
    
        Our language is an extension of regular Excel formulas, 
    	 so you can write a transformation like
        
        A1+A2 <-> SUM(A1:A2)
        
        which allows BumbleBee to transform exactly the formula 
    	 A1+A2 to SUM(A1:A2) or vice versa. 
    	 
    	 In addition to using exact cell references, you may also
    	 use variables instead of cell references:
        
        {i,j} + {i,j+1} <-> SUM({i,j}:{i,j+1})
    

I hope it can be useful to you! :)

In the video I linked before she mentions it at 31m33s. Oh and here[3] are the
slides for that video, in case you prefer those.

(Disclaimer: I don't use Excel myself; I'm just a programmer who wants to get
more people into programming, so I was both happy and impressed when I saw her
presentation on how people not trained as programmers use it to do really
complex tasks)

[0] [http://www.felienne.com/BumbleBee](http://www.felienne.com/BumbleBee)

[1]
[http://www.felienne.com/archives/2964](http://www.felienne.com/archives/2964)

[2]
[https://figshare.com/articles/BumbleBee_A_Transformation_Env...](https://figshare.com/articles/BumbleBee_A_Transformation_Environment_for_Spreadsheet_Formulas/813347)
Paper on BumbleBee

[3] [http://gotocon.com/dl/goto-
amsterdam-2016/slides/FelienneHer...](http://gotocon.com/dl/goto-
amsterdam-2016/slides/FelienneHermans_PureFunctionalProgrammingInExcel.pdf)

------
75dvtwin
1) performance, including multi-sheet setups, should be better than the
current Macros.

For maintainability reasons, in one personal experience, I moved in-cell
macros to VBA, and saw significant degradation in performance (my excel was
calculating financial instrument attributes, based on raw input data (store in
separate workbook with the same sheet)).

So my ask would be that Python-based scripting would not just be the same as
VBA in speed, but faster than in-cell macros.

2) There needs to be easy-to-use capability, to be able create XLS files with
the new language macros, from within other programs. So that the new Python
modules can be written out together with data from within other programming
languages (and MS-supported libraries to replace or augment something like
openpyxl, and similar libs for other langauages will be much welcomed)

3) I think Python as a choice for Excel is a good idea. It should be a
language with 'duck typing', and that has support for Data Frames, Reactive
programming. And in that light, I would like to see that Python's Pandas are
first class citizens in being able to address Excel cells, participate in
graphing, pivoting, etc.

4) Version control within the excel file... may be this is going beyond the
original ask... but I think the spirit of introducing Python into excel, is
around better SDLC/reusability. And so local and remote version control models
should be supported.

5) I personally do not care if other MS Office tools (eg MS word) support
Python. Would be nice.. but for my needs, this is not relevant.

6) a type-checking mode to be able to say, this Module will type check the
data it uses... at run time.

------
HumanDrivenDev
An absolute no-brainer. Python is the new BASIC - very popular with people who
have to program to do their work but aren't programmers. It's an excellent
choice for a spreadsheet.

~~~
blhack
>aren't programmers

Also extremely popular with people who _are_ programmers and need to do
things.

Sorry, this is a frustration of mine lately. Python is a _fantastic_
introductory language. It's also a _fantastic_ general purpose language.

Newbies get turned off of it because it feels too easy, and they know that
"real" programming is supposed to be hard.

~~~
gregschlom
I disagree.

Python is great for scripting and for small projects, but I believe strong,
static typing is an essential feature for large scale projects. I wouldn't
want to use Python for anything that's predicted to end up with more than a
couple thousand lines of code.

~~~
stestagg
Last time I saw the Bank of America python codebase, it had ~6 million lines
of code, was worked on by about 4,000 developers, and ran some core,
performance critical functionality.

Python programming is an aesthetic that needs learning. Many of the worst
written, and least maintainable python codebases I've seen are by
programmers/teams coming from "proper" languages and don't think they have to
learn how to write idiomatic python.

~~~
rogerbinns
A bit dated now, but still a great read about a Python project done by Java
developers: [http://dirtsimple.org/2004/12/python-is-not-
java.html](http://dirtsimple.org/2004/12/python-is-not-java.html)

"So, the sad thing is that these poor folks worked much, much harder than they
needed to, in order to produce much more code than they needed to write, that
then performs much more slowly than the equivalent idiomatic Python would."

~~~
stestagg
Yeah, I've seen that story played out so many times.

Best example I've seen was from a couple of Java devs transitioning to python,
they re-wrote a system 3 times: 1st time: 35k loc 2nd time: 10k 3rd: 2k

The third rewrite was also significantly faster than the first two :)

------
andygreenwell
Glad to hear that the Excel team is finally listening to your requests on this
one. It's been a long time coming. Too bad they weren't interested during the
TC days. If it does happen, it would be great if you could get the Cloud
Numerics effort rebooted as well. There might still be a few people from our
old team at NERD capable of resurrecting it.

------
erichurkman
I would love this, but for a unique use case: we generate _a lot_ of workbooks
using Python. Some of them have hundreds of thousands of automatically
generated formulas. We also have to write tests for workbooks. If we could
embed Python, which all of our developers know, into Excel, it would make
testing our formulas a bliss, rather than the burden it is today.

------
resoluteteeth
Excel already has VBA, C add-ins, COM interop, VSTO, javascript addins, and
random functionality that's only available by using functions left over from
Excel 5.0 macros (before VBA). These all have different weird limitations.

What Excel absolutely does not need is for Microsoft to add another scripting
language in a half-assed fashion and then get bored and stop again.

------
shubb
Is anyone using javascript to write excel macros?

That functionality has been out but a while right?

Do people use it? What do they use it for? What makes them step back and reach
for pandas or salesforce instead?

For me, working across multiple excel files sucks right now. Excels handling
of datatypes kind of sucks. And pretty spreadsheets that people like looking
at and working with have a bunch of annotation in them so you end up
extracting the sub tables you need anyway - why not into csv/dataframes.

Tableu makes a lot of this better. Why not copy them instead of giving us
another language to cheer about then ignore.

Why not integrate power bi more tightly with Excel and ship it in the basic
version of office, then let us script in there?

------
rmbeard
There are now plenty of Python modules for working with Excel and Excel format
files. Why are they trying to compete with those? As a university teacher I
have dropped the use of Excel from my classes. I'm really not convinced this
would convince me to go back. The philosophy of the product is just wrong. The
should probably consider retiring Excel itself while maintaining support for
Excel file formats. If they were to get behind some of the existing Python
module initiatives or do something similar this would not be bad either, but
using Excel as a front-end to Python is just a bad idea.

~~~
thatcat
>Excel as a front-end to Python is just a bad idea

I think a lot of people would like this because you can look at more data on
your screen at once with excel compared to jupyter notebooks. What's the
downside?

~~~
rmbeard
The downside is

i) reproducibility. In the academic/research world there is a big move towards
reproducible research, the nature of the Excel interface is not conducive to
that. A standard scripting language is fine that plays with Excel but you
don't want Excel necessarily as the main access point and the menu driven
approach isn't conducive to keeping a permanent record of what buttons you
click on. ii) In multi-cultural settings Excel defaults to the users system
language, these days you simply jsut work with students laptops rather than
using a standardized lab, so unlss you are polyglot working with Excel is just
a really bad idea. Jupyter provides a standard interface and the default is
always English, but supports multilingual content. iii) Python modules provide
a huge range of solutions for many different domain applications, it's hard to
see how Excel as an interface would provide support for every one of these
modules. What I mean is how would Excel work as an I/O interface to a Python
script that was doing something other than working with data? Notebook
solutions already do this quite well.

------
ninjamayo
Just do it! We 've been waiting for decades for a replacement of visual basic.

------
jgamman
Aim for a front end notebook interface like Jupyter or Mathematica. Most excel
i've had to play with was to store/manipulate data _and then_ C&P charts or
data to word for the report. Seriously, notebooks.

~~~
rmbeard
You can basically use Jupyter as a frontend to Excel now anyway and never need
to open Excel except to read and write to Excel files that you are sharing
with Excel users.

~~~
jgamman
that's cool - hadn't realised. i still dream about a word-excel mashup.
imagine a table in word that when you click on it revolves around to reveal a
spreadsheet and you hook the 'other side' to the calculation cells. literally
separate data and text/analysis but packaged as a unit.

------
Yuioup
As well as agreeing to this, I would add the following:

* I would support both Python 2 and Python 3. Yes I know that the push to Python 3 is ongoing but there are a lot more libraries to be found for 2. Don't bother with IronPython.

* I would integrate pip or whatever package manager Python uses these days so that people can download their own modules and use them in the Excel sheets. Not only that, the packages should be restored automatically when the Excel sheet is loaded.

* It goes without saying that Python should be sandboxed.

* VS Code integration in Excel with full syntax highlighting and autocomplete - again a no-brainer.

~~~
rspeer
> I would support both Python 2 and Python 3.

Nah. They can spare a lot of pain and confusion by not having two _different_
Pythons with different sets of libraries in Excel, and they have this
opportunity because they don't have to support people's old Python 2
spreadsheets. There _aren 't_ old Python 2 spreadsheets.

The libraries that are stuck on Python 2 really don't seem relevant here.
There aren't many of them anymore [1], and I don't think people will be trying
to run graphite-web or some busted old OpenID provider in their spreadsheet.

(I originally used Fabric and Twisted as examples in the above, but hey, those
are on Python 3 now. Also not things you'd be likely to use in a spreadsheet.)

[1] [http://py3readiness.org/](http://py3readiness.org/)

------
valuearb
They should never do this because many people spent lots of time learning
existing Excel scripting and they won't like it. Fortunately the user feedback
will likely be very negative, so will stop this is it's tracks./s

Henry Ford: "If I asked customers what they wanted, they would have said
faster horses"

Steve Jobs: "A lot of times, people don't know what they want until you show
it to them"

Seriously. Just build it and and make it great. When you can show that you can
do amazing things with it, release it. The downvoters will also then adopt it,
if you made it great.

------
pessimizer
As long as the range object works in the same way, I don't care. Would be nice
to have proper objects instead of having to use interfaces. It would also make
a nice sandbox for beginners to learn python.

------
serialhex
Please God no! I'm all for a scripting language but the poor quality and
inconsistencies of Python makes my life so much harder in the 5 other
applications where it is the ONLY way to script everything. The fact that it
is whitespace sensitive I have found makes it harder for beginners who try to
edit pre-existing files that mix tabs and spaces. That's one dumb thing but
there are many other thongs that bother me about Python. Yes to a scripting
language, please no to Python.

------
DoubleCribble
I know it's heretical amongst the Finance types... but one of the few reasons
to use Sheets over Excel is for its scripting abilities. This will remove that
advantage.

~~~
kevin_thibedeau
Alt+F11... Script away.

------
kazinator
Anything you think you can solve with Excel plus Python is much better done in
just Python.

This is like adding a tumor to Python.

Operable, luckily.

------
donatj
I hate to say it but why not ECMA Script (JS)? It’s everywhere and everyone
knows enough to get by...

~~~
pbreit
JavaScript is the obvious call.

App Script for Google Docs/Sheets is very powerful and one of my favorite
features:

[https://developers.google.com/apps-
script/guides/sheets](https://developers.google.com/apps-script/guides/sheets)

It makes for an excellent API runner. You massage a data set and then run it
against an API very easily.

------
eggy
I am all for more ways to hook into Excel since it is integral to many things
I do for my job. There are some F# ways to play with Excel. I just wish MS
would give more love to F#.

    
    
      [1]  http://fsharp.org/guides/data-science/#excel-interop

------
agumonkey
python isn't the bestest thing in the world but it's still a massive win for
them, and a massive win for excel users. VBA had too many shortcomings and led
to loads of scalability problems even for medium size apps.

~~~
cm2187
To its defense VBA litterally hasn't been updated in 20 years. It's hard to
hold a 90s language to the 2010s standards.

~~~
agumonkey
Fair enough. Although the jury is still out about it's value in the 90s too :p

------
seak
Am already excited for this and would use it to the fullest.

But i think Microsoft in doing this should come up with a way we can plug any
other language(julia,lua,...). Getting this right now would mean a lot.

------
tg2
Supporting R or Typescript/JavaScript would be great and probably closer to
the Microsoft ethos (R is already very well supported in SQL server and
PowerBI).

------
princeb
honestly don't know how they are going to integrate python for me to think
about how it could affect my workflow.

it could be entirely possible that you could create both VB modules and Python
modules in alt-f11 and functions and subs from either could be called from the
spreadsheet. this would be great. if python had to be run in a separate app,
not so great.

will python in excel rely on the environment(s) installed independently in the
system or the excel python environment? if the former, how to standardize
runtime across different machines?

support for the scipy libs and matplotlib would be nice. maybe matplotlib will
generate plots in its own window - 6/10 if so. if matplotlib can generate
plots as its own object within excel sheets - 7/10\. if the plot is reactive
to changes along its dependency chain - 9/10\. if you can right-click format
shape and adjust colors, lines, scales, axes - 10/10

support for python exception handling - well... ANY exception handling besides
"ON" ERROR GO TO" / "RESUME NEXT" \- 11/10

python with alt-f11's immediate and locals window + breakpoints + steps -
10/10.

what about windows api? office interop? internally built xlls? guessing these
will remain with VB and will remain compatible. guessing excel/office object
models will also remain the same structure in python for excel.

don't really care about output into jupyter. excel has "cells" too so you
could technically output into a protected sheet if you wanted a read only
report. we used to generate publications out of excel - chuck in some data
into the sheets, matlab takes over the computation and spits it back into
excel and a full report with cover sheet / table of contents / page numbers
etc will be generated and we'd print and bind it professionally and send it
back to the client.

just a philosophical musing... excel is very "functional". from each cell/cse-
array in your raw data to each cell/cse-array in final output there really
ought to be a single chain of functions. i see a few comments here and on
reddit where people are looking forward to happily blasting for loops on each
cell in book-wide subroutines. that breaks the "functional"-like quality of
excel. that makes excel a million times harder to audit. excel at its best
should look a lot like f#.

------
muxator
I am 90% certain that MS has abandoned its EEE strategy from the nineties.

But the scars from that era are so vivid in my mind, that I feel the need of a
confirmation.

~~~
abraae
What do you want confirmation of?

That MS is now a gentle, caring beast? Large organizations are not like that,
they are money making machines that adopt strategies to maximise profit. EEE
is no longer such a strategy, though it worked very well for a long time.

Will MS ever go EEE again? In a heartbeat if they felt it would maximise
profits.

Does that seem likely in the short to medium term? No, the industry is
different now, and they have to play nice.

------
pcvarmint
This is a long time coming. There's a big backstory to it. Let me explain.

"Exie" was the codename for Microsoft's attempt to create, in Excel, a
language similar to MATLAB (and later, Julia). The name "Exie" meant that it
would be integrated with Excel. It was based on Alan Edelman's Interactive
Supercomputing (ISC), which Microsoft acquired in late 2009 [0]. ISC's main
product was Star-P, an auto-parallelizing compiler in which users used a *p
suffix in an array dimension to indicate parallelism across that dimension,
similar to CoArray Fortran.

Unfortunately, the ISC acquisition was a failure. Microsoft already had
agreements with MathWorks and Cleve Moler (makers of MATLAB) which prohibited
competitive software like Star-P. So Microsoft had to scramble and find other
ways to get analytic, REPL, MATLAB-like software out the door. Unbeknownst to
Microsoft, Julia was already making faster progress than they ever did, but on
similar goals. Julia is what Microsoft had hoped Exie to become, and it's not
a coincidence that Alan Edelman has been involved in Julia.

Then, Steve Ballmer decided to abandon HPC and mathematical software, and to
focus mostly on the cloud, which led to the very public dismissal of Bob
Muglia.

The head of Microsoft Technical Computing, Kyril Faenov, unfortunately
committed suicide a year later. His wife, the daughter of a famous Seattle
architect [1], did not respect his Jewish mother's wishes on the handling of
his remains. His mother fought and lost in court [2].

Maybe Microsoft embracing Python in Excel is the best that can be hoped for
now. It's certainly better than VB. But Exie tried, almost 10 years ago, to
create an Excel environment closer to modern-day Julia than anything else.

There were a lot of personal sacrifices in that effort. For example, Bill
Blake, the former CEO of ISC, stayed at MS for a while during the transition,
then moved to Cray as CTO for a while, and then died unexpectedly less than 4
months after he joined D-Wave. [3] [4]

There's certainly been a lot of casualties, in the attempt to bring Excel up
to being more analytically-friendly. Is it really worth it?

[0]
[https://blogs.technet.microsoft.com/windowsserver/2009/09/21...](https://blogs.technet.microsoft.com/windowsserver/2009/09/21/microsoft-
acquires-the-technology-assets-of-interactive-supercomputing-isc/)

[1]
[http://archive.seattleweekly.com/news/956673-129/seattleland...](http://archive.seattleweekly.com/news/956673-129/seattleland-
latest-selig-real-estate-fight)

[2] [http://caselaw.findlaw.com/wa-court-of-
appeals/1735359.html](http://caselaw.findlaw.com/wa-court-of-
appeals/1735359.html)

[3] [https://www.cray.com/blog/cray-ceo-reflects-on-bill-
blakes-l...](https://www.cray.com/blog/cray-ceo-reflects-on-bill-blakes-
legacy/)

[4] [https://www.dwavesys.com/blog/2015/04/bill-
blake](https://www.dwavesys.com/blog/2015/04/bill-blake)

~~~
andygreenwell
An additional note for posterity here...one of the main reasons Microsoft was
interested in acquiring Interactive Supercomputing was that ISC developed it's
own M-language (Matlab) compiler M# built on Mono/.NET...basically a faster
Matlab replacement than Octave, using features like multiple dispatch. One of
the primary developers of the M# compiler at ISC was Jeff Bezanson, co-creator
of Julia.

Exie used a bit of code from M#. When Exie was cancelled, the libraries were
given a C#/F# facelift as Cloud Numerics, which was eventually cancelled, and
then given a GUI facelift as part of the initial version of AzureML.

Disclaimer: I previously worked at Interactive Supercomputing, was part of the
team acquired into Technical Computing/HPC at Microsoft, and also worked at
Julia Computing.

~~~
byt143
Julia is open source...why don't they just incorporate it?

------
barrystaes
I hope they wont localise the function names like they do for cell formulas.
Never have i met someone who enjoyed this.

~~~
froindt
I do quite a bit of VBA, but not much other programming. Could you clarify
what you mean by localized?

Just that the cell formulas cannot be (elegantly) accessed from VBA?

~~~
edanni
The formula names are translated into different languages so if you are used
to using Excel in your native language you can't easily use it in English or
vice versa.

------
kolombet
I would prefer JavaScript as scripting language. Or make support all clr
compatible languages

------
obilyk
F# should be best is Excel macros language. You may provide option to run
Python from F#.

~~~
johnmalc
yes please !

------
timothylaurent
This will be >>> better than using JS as a scripting language in Google
Sheets.

------
thkim
pro: better compatibility with external libraries, syntax is nicer

con: GUI programming will suck unless .net adds "visual python"

I don't have statistics but I imagine people would prefer sticking to VB for
ease of adding buttons, etc.

------
cies
I thought there was a project for typed Excel. Any news on that one?

------
gigatexal
Do it!!!!!! To stay relevant do it!

I mean any language would be better than VBA.

------
notsgnik
Native virtualenv and python inside windows would be great :p

------
gpw501
I'd like to see perl integration, that would be rad.

------
jonbarker
You can already do this with xlrd and xlwt.

~~~
civilian
Excel spreadsheets are cool because if you update data somewhere, it'll update
all the formulas and products elsewhere.

How do you get that kind of "watch" behavior with `xlrd` and `xlwt`? You
don't, you have to re-run a script. Sucks.

~~~
rmbeard
Try XLWings

~~~
civilian
Right. XLWings looks like a cool tool.

But the point I'm making is that: It's still a good thing for Excel to be
integrating more tightly with python. It'll help all of those non-developer
normies get the magic of coding.

------
ww520
Why not Typescript or some languages with stronger type support? Auto-complete
is much more useful with a typed language.

------
nusq
Yes please.

------
kevin_thibedeau
Why not make it work with Windows Script Host for any compatible language?

------
borplk
"NO! I prefer VBA to Python!" Said no one ever :)

~~~
kgwgk
Thousands of people would say it if MS attempted to remove VBA telling people
to use python instead.

------
supbitcoin
please do that

------
pruthvishetty
Yes, please.

------
Jacek1959
Why not C# ?

~~~
taspeotis
Python is used a lot for number crunching/data science. It has an ecosystem
for that. Excel has the numbers. People want the two together!

------
DonnyV
Don't do it!

~~~
civilian
Why?

~~~
DonnyV
The people that are going to use this aren't programmers. They are going to
hate that the code has to be indented properly or it is considered an error.

------
probinso
should probably be prolog or apl instead

------
lafar6502
Maybe they read it here: Keep Excel application as is. Excel is OK without
Python and VB seems ok, it's BASIC after all. Instead, concentrate on making
Excel functions embeddable in server applications, this is area totally
neglected so far. Think about server-side spreadsheet handling and
calculations, that would allow Excel to drive business logic of systems. And
maybe there Python would be useful, but i'd prefer just .Net runtime libraries
instead.

~~~
odonnellryan
The best solution to this, in my experience, has been a data-backend for
Excel.

No, I'm not talking about connecting via ODBC. Rather, generating Excel
documents from a data store: which may possibly be versioned and so on.

Excel is not a good place to store data. It is good to work with data. It's
really, really good to view data. People love it for that. But when you start
to store a lot of data in Excel ...

------
malmsteen
Well python is pretty much already well established but it should be wary of
te famous "Embrace Extend Extinguish".

------
mosselman
Ruby is a lot more non-programmer friendly and has an easier syntax if you ask
me

------
jbergens
I think python is a bad choice for Excel, Ruby would probably be easier to
people who are not developers and javascript might work just because if its
reach (while still being simple).

~~~
lawnchair_larry
I think basic Python is far easier for a newbie to learn than Ruby, and is
commonly used as a scripting language for non-programmers.

------
johnthomas00
Does not M$ have a track record of getting everyone on board and then
murdering everything in site. I mean it sounds good, but I don't trust M$.
Maybe they have changed, but I'm not yet convinced.

~~~
quickthrower2
Embrace and extend python? I think not.

