Microsoft Considers Adding Python As an Official Scripting Language in Excel (bleepingcomputer.com)
An anonymous reader writes: Microsoft is considering adding Python as one of the official Excel scripting languages, according to a topic on Excel's feedback hub opened last month. Since it was opened, the topic has become the most voted feature request, double the votes of the second-ranked proposition. "Let us do scripting with Python! Yay! Not only as an alternative to VBA, but also as an alternative to field functions (=SUM(A1:A2))," the feature request reads, as opened by one of Microsoft's users.
The OS maker responded yesterday by putting up a survey to gather more information and how users would like to use Python inside Excel. If approved, Excel users would be able to use Python scripts to interact with Excel documents, their data, and some of Excel's core functions, similar to how Excel currently supports VBA scripts. Python is one of the most versatile programming languages available today. It is also insanely popular with developers. It ranks second on the PYPL programming languages ranking, third in the RedMonk Programming Language Rankings, and fourth in the TIOBE index.
The OS maker responded yesterday by putting up a survey to gather more information and how users would like to use Python inside Excel. If approved, Excel users would be able to use Python scripts to interact with Excel documents, their data, and some of Excel's core functions, similar to how Excel currently supports VBA scripts. Python is one of the most versatile programming languages available today. It is also insanely popular with developers. It ranks second on the PYPL programming languages ranking, third in the RedMonk Programming Language Rankings, and fourth in the TIOBE index.
I have been wanting to be able to write C# to automate functions in an excel sheet.
You can easily do that since long time ago. There are even different alternatives (e.g., relying on a template or creating everything on-the-fly). If I have to communicate with MS Office and I can choose how to do it, I would develop a C# or VB.NET application rather than relying on VBA.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
VB.Net is .Net first and VB second.
For example, if you type If foo = "1234" Then, it's doing some wonky-ass classic VB shit in the background (implemented in the Microsoft.VisualBasic namespace syntax shims) to allow variable foo to be an Int32 and still compare without a type mismatch. If, in C#, you try the same thing with if(foo == "1234") and foo is an int/Int32, it's going to flip its shit at compile time. But best of all, in either language, you can do If foo.op_Equality("1234") Then (or if(foo.op_Equality("1234")) in C#) and get the standard C#-style and .Net standard equality comparison operator functionality that bypasses the classic VB shims.
VB.Net is .Net first and VB second, only by means of the compiler handling special cases to fill in keyword functionality with Microsoft.VB shim code that works differently than bog-standard .Net. These shim functions generate some terribly expanded MSIL for things that look like they're simple language translation.
On a related note, you can add using Microsoft.VisualBasic to your C# code and start using things like Strings.Equals(object), for example, if(Strings.Equals(foo)), where foo is an Int32, like the previous example. This will use the "wonky-ass classic VB shit" string comparison, even in your C# code. With all of the MSIL performance gotchas that apply. .Net is an incredibly flexible ecosystem, and Microsoft strives to make things "easy" for newbies. But if you familiarize yourself with its inner workings, you'll quickly find that it's both every bit as complex as C/C++ and simultaneously capable of doing all of the same hideously unmaintainable performance tricks. It just makes them unnecessary most of the time.
Office suite + Python = OpenOffice. This is already a thing.
Weaselmancer
rediculous.