
Will VBA Die? (2019) - UkiahSmith
https://www.thespreadsheetguru.com/blog/are-vba-macros-dead
======
kevas
Nah... why should it? It works and it does what it needs to do and more if you
decide to hook into the Windows API or Mac’s API.

Want to parse 500mb structured XML file? Okay. Takes 3 seconds or so.

I had a lot of fun creating a full featured & modern look & feel application
using Excel’s VBA runtime as my platform. Sure... I had to create everything
from scratch, but learned so much while doing it. Kind of miss it at times
since I now work with Java.

By the time I moved jobs, the codebase was +30k lines and even built an auto-
updater, auto-installer, diagnostic, and AD type of authentication for the
app, but most importantly saved tens of thousands of hours by automating
reporting, analysis, detect errors, and querying that analysts, accounting,
and some BI’s would do as part of their normal work.

VBA is great for analysts to work in Excel all day & every day who want to get
into programming a little more, but want to have it apply directly to their
daily work.

Now.... I wish Access does die...

~~~
clausok
Your Excel+vba application’s features remind me of when I joined an investment
bank in 2000. I had come from an insurance company where I was considered the
Excel\vba wizard, and I was impressed, in the extreme, by my new colleagues’
approach to Excel development. Even during the interview process I had
realized that, when it came to vba, I was but a babe in the woods. They had
auto-updating code (when you “published” code, all client workbooks downloaded
the latest version), code-generated collection classes, interface inheritance,
tests, error detection, higher-level functions via Application.Run(), self-
contained worksheets with embedded vba code that would operate even if moved
to a new workbook.

Inevitably, new hires would be unhappy that they did, in fact, have to write
vba code all day and would argue for switching to a better language. Our team
manager would say, "Vba gives us a superpower no other language does: we can
deploy whatever we want, whenever we want, to whomever we want. In any other
language, getting 'Hello World' in front of a user is a six month project."

~~~
AdamM12
What would the role names be for positions like this at an IB? Been interested
in this type of work.

~~~
richardcrossley
Something called "Desk Developer", "Deskdev", "Rapid Application Development"
or "RAD".

I was in the Deskdev team in an investment bank for 4 years, great fun and I
learned a lot about Excel.

~~~
AdamM12
Ok cool. Thank you!

------
mschaef
It'd honestly be a shame if it did (but I understand the stresses that might
cause it to happen).

Flash back to ~1986, and Bill Gates wrote an article for a Byte magazine
special edition in which he described a unified version of BASIC implemented
across a suite of GUI productivity applications.

Keep in mind, this is before Windows 3.0 and the Microsoft hegomony, before
Word for Windows, (and Access, Project, Visio, etc.), before
OLE/COM/ActiveX/IDispatch, and all of which are arguably necessary to complete
the vision he outlined in the article. Ten years later, the vision of the
article was realized, and thirty-five years later, it not only still exists,
it's still useful across a huge cross section of computer users. (Despite the
radical changes in the industry over that time.)

Microsoft has gotten a lot of flack over the years, and a lot of it has been
earned, but the ability to identity a useful target state ten years in the
future and rally an organization to achieve that goal is an amazing
accomplishment.

------
dokka
I'm working on an excell addin right now. It doesn't use VBA (it uses
microsoft interop libs for .NET) And I have zero interest in using VBA, but I
will admit, it would have been much easier to do this project in VBA instead
of C#. Debugging would have been easier. I could debug inside the VBA code-
behind instead of Attaching to the excel process in Visual Studio. Deployment
would have been easier. I could make an .xlam file and just give it to the
users instead of A separate visual studio project that creates an installer on
each build. Excel interop would have been easier too(probably, I'm not 100%
sure.) But using the Microsoft.Office.Interop.Excel libs are kinda hard. I
don't have any good reference material for this lib, but for VBA, there are
tutorials all over the internet for doing common things. I mostly avoided VBA
because I prefer the syntax of C#. I would imagine most people that only know
VBA would have no interest in using C# to write office interop code, and I
don't blame them. As for javascript, I doubt anyone that knows VBA well would
have a hard time learning javascript, and if the codebehind for excel was
slowly migrated to that, most devs would welcome the change.

~~~
jbeam
I’m the other way. Started a large project in VBA once, jumped over to C#
interop and never looked back. I found the libraries to map fairly well to the
same named functions in VBA when it came to worksheet manipulation. My biggest
issue was that the interop has quite a bit of latency. You really want to
accomplish as much in one call as you can (i.e. read whole ranges into an
array instead of looping through cell by cell).

Edit: If this is internal, you can also set up one click deployment to some
folder on the network that will auto update the add on for end users.

~~~
non-entity
I was working on a small program that originally used the C# interop and found
the latency pretty bad as well. For a small document, it was taking like 4 or
5 seconds to do what we wanted (dont remember exactly what that was atm).
Eventually, I used some OpenXML library Microsft offered that was basically
LINQ to XML with some types / extensions and found something interesting:

On smaller documents, the OpenXML manipulation blew the COM interop out of the
water in terms of speed, but with larger documents (hundreds of thousands of
rows), I think the COM interop was either faster or at least just as fast.

------
cm2187
Microsoft should rather provide a better path toward office automation rather
than just frustrate users. As I have seen it, javascript isn’t even remotely
close to the sort of integration that made the success of VBA. Like how can I
save a javascript macro as a user? Javascript user defined function?

VSTA was a good attempt in its time, a mini visual studio integrated in office
with VB.net and C# instead of VB6. That would have been cool.

~~~
Ididntdothis
Agreed. JavaScript has no real upside here besides being fashionable. whereas
built-in C# with access to the .Net framework would be really powerful.

~~~
rosybox
JavaScript has a huge upside because a lot of people already know JavaScript.
The more tools and platforms switch to JavaScript the more of an office
superhero users are when they know something about the language. The
productivity of employees will jump off the charts. When you send someone to
train for one thing that utilizes JavaScript you get the benefit that those
skills may also happen to work with something else as well.

~~~
NeoBasilisk
At some point, I hope we can get past this argument. Learning a new language
for rudimentary tasks is not particularly hard. I'm not sure why people
decided that JavaScript of all things was what we had to all latch onto.

~~~
chaostheory
Because it’s the new Franca lingua of programming. Everyone knows it whether
they like it or not. There’s value in not have to switch context while
programming. Also there’s typescript which makes JavaScript usable. I don’t
like JavaScript either but typescript isn’t terrible and the ecosystem is much
bigger than any Microsoft programming ecosystem which results in less
reinventions of the wheel. MS has also been treating JavaScript as a 1st class
citizen on Windows

~~~
DaiPlusPlus
> MS has also been treating JavaScript as a 1st class citizen on Windows

Eh what now?

The ActiveSctipt host for JScript (for shell and Classic ASP scripting) hasn’t
been updated since Windows 2000, and for shell scripting in-general Microsoft
has been (“was” at this point?) pushing PowerShell since its demo at PDC 2003.

WinJS for Windows 8 was a huge waste of money for the company that people
always seem to forget.

And their Chakra JS engine is effectively now retired given Chromium+V8
replaced EdgeHTML earlier this year.

The only places Microsoft has been using JS are for their current set of
Electron-based applications (VS Code, Skype, MS Teams, Azure Storage Explorer,
etc). TypeScript is nice and all (and I really love it and I hope it brings
algebraic typing and structural typing to more languages) but it’s only
popular because Google, of all people, adopted it for Angular.

------
HenryKissinger
As long as Excel is used by businesses, VBA will be relevant. Excel will
probably continue to exist - and be supported and updated to ever newer
versions - forever, so it stands to reason that VBA will probably also exist
forever. Unless Microsoft goes bankrupt and Excel isn't picked up by another
company. Which will also probably never happen.

~~~
chaostheory
Microsoft is slowly transitioning Excel macros to Javascript / Typescript. It
will happen eventually.

~~~
mschaef
The Excel object model is really a COM/IDispatch object model... it's been
accessible from non-VBA applications essentially since the beginning.

Not Excel, but one of my first consulting projects was at a company that
developed some custom libraries in Java and for a company that used ASP for
the front end. The architecture we used ran the Java code in the Microsoft
JVM, which then made Java accessible via IDispatch (and therefore by ASP's
scripting engine).

IIRC, we were doing stuff similar to this:

    
    
        let javaObject = CreateObject("java:com.company.library.ApiClass")
        
        print javaObject.version
    

This is essentially a part of the 'embrace and extend' functionality that MS
added to Java and got sued by Sun over. (There were also mechanisms for
relatively easily calling into Windows from the MSJVM too... it felt an awful
lot like the Proto-CLR that it was.)

~~~
bilekas
At the moment the implementation is to basically inject code, but I imagine
eventually Microsoft would like to move away from that.

Issues like DCOM and legacy systems would need some interface from Microsoft
of course to handle IDispatch, GC etc, but thats what Microsoft do.. And to
behonest, as much as I like to rip on them, they do it well.

Edit: I think the Java example is a little bit different, but i don't know
anything about Proto-CLR!

~~~
pjmlp
Have a read about Ext-VOS here.

[https://blogs.msdn.microsoft.com/dsyme/2012/07/05/more-c-
net...](https://blogs.msdn.microsoft.com/dsyme/2012/07/05/more-c-net-generics-
research-project-history-the-msr-white-paper-from-mid-1999/)

"Project 7 and .NET Generics"

[https://fsharp.org/history/hopl-draft-1.pdf](https://fsharp.org/history/hopl-
draft-1.pdf)

WinRT, as it was originally designed, traces its ideas back to that Ext-VOS
project, but going back to COM as they were thinking about it back then.

[https://docs.microsoft.com/en-us/uwp/winrt-cref/winrt-
type-s...](https://docs.microsoft.com/en-us/uwp/winrt-cref/winrt-type-system)

------
thanatropism
There's really two camps of VBA, the "application builder" and the
"spreadsheet functionality" camps.

Application builders are trying to build interfaces for things that will run
in a non-spreadsheet (i.e. non-reactive, not always-recalculated-to-be-
consistent) mode. That's bound to be brittle, because that's not what Excel is
for.

Spreadsheet functionality extending people OTOH write almost 100% what in
ordinary programming is known as "pure functional style". Too often to write
complex formulas in Excel (even something as simple as the Black-Scholes
equation) people have to use multiple cells to keep things tidy and
debuggable. You can use VBA functions for that. You can also write short loops
to "solve for zero" with the bisection or Newton method etc. as long as they
don't run for long. None of that interferes with spreadsheet semantics.

------
unnouinceput
Quote: "What Will Replace VBA? Short answer: JavaScript. "; and author follows
with some logic about JS vs VBA using cross-platform.

Except this will never happen:

1 - M$ loves backward compatibility. It's what keeps their software being sold
all these times. Worse case JS will have bigger user share and that's it, but
M$ will never cut VBA out.

2 - Also majority of business is done on Windows. Cross-platform means
absolutely nothing to corporations. The day that Windows dies that's the day
VBA will die as well.

3 - JS as golden boy vs VBA? pleease. Best case scenario you're switching from
one ugly boy to another ugly boy. Both VBA and JS are horrors. Don't believe
me? Go read'em horror stories about JS cross browsers implementations. JS
solved the problem of cross-platform only to open the problem of cross
browsers. Good luck having Apple implement the same JS in Safari as their
mortal enemy from Google in Chrome.

~~~
bilekas
1) They are paid to support their own tech, when they drop one (Silverlight
for example) it can be a serious hit for a buisiness.

2) Yes, but it is changing thanks in part to dotNet core understanding this
too. So we should see some benefits across the board for everyone.

3) Well, like PHP back when it was the golden boy against Perl, it's up to the
developers to decide the direction of the language itself. Browsers and Node
are big players to influence that too, but M$'s interest bringing TypeScript
for example is evidence they might believe that.. Also as for standards, I
might be wrong but I think they now decide their own standards, with all the
browsers as members ?

~~~
Wowfunhappy
> They are paid to support their own tech, when they drop one (Silverlight for
> example) it can be a serious hit for a buisiness.

...but you _can_ still download and run Silverlight.

Fun fact: if you load up Netflix in a browser that's too old to support the
html5 player, they'll prompt you to install the Silverlight plugin.
[https://help.netflix.com/en/node/23742](https://help.netflix.com/en/node/23742)

------
markus_zhang
Excel is one of the reasons I want to leave a career of Business Analyst
behind.

Regardless of the process, the last step is always to dump the data into Excel
and spend tons of time to create good-looking charts and tables. It usually
takes me a full day to do that plus write wiki pages in Confluence (another
pain point).

I just want to stay away from spreadsheet -> which means I need to get further
from business and get a more technical position.

~~~
dswalter
I think you may find R an excellent tool/ecosystem for that kind of work.

~~~
markus_zhang
I'm actually trying to break into BI or DE, so Python is my first choice. I
also have some experience with C++ but it is not that useful for corporate
development nowadays.

------
__app_dev__
Ha - good timing! I've been using VBA today and yesterday actually!

Often only a few times a year I use it now but when I do it I feel productive.

In case your wondering I has a previous Excel VBA Macro that I wrote for
updating a SQL Server Database based on data in Excel. The macro first has to
run checks against data in an IBM AS/400 Database.

I ended up having to pull out the macro to do a bulk update in an ERP. It was
faster to do this then re-write in an modern language (especially since I work
with the data in Excel first).

------
smitty1e
Some points:

* I guess with Office365, JavaScript makes some sense, but why not just go VBA to WebAssembly?

* What about the Python rumors a couple years ago?

* I should probably turn my NecroVisualBasiCon library into A book. If you use the Access.Application library, right-click and toggle the hidden members, that COM object has a few extras like loading/saving objects from the VBProject that make e.g. git integration feasible.

* VBA does an outstanding job of providing 80% of what you want and no more.

------
mnm1
My first apps ever were extremely customized VBA Access databases. I already
knew QBasic so doing VBA was easy. It affords a ton of power. I was able to
create an entire interface and workflow easily and have everything contained
within one Access file. The only downside was when multiple users wanted to
use it (I think one had to save/close to let another in). For small things (a
workflow tracking a university's scheduling changes) it can be great.
Filemaker is a similar tool and both tools allow rapid development and
prototyping. It might not be that useful to seasoned programmers, but to
people who just want to get something done quickly, and especially for people
who don't program much, it's an amazing tool.

------
animalnewbie
I wish Microsoft would just make a CSA already, c# for apps. This would be a
huge win on so many fronts that I am shocked they havent done it already.

Increase C# mindshare.

Better Lang means a better ecosystem.

It's a free win.

It's also an ad for office. I started appreciating Outlook and Excel once I
had vba filters and maps

~~~
flomo
Very surprised after all these years (decades?) they have not done something
like this. Basic has been a low priority at MS for a long time now.

~~~
tonyedgecombe
It could have made for an interesting alternative to PowerShell as well.

~~~
animalnewbie
Not a PS1 expert by any means but you have to spend some time with it to
appreciate the design decisions. It's a very "wholesomely" designed language.

Try eg. The for each parallel construct which made me realize why the output
in PS1 behaves how it does.

~~~
tonyedgecombe
That's always been the problem for me, I don't use it often enough to become
fluent with it.

~~~
animalnewbie
You're missing out. As a full time Linux user (since a year), PowerShell is by
far the best shell out there (once it starts after 5 secs)

~~~
tonyedgecombe
I'm not going to start using it for the sake of it. Some tools I just dip in
and out of when I need to. Build software is the same, I haven't modified my
build scripts for a year.

------
dntbnmpls
VBA won't "die" anytime soon for the same reason Office or VB/VB.NET are still
around. Legacy code. Almost every office in the US and probably around the
world has VBA code in one of their office products ( excel, access, etc ).

Google spreadsheets was going to kill Excel, C# was going to kill VB, Sql
Server was going to kill Access, etc. Look at how that turned out?

Maybe in an ideal world, but in the real world, there is a ridiculous amount
of time, money and resources invested in VBA code. These sunk costs are very
meaningful to corporations and governments and as long as corporations and
governments give microsoft huge stacks of money, microsoft is going to keep
VBA around.

------
mlazos
I don’t think it will. Microsoft might add another macro language but everyone
is obsessed with backwards compatibility at MS and I highly doubt they would
remove something as widely used as this. I used to be really annoyed by this
as an engineer, but in contrast to Google’s culture where products are
shutdown all the time I’ve started to come around that users should come first
to avoid getting this reputation, even if it does become a combinatorial hell
of different versions. I work at MS so I’m biased probably

------
gliese1337
As far as I'm concerned, JavaScript (or at least JScript, MicroSoft's
proprietary reimagining) replaced VBA 13 years ago. I haven't had to do
anything programming with Excel for rather a long while, but way back in 2007
I was already writing JScript programs to automate spreadsheet tasks.

------
zchrykng
I hate VBA with a passion, but on the other hand it saves me many many hours
every month through my ability to automate tasks. I would love for almost any
language to replace it, but there has to be some kind of replacement if it
goes away.

------
A4ET8a8uTh0
Between the spread of excel across businesses and MS focus on compatibility it
seems rather unlikely. It is kinda ridiculous how much depends on VBA macros.

Weirder things have happened, but whatever would replace it, would create an
industry overnight.

------
tombert
I don't own a Windows computer, but I've seen some incredibly interesting
stuff come out of the VBA for Excel, which I sadly never have had a chance to
learn.

Does anyone here have a side-by-side comparison of the LibreOffice BASIC vs
the VBA?

~~~
stan_rogers
The main difference will be the object models for the various applications.
LibreOffice's object model was designed around the expected
scripting/automation language - Java. That means that the object model,
especially the properties and methods of those objects, is written in a very
Java-accented way that would normally feel like foreign vocabulary mixed into
a Visual Basic-based dialect. If you're used to that, then the way objects
work in VBA (or the very similar Lotusscript) might feel a little bit weird at
first, then make more sense than the LibreOffice objects/properties/methods.
(Similarly, writing Java against a COM- or OLE-oriented API object model feels
awkward, even if you can do all of the same things that you could do with
VBA.)

------
ptx
> one of the easiest coding languages to learn if you don’t have a computer
> science background

Really? A language that has values passed by value, values passed by
reference, references passed by value and references passed by reference? (And
both late and early binding, and auto-boxing with all kinds of mysterious
type-conversions, etc. and so on. And default properties.)

What makes it easy for beginners is the integrated environment, which is also
what makes it difficult for more experienced programmers as it doesn't
integrate with their version control system and other common tools.

------
codegeek
If traders/quants and financial analysts in banks say that they don't need VBA
anymore, sure it will die. Otherwise, not a chance. Trust me.

------
pix64
Not sure why they wouldn't go something C#/.NET based. If you're going to go
the JavaScript route, at least pick TypeScript.

~~~
andybak
Whatever your position on the static typing debate surely one of the sweet
spots for dynamic languages is casual use by non-professionals?

~~~
Ididntdothis
C# has a dynamic runtime. In that sense it's very similar to VB with can also
be strongly typed or dynamic.

------
kilon
Well judging from the fact that my first computer my father bought back in
1988 Amstrad CPC 6128 is still alive and kicking with very active community
and more development tools than it ever had, I think its safe to assume that
software never dies. Only thing it takes is a small dedicated community and it
can last for centuries. Partly because father and mothers infect their sons
and daughters with their passion for the technology and the the loop never
ends. What else never dies is necrophilia in software , apparently people are
addicted to declaring software dead prematurely. Oh and of course clickbait
because some people are desperate for views. It started with Java back in to
2000s and still going strong. I am not fan of Java but I am also not that
delusional to declare Java dead. So no I think its pretty safe to assume VBA
is not going anywhere.

------
_bxg1
It's weird to me that we haven't settled on a common, stable, purpose-built
high-level language specifically for business logic. Stuff that doesn't change
much, that doesn't need to concern itself with the platform, only the
business. That code should be portable to whatever shiny new underlying system
gets invented; why does it keep having to be re-expressed every few years?

The situation is much better (though still far from ideal) when it comes to
data. Everything knows how to use CSVs. Relational databases, from a schematic
perspective, really haven't changed terribly much in decades. NoSQL came
around but that was really just an alternative option; you don't see everyone
scrambling to migrate their SQL data to Mongo. SQL isn't quite a standard, but
it would be dramatically easier to migrate an ancient MS SQL database to
Postgres than an ancient COBOL codebase to Java.

~~~
michaelmrose
The great thing about standards is that there are so many to pick from.

What is the difference between what you are imagining and Java or python?

~~~
_bxg1
I guess I'm talking about a domain-specific language. Something where you only
articulate business processes and formulas, and nothing more. Java and Python
are _programming_ languages. You use them to tell a computer what to do.
Whereas this would be a _representation_ language. You'd be able to carry that
representation around with you and drop it into different programming
contexts.

~~~
alexisread
You should look at Sqlite, not just as a portable business environment, but as
a data format and deployment format.

------
bitxbit
Imagine Excel with Python.

Edit: I believe Libre has python.

~~~
warpech
[https://www.xlwings.org/](https://www.xlwings.org/)

~~~
thanatropism
I made some code using xlwings to allow you to emulate spreadsheets with
machine learning models à la scikit-learn.

[https://github.com/asemic-horizon/stanton](https://github.com/asemic-
horizon/stanton)

------
tracker1
JavaScript, for better or worse, is probably the most widely used language out
there, by nature of being the language in the browser. The push for cross
platform, mobile and web with frameworks that leverage it have leaned in on
and expanded JS greatly. The engines are highly optimized (more than any other
scripting language as feature rich), cross platform and nearly ubiquitous.

VBA just isn't. Anything not JS is just about a non-starter for the web
versions of these applications, and that's where things are headed. If you're
on Linux it's probably the only option in the space for a while.

JS is pretty decent, the ecosystem is massive, and you have the option of
TypeScript if you want something more formal. Guessing everything MS offers
will actually be written in TS, just consumable in plain JS or TS.

------
dmix
Reading the replies to this post, the title is most certainly click-bait and
not encouraging deep discussions.

------
disposedtrolley
I have a soft spot for VBA. Programming macros in Excel was my introduction to
programming; it made me realise how simple it can be to automate a repetitive
process and save yourself literally hours a day with just a small investment
of time.

------
dfox
I still think that original Excel macro language was better than VBA. It
essentially excel's formula language extended to be imperative language and
represented as sheets. At the same time it was user friendly and had kind of
lisp feeling.

------
wolrah
If there's one thing I've learned in 15 years of IT work, it's that once
business users have discovered a thing it will never die.

No matter how outdated, shitty, useless, etc. it may be, some jackass has
built their entire workflow around it and has more power than you to prevent
that from ever changing.

------
senderista
VBA was my entree into professional programming and I'm not ashamed to admit
it. I enjoyed using BASIC to solve my own problems (games) as a kid, but VBA
showed me how fun it was to solve other people's problems.

------
jerry1979
VBA will "die" (in the same way fortran is dead) when people can record macros
in another language, and then keep those macros baked into xlsm files.

------
phendrenad2
Hopefully not. It's withstood the test of time, why replace it with something
trendy?

Edit: Yes, Python has also withstood the test of time... as a scientific and
web language. There's no reason to assume that it could replace VBA as a
spreadsheet automation language used by relatively non-technical business
folks.

~~~
andybak
Python is widely regarded as a very good first language for non-programmers.

------
buybackoff
With ExcelDna, which is open source .NET library, has very fast C API and rich
COM API, I don't know why one would use VBA for new dev. One commenter here
said debugging of interop libs is hard, but my experience is quite opposite -
it works nice from Visual Studio with normal F5.

------
boshomi
Microsoft will probably port VBA to WASM. With the mass of all MS Office dll
involved, this can grow huge.

------
StreamBright
VBA was the first environment/language that I professionally used at the
beginning of my career. It was so efficient to navigate in an environment that
had 1000s of Excel files. I did not realise how fast I could develop the
things needed to be done.

------
wernercd
Short answer? No. Just like COBOL and fortran. With us until the heat death of
the universe.

------
samfisher83
One of things that at least the old Microsoft was really good at was backward
comparability.

~~~
sn_master
Did they break that recently ?

~~~
Ididntdothis
They keep compatibility but abandon a lot of stuff. If they switch to
JavaScript VBA development will slow to almost nothing and it will take years
for the JavaScript stuff to catch up, if ever.

Something similar happened with visual studio. 2008 was really nice, very
customizable and fast. Then they redid everything in 2010 and the result was
slower with way less capability. And even now there are still a lot of
features that 2008 had not implemented.

~~~
atesti
I also love vs2008 over vs2010 and still use it for some projects just because
it feels so nice and snappy.

But which features exactly are missing in vs2010 that were in vs2008 (except
the snappy feeling)? I have not actually noticed anything missing and would
like to know more

~~~
Ididntdothis
2008 had an excellent macro recorder which was gone on 2010. 2008 had an easy
way to customize toolbars and menus by drag and drop. With 2010 setting up a
toolbar is much harder. There were a few other things but I don’t remember
right now.

------
stormdennis
If they killed it today, then if VB6 is anything to go by, it will still be
chugging along unconcernedly in 2050. VBA was a huge component of VB6, so it
would be relatively easy ( I think) for MS to produce a 64 bit VB7.

------
NoPicklez
Depends on what you're using VBA for, it is for Excel data processing or
analytics. IMO it will likely die out, there are much better data solutions on
the market for data analytics that use python.

------
vxNsr
I can relate to every single point he makes about how great VBA is compared to
other languages and how annoying it is that MS has basically abandoned it in
favor of JS.

------
marcosdumay
As any single provider language, VBA will die on the moment Microsoft decides
to kill it.

They don't seem to be in that mood, so no, not today.

------
grma1
this will definitely will be a huge relief for many sys-admins in windows
environments... I think javascript isn't a bad choice since ms isn't as
ignorant as some years ago, when it comes to new standards.

------
pjmorris
Hey, hey, my, my, VBA will never die.

The real question is whether VB6 will ever die.

------
musicale
TL;DR: No, or at least not anytime soon (author guesses 2035.)

------
anonsivalley652

        10 PRINT "Nope"
        20 GOTO 10

------
skittleson
No, it will not.

------
LilBytes
Betteridge's law of headlines rings true.

~~~
gauravjain13
Will VBA live?

------
pgt
Betteridge’s Law says no.

~~~
mc3
COBOL's Law also says no.

------
ShakataGaNai
As it is 2020 and VBA still exists. No.

~~~
dang
We've taken 2019 out of the title above since if there's anything interesting
about the article, it's not that.

