Feedback by UserVoice

Zev Spitz

My feedback

  1. 27 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Zev Spitz commented  · 

    NB While these are Excel object model functions, they aren't VBA functions as they could be used from any language which supports COM.

  2. 119 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Zev Spitz commented  · 

    @JamesLee @vinnyjames I think an overhaul of the IDE is not something Microsoft is willing to invest in ATM. However, if MS would be willing to provide a language server, any editor (VS Code, Atom, Visual Studio, Eclipse, etc.) could theoretically be used to write VBA code.

    Fortunately, the Rubberduck community have started work on a VBA language server (https://github.com/rubberduck-vba/Rubberduck/issues/5176) using the Rubberduck parsing engine, so we won't have to wait on MS for that either.

    Zev Spitz commented  · 

    @FatDan

    > it's quite frustrating to have to use the much more limited language of VBA

    What specific language features do you feel are missing from VBA? Not editor features, because that is the subject of this suggestion. The only language feature / API I miss very strongly is functional data processing, which would require 1) first-class functions, and possibly 2) generics.

    @vinnyjames

    > much harder to manage than it should be with Excel's VBA editor

    Again, does this reflect the limitations of VBA? Or is this because of the ancientness of the VBA editor?

    The litmus test would be to use http://rubberduckvba.com, which is an active addin for VBA dedicated to adding features to the editor.

    Zev Spitz commented  · 

    > translate 90% of VBA scripts to VB.NET

    What would VB.NET bring to the table that you don't already have in VBA? It would only increase the complexity of what is a very simple use case -- scripts that manipulate Office application objects embedded inside Office documents.

    Zev Spitz commented  · 

    > I hear you saying we need a VBA.net.

    I think the only changes to VBA which would add significant value, would be 1) access to the .NET framework, and 2) functions as first-class-citizens, which would enable LINQ-style data processing.

    Zev Spitz commented  · 

    > when you have processors with 8 cores 16 threads and there you have a language which is single threaded.

    In order to use that power, you need a language which introduces significantly more complex paradigms. Just like it doesn't make sense for virtually all LOB applications to be written in assembly, in spite of the greater power and flexibility this would offer; the use case for VBA usually doesn't require the performance efficiency that multithreading would bring.

    > why anyone would complain about VBA and suggest that JS is a viable replacement

    Two points: 1) I'm not advocating Javascript necessarily; but the VS Code architecture would make it trivial to add Intellisense from the Office APIs to various language extensions. In contrast, if you look at LibreOffice/OpenOffice support for various languages, each language has its own editor with varying levels of capability.

    2) Javascript's warts show only in larger code bases, handled by multiple team members. The use case of a standard VBA project could be handled by Javascript.

    > It makes far more sense for the official language to be VB.NET as this is the rightful heir to VBA7.

    And yet, after nearly 20 years, VBA has not been replaced with VB.NET, because VB.NET is still not a drop-in replacement for VBA. Programming in VBA is a simple matter of opening the editor writing code, and saving the file; the code is now part of the document. Providing embedded VB.NET code in an Office document, or via an Office add-in, is an order of magnitude more complicated/

    But again, the point here is not "what should the official language be?", but rather making it possible for **any** language to be embedded in an Office document and to make use of the application's API, and providing a unified editor experience via VS Code.

    > But VB.NET is a must since it will be much more similar to VBA and allow porting of macros more easily.

    VB.NET is far closer (though not entirely so -- https://anthonydgreen.net/2019/02/12/exhausting-list-of-differences-between-vb-net-c/) to C# than VBA. There may be some superficial resemblance in syntax between VBA and VB.NET, but a language is far more that its' syntax.

    > allow porting of macros more easily

    ... which is why there are a number of code translators between C# and VB.NET, because that is a far simpler problem than translating between VBA and VB.NET.

    Zev Spitz commented  · 

    @Conan Keep in mind the use case for VBA -- it is designed to augment either an Office document, or an instance of Office. It's not meant to be a full-blown language / environment for standalone programs. Also, because VBA has a relatively long history, and has been adopted in enterprise environments, it is very difficult to divert resources to new features, while ensuring backward compatibilty with all this legacy code.

    Asynchronicity does introduce a certain level of complexity, and in virtually all cases is not needed for the VBA use case.

    Framework support would be nice, but not as necessary.

    A module system is necessary when there is a lot of package churn. In Javascript, where new versions of a package might be released weekly, it is needed. Since VBA makes use of the COM libraries registered on the system, and those libraries don't change nearly as much, a package system is less needed.

    Callbacks would be a very welcome addition, as they would enable a functional style of data processing. I think it's a resource issue.

    Note that @Mathieu Guindon is quite familiar with C#, WPF, and .NET, as he is the maintainer of Rubberduck, an VBA addin written in C# which adds a number of useful features to the VBA IDE.

    Also note that the main point of this proposal is NOT multiple language support against the Office object model (which if you don't want to embed in a document, is quite possible and straightforward). The primary point here is that the VBA editor+debugger is rather bare-bones, and since Microsoft does not seem willing at this point to invest resources in improving the editor, and extending the editor currently requires a deep knowledge of COM and creating COM addins, VS Code seems to me like a viable alternative.

    Zev Spitz commented  · 

    @MathieuGuindon

    I want to emphasize that I greatly appreciate -- and benefit personally -- from your tremendous efforts towards dragging the VBA IDE kicking and screaming into the current century. Rubberduck;s many features fill a tremendous hole in VBA development.

    It certainly would not be "simple" to integrate VS Code into Office; I've listed 4 points (1-2, 4-5) which a possible VS Code extension would have to provide, in order for it to be on par with what exists in the VBA editor today.

    But considering VS Code's flexibility and versatility, and the relative ease with which extensions can be written for it, I think there might be value in such an integration. Case in point -- if the language processing parts of Rubberduck could be separated from UI parts, it could be run in a separate process, working as a language server.

    Zev Spitz shared this idea  · 
  3. 45 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Zev Spitz supported this idea  · 
  4. 6 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Zev Spitz commented  · 

    @DoryOwen I've opened a suggestion here (https://excel.uservoice.com/forums/304921-excel-for-windows-desktop-application/suggestions/20010145-integrate-vs-code-into-excel-at-the-same-level-as). For the most part, it is possible to replace the VBA IDE with VS Code; and editing and debugging VBA from VS Code would be a good first step to opening many doors -- exposing the full Excel API to embedded macros/scripts in other languages such as Javascript, ad positioning VS Code as the editor of choice for the new Office JS APIs.

  5. 6 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Zev Spitz supported this idea  · 
  6. 5 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Zev Spitz commented  · 
  7. 236 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Zev Spitz commented  · 
  8. 6,338 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Wow.

    Thank you to all those participated in our survey. What an amazing number of responses, many of them with very deep content. We’re processing the over ten thousand responses(!), and already appreciate the time so many of you took to answer with passion and experience.

    Please know this survey is used to help influence various topics – both on Python as well as other related topics that the comments started to bleed into. Given the passion, I want to be clear this remains an area of exploration for us, without any specific timeline.

    We’ll provide updates as we progress on this feature request.

    Thanks!

    Ashvini Sharma
    Lead Program Manager
    Excel

    Zev Spitz commented  · 
    Zev Spitz commented  · 

    (Not familiar with R). I support this idea for (if nothing else) Python's lambda expressions, which enable a succinct style of data processing (think LINQ) than requiring multiple nested For/For Each loops in VBA.

    How would the editor/debugging experience work? Must Office also have an embedded Python IDE, like the VBA IDE? I know Visual Studio Code supports debugging Python via an extension, so it should be possible to debug with an external IDE.

    Would Python support be enabled for other Microsoft Office programs as well?

    I understand the intention is to either 1) allow Python programs to be embedded inside Excel documents, or 2) allow Python programs to be hosted by the Excel application. Or both. What about security implications?

  9. 10 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Zev Spitz commented  · 

    @Vogel612

    1,3) Python can access the same COM API as VBA can, via win32com.

    2) Whatever version of Python is installed on the user's system, with an option in the Office options dialog to specify the path to the Python interpreter. Presumably the first time a user tries to open a file with embedded Python code, or execute a Python script, Excel (or whatever application) would prompt for the location of the interpreter.

    4) I think the primary benefit of Python-as-an-embedded-scripting-language is not in performance, but rather in the higher-level abstractions. Specifically, because Python has a function-as-first-class-object mechanism, it enables a more succinct style of data processing (think LINQ).

Feedback and Knowledge Base