https://excel.uservoice.com/forums/304921-excel-for-windows-desktop-application/suggestions/10549005-python-as-an-excel-scripting-language
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.
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.
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.)
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.
---
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.
The https link doesn't seem to work, try this:
https://excel.uservoice.com/forums/304921-excel-for-windows-...
[disclaimer+bias: on Python team @ msft & would love to see this happen!]
https://www.python.org/dev/peps/pep-0551/
There's a YT talk as well.
Well, I guess that explains why you care about Office in 2017.
I'd argue large companies are still running Windows because of Office. The cost of retraining people, redesigning all of these user processes and converting all those documents would be massive. Whereas most new corporate applications in the last 5 years have been mostly web based.
So I am surprised Microsoft under-invest in what is they main strategic lock-in in the juicy enterprise market.
The first release to feature the Ribbon, arguably one of the all-time major changes in Office, was 2007. That took quite a bit for most users to get used to.
An Office suite is not where you add experimental features for the hell of it. People use it to get the job done in so many different scenarios, any change will significantly impact entire industries.
Office programs are the "lawyers" and "accountants" of the software world: their work has been more or less the same since they existed, and any major change to them is a basically societal upheaval, so their approach will always be naturally conservative.
There are many things lawyers, bankers, consultants and accountants would need that Office doesn't do. Linking a spreadsheet to a powerpoint document is a nightmare right now. Linking spreadsheets between them too. There should be a way to express a UDF as a spreadsheet so that people who can't code could create their own UDF. I love Apple's Number canvas approach, where a sheet is not a grid but a canvas on which you can add grids or charts, and they overflow with a scrollbar. Etc.
There are lots of new functionalities they could add that would make people's life better. Instead these products barely evolved in 20 years. Click the "fx" button in excel 2016 and you will get the same non resizable dialog box with a tiny listbox and a search box that doesn't search anything than in Office XP.
* Python 3
* Numpy, SciPy, Pandas, Matplotlib, Altair, ...
* Pythonic bindings for Excel APIs (sheets, etc etc)
* VSCode's Python Editor + Debugger built in
* Some sort of conda based env/pkg mgmt
* Right-click, "Open in Jupyter" (data/code)
* <your wish here>
I mean, MS implemented these really nice Tables in excel, but then left us no way to easily query them with something like SQL.
Are there plans to get this working with the Excel web-app, or just the desktop version? I'm just having a daydream about Excel, Juypter notebooks, and OneNote Class notebooks...
Our team provides a free service for anyone to run Jupyter Notebooks on Azure. It's currently a big hit with the Edu crowd. We're seeing lots & lots of universities upload & teach courses on it. eg:
http://notebooks.azure.com/richie
There's also an Intro to Python notebook on the front page.
Hopefully the Excel team will consider Jupyter integration, esp for the web-app version! You're right that it's a killer combo. Check out xlwing's video on using Excel+Jupyter - it's brilliant.
for row in rows:
do some cool stuff
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.
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.
https://en.wikipedia.org/wiki/Component_Object_Model
that is how people do stuff with VBA and Powershell and you can do it in Python with
Could they use Microsoft's old Windows Script Host thing?
The main thing that might be nice is tables as a data structure for spreadsheets, but somehow I picture pain.
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!).
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.
Aside from that it sounds like a cool idea.
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?
I am looking forward to what a Python & Excel marriage will look like.
http://www.prweb.com/releases/spreadsheet/competition/prweb1...
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):
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.
Flowsheets has become my preferred data manipulation environment.
Would this get better in Python? I hope so.
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.
See Http://www.datanitro.com
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})
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
[1] http://www.felienne.com/archives/2964
[2] https://figshare.com/articles/BumbleBee_A_Transformation_Env... Paper on BumbleBee
[3] http://gotocon.com/dl/goto-amsterdam-2016/slides/FelienneHer...
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.
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.
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.
Edit: I suppose my point got a little lost. What I mean is that I highly doubt much Excel code is a "big project." It may feel that way when you crawl through some of the hideous VBA coding I've done but much of this is due to the inexperience of the coder and the realities of VBA. Give me python + 4 or 5 libraries and I could recode anything I've ever made in VBA in 1000 lines or less.
I understand, though: you hate VBA. And by extension, Access. But Excel, with or without Python, doesn't mean it can suddenly be used as a relational database. But you knew that.
So, what should replace Access?
Most used: everyone pays taxes. Paying taxes is popular!
A more practical example is javascript. I write some javascript, not because I like it (I hate it), but because that's the only way to make things happen in a browser. Javascript is popular. Does it mean it is liked / a good language?
No it does not, neither in theory nor in practice. Also, "less code" depends primarily on the language structure and not on whether the language is dynamically typed or not. (Haskell, for example, is more terse than Python.)
I've yet to come across something that was fewer loc in C++/java than in python.
That said, this is true even if I use pytype.
Every sufficiently large test suite will contain an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a proper type system.
(I too enjoy a good pseudo-Greenspun)
More seriously something I've been pondering a lot recently watching the old pendulum swing back towards an enthusiasm for explicit typing is this:
* The advantages of static type systems are obvious and easy to articulate. * The disadvantages of static type systems are subtle and difficult to argue.
I started my career as a professional programmer when the pendulum was moving in the other direction. Essays by Paul Graham on Lisp and Python. The marvellous PJ Eby piece quoted above and Peter Norvig's "Design Patterns are artifacts of language flaws".
I just feel dynamic languages fit my brain better but maybe that's my own form of Stockholm Syndrome. Maybe I need to try a decent type system rather than the brain-damaged descendents of Java...
After some time doing that a Java project came up, so I grabbed Lombok, Vavr and started writing Java as if it was just another ML (immutability first, paying attention to side effects and so on) and the whole thing made sense. More sense than all those years of OOP teachings. The code was easy to debug, easy to reason about, easy to change. And it was Java. And that just stunned me for life.
Then of course, I started using TypeScript for React development and giggled like a little girl every time I had to refactor something, for I KNEW that it was very unlikely I'd have to stare at the debugger for long periods of time in a wild goose chase like I often had to with plain JS.
But the trick was to learn the way of doing things in the languages that really guide you towards that path.
I can definitely recommend that you try Elm if you're into frontend development, or something like F# if you want native. As far as docs go, the Elm guide and fsharpforfunandprofit.com are both great; the latter I can recommend regardless of your language choice for making typed functional programming make sense. I can also recommend the book Type-Driven Development with Idris, which has also been an invaluable resource to really understand that way of doing things.
Anyway, I doubt that a VBA replacement would need types. The use case is small scripts.
There's room for both paradigms - it's kinda silly to argue strict superiority of either because there's just no empirical evidence that having static typing or not drastically changes bug count.
If you take a look at some of the studies out there that do exist (which there are, admittedly, few, and it's a fundamentally tough thing to measure), e.g. [0], it usually tends to be the case the both typed and untyped languages show up in the realm of "least likely to produce bugs"
[0] http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf
Put me with Op. I'll use Python for prototypes and small tools but get past that and I want a statically typed language. Not just for validation but also refactoring.
You're testing things that need testing either way, and incidentally also testing the types.
However, it tests values for correctness. Values have types. So if you are testing whether something has the correct value, you are also testing implicitly that it has the correct type, because for the values to match, the types must also match.
That's what the vast majority of testing is when it isn't simply testing mock code implementations.
My only complaint about Pytype is that there's no `Char` type at compile time (ie `for x in "a string"` -> Iterable[Char] instead of Iterable[str] during typechecking). But alas.
On the flip side, i use interfaces and dependency injection constantly in java to work around static typing. In python, i write probably ~20% the amount of code because i never use interfaces, wiring logic or convert types.
Write a Python program. Compile it as a Cython program. (Already faster, with no changes.) Add C types to the speed-critical parts. (Up to many 100s of times faster than Python)
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.
"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."
I included a link to this blog-post in the "letter of intent" (don't know the exact English term) that I sent to my potential employer just before my first interview for a professional (Python) programmer job, back in 2005. I got the job. Good 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 :)
This is empirically false.
There are (of course!) good reasons to consider static typing. But, in my experience, use of static typing has never been a first-order predictor of business or technology success. It's quite possible to build considerable value with, for example, a large Python 2.x code base.
A fun, and tangentially related, talk: https://www.destroyallsoftware.com/talks/ideology
For example, nullability annotations reduce nil pointer exceptions.
Static typing removes the need to make certain typing unit tests, makes refactors easier to do in large code bases, makes it easier for compilers to generate faster code and so on. Think of them as compiler level linters.
Anyway, python has a static gradual typing mechanism. You should try it out :D
In my view, classes are types. (Well, maybe I'm just spoiled by C++.)
I understand the word "type" to mean a property of a variable which restricts the range of values it can hold, and the set of methods which can be invoked on it. Smalltalk doesn't have any way to do either of those things, so it has no types.
Interestingly, it seems that this was planned for Smalltalk, but never implemented; a 1981 article about the design of Smalltalk [1] says:
"Also, message protocols have not been formalized. The organization provides for protocols, but it is currently only a matter of style for protocols to be consistent from one class to another. This can be remedied easily by providing proper protocol objects that can be consistently shared. This will then allow formal typing of variables by protocol without losing the advantages of polymorphism."
[1] https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....
> big boon
But they argued ‘essential’. You’ve watered that down to nice-to-have.
Not everyone likes IDEs (Emacs and VIM are still by far superior to many) and not everyone wants to deal with all the extra code and boilerplate and ad-hoc data classes that comes with static typing, to name a few.
Dynamic languages have faster iteration times and from experience that can yield higher quality software. They're easier to fit in the functional paradigm, better to model data transformations, and a bunch of other goodies.
You can't judge something without taking into account the context in which its used. And for scripting something like Excel dynamic is clearly superior.
You may like plain text editor but for someone who doesn't know how to program, typing a variable then dot, and having a drop down of what is available from there, with an embedded documentation and direct IDE feedback on what is correct or incorrect syntax immediately after typing every character is super useful. RTFM isn't novice friendly.
Its still possible for dynamic languages to have auto-completion. There's way more information available at runtime than at compile-time.
Besides, IDEs tend to have the entire world in most autocompletions, which is not useful either.
There would be no IDE here, you'll probably still write code from within Excel and advanced users will use separate source files to leverage their editor of choice.
The novices you mention will not want to leave Excel. A dynamic runtime with reflection is all you need to give a friendly experience. That doesn't prevent type hints, inference or autocompletion.
I would hate a typed language in there. Besides most static typing systems are ridiculously weak and introduce more headaches than they actually solve.
E.g. Go (and I still love Go, but it's pretty weak...)
With some of the spreadsheets I've seen, the next Netflix might just come out of it.
Just kidding, but only a bit. I've been at factories where if VBA stopped working, I literally don't know if we could have produced product that day.
You mean like Dropbox, Evernote, Ansible, OpenStack etc.
Python is strongly typed and has an available static typechecker, so, even if this is true, it doesn't rule out Python for this use case.
because it has no long term potential
It also allows a developer to manipulate individual bits, which is pretty amazing for security research or other cases when you want to get low level but don't want to get in the weeds with C.
You'd be hardpressed to reinvent excel in a browser. Sheets is a big, advanced web app but it doesn't even come close.
No true scottsman etc.
Why do you find it so fantastic? What stands out for you?
Python was my first real programming language, but I don't see anything very attractive about it now - save the libraries.
I would even say it would fit better, not because the language is better, but because indentation wouldn't go in the way for quick & dirty one-offs.
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.
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?
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?
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.
* 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.
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.)
http://www.python3statement.org/ <- look at the list of projects dropping support... NumPy, MPL, Pandas, SymPy etc.
Not to get into a huge python debate. But this statement is just blatantly false.[0] Unless you are in a niche domain, the library you need either supports Python 3 or (increasingly, esp. among newer packages) is 3-only.
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.
This is like adding a tumor to Python.
Operable, luckily.
App Script for Google Docs/Sheets is very powerful and one of my favorite features:
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.
[1] http://fsharp.org/guides/data-science/#excel-interopBut 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.
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#.
But the scars from that era are so vivid in my mind, that I feel the need of a confirmation.
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.
They still do the EEE strategy. Fool me once...
"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...
[1] http://archive.seattleweekly.com/news/956673-129/seattleland...
[2] http://caselaw.findlaw.com/wa-court-of-appeals/1735359.html
[3] https://www.cray.com/blog/cray-ceo-reflects-on-bill-blakes-l...
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.
Just that the cell formulas cannot be (elegantly) accessed from VBA?
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.
I mean any language would be better than VBA.
How do you get that kind of "watch" behavior with `xlrd` and `xlwt`? You don't, you have to re-run a script. Sucks.
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.
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 ...