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.
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."
This is so cool. VBA is a gateway drug, for sure. It was my first foray into programming, specifically to solve a problem I knew I could formulate as a shortest path problem. That's led me on quite a journey.
The only thing I wish they'd do is update the editor. I like that it feels responsive, I just don't like the lack of line numbers and themes.
Problem is that VBA in its current shape doesn't work for webbased Excel. Microsoft started with attempting to support Javascript based add-ins [0].
However, they those are of course light years behind in terms of API support. Never even mind that on the desktop Excel the javascript runs in the Internet Explorer engine (of all things, not even the EdgeHTML engine).
However, it would take a lot of effort to maintain that 30K+ lines of VBA application. But I think that's because the infrastructure at that time was archaic. If it's today you would probably ditch Access for SQL Server and build reports with something more modern.
But it doesn't have to be VBA. Any language with a decent OLE Automation library would suffice. I've been using Python to automate my Excel files, and am really happy about that. I tried to learn VBA, but could not adapt to its archaic syntax and the clunky VBA editor that comes with Excel.
We still have Access/Filemaker in use. Just as a frontend, but still. There could be something better, but often there just isn't. Some turned their Access apps up to eleven, with maps integration for navigation, address completion, automatic correspondance functions, automatic dashboarding for different departments... some are even more advanced than the latest stock CRM/ERP solutions from known developers.
There certainly would be a better solutions, but reimplementing some of those apps would take months or even years of development time. Completely crazy.
I know many non-technical people love VBA because it empowers them to do cool things, especially in Excel. However, there is a no smaller number of people who view VBA as a necessary evil, because they are forced to do programming and they are not programmers. It's also well-known that VBA macros written by non-professional programmers tend to become a cumbersome, unreadable, unmaintainable mess. My favorite case is when VBA is used to insert complex multi-line formulas in a spreadsheet, run calculations, then do it again with another set of formulas.
I believe, VBA will remain as a general purpose language for long time, but it will be partially replaced by tools that are purpose-built for tasks such as data preparation. We've seen it with EasyMorph (https://easymorph.com), a visual data preparation tool we've created exactly for heavy Excel users without a technical background. It works very well for them and we get a lot of praise for it. If this approach works for data preparation, probably it will work for other types of automation too.
The company I work for just moved all automated bookkeeping and analysis into R scripts (running automatically), completley ditching office and Microsoft.
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.
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.
> 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.
I'd be happy to use C# but it's so god damn hard to learn those libraries.
The biggest disadvantage in using VBA is speed – not to mention the idiosyncrasies of the language itself, which can make complex code rather painful.
Writing a .xlam addin is easy, except there's no tooling for creating "builds".
On a separate but related note, since writing XML for the ribbon by hand is so annoying (and you also have to write callback wrappers for each Sub you want to expose) I have actually written a python tool that parses annotations from comments in .bas files in a given folder and spits out a .xlam file. Haven't gotten around to publishing it but if folks are interested I can give it a little oomph and finish in the next few weeks, so lmk
There is so much of this I can relate to, I have worked with legacy systems too and have been fortunate in a sense to have to drill into someone else's VBA and thankfully there were people there to run me through those strangeness of it.
While I don't think it needs to continue, I believe it's been replaced in all aspects to date.. I do think that there is a requirement for a knowledgeable person to at the very least lead the re-write.
> 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.
One of the main points of contact for my VBA adventure picked up vanilla javascript super fast, and within a few weeks he was already explaining how it could be made semi strongly typed, he introduced us then to a newly formed TypeScript subset and we never looked back.
It's not a language issue, its an understanding issue, give a good engineer/developer/hacker any language and they will figure it out and know how to make it work.
That said, if I ever see VB again, I will still shed some salty tears.
One thing to consider, which I've found powerful, is a hybrid approach where you use vba for what it's best at -- interacting with the Excel object model -- and have the vba load and call a C# xll that leverages the .Net libraries and does all the work that would be tedious to do in vba. For your users, they would simply open a "host" .xlam file, which is the only one they would be aware of, and this file would load additional .xlam or xll files and typically also check for updates to these files. No installer necessary.
For example, your vba code would pick up a range of index (or ETF) tickers from a sheet, use Application.Run("lib.constituents") to call a C# function that pulls the stock tickers and weights that represent each indices' constituents, your vba code would receive back an array of arrays and use Excel's row grouping feature to group the members & weights under the parent index and perhaps add some formatting and\or formulas.
The advantage of this division of labor is that you get faster dev & debug feedback loops within your Excel-centric code, while minimizing the amount of time you spend working in a dev environment that has stood still for 20+ years as others have raced far past.
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.
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.
I think there's a different focus with JS vs VBA or C#. JS is the future because of Office365 ie. Cloud/online apps are the future.
I don't think C# integrates with the o365 codebase, but I'd consider both JS and C# as attempt to move people to good dev practices, C# with IDE/versioning/debug etc and JS with the approach of funneling data in and out of excel eg. Cloud compute, and then using excel for basic functions that don't involve using macros etc.
VSTO to the best of my knowledge is still a thing. And you could indeed do some pretty cool stuff with it!
But it's not as easy to use as VBA, nor was it incredibly easy to work with from a development standpoint when I last tried to use it (Maybe I was doing it wrong, but I had to do a full VS install with the add-in module.)
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.
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.
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 ?
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.
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.
* 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.
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.
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
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).
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.
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.
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.
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?
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.)
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
It's just too much effort for nothing. People using VBA for automation pretty much live in the ecosystem of MS Office so it's not a big win for them. Plus MS has to spend huge sum of money to incorporate C# into Office.
Yeah, and considering that the .NET 5 runtime will run in WebAssembly this is quite interesting. Maybe they are porting VBA libs to .NET. Then C# and VB.NET can pick up.
Or they do the real deal: Port VBA to .NET ... that however, would be a little bit difficult to explain with VB.NET in place as well ;)
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.
kevas|6 years ago
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|6 years ago
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."
CinchWrench|6 years ago
The only thing I wish they'd do is update the editor. I like that it feels responsive, I just don't like the lack of line numbers and themes.
sebazzz|6 years ago
However, they those are of course light years behind in terms of API support. Never even mind that on the desktop Excel the javascript runs in the Internet Explorer engine (of all things, not even the EdgeHTML engine).
[0] https://docs.microsoft.com/en-us/office/dev/add-ins/excel/ex...
markus_zhang|6 years ago
jmnicolas|6 years ago
yokohummer7|6 years ago
raxxorrax|6 years ago
There certainly would be a better solutions, but reimplementing some of those apps would take months or even years of development time. Completely crazy.
dgudkov|6 years ago
I believe, VBA will remain as a general purpose language for long time, but it will be partially replaced by tools that are purpose-built for tasks such as data preparation. We've seen it with EasyMorph (https://easymorph.com), a visual data preparation tool we've created exactly for heavy Excel users without a technical background. It works very well for them and we get a lot of praise for it. If this approach works for data preparation, probably it will work for other types of automation too.
ourlordcaffeine|6 years ago
mschaef|6 years ago
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|6 years ago
airstrike|6 years ago
I'd be happy to use C# but it's so god damn hard to learn those libraries.
The biggest disadvantage in using VBA is speed – not to mention the idiosyncrasies of the language itself, which can make complex code rather painful.
Writing a .xlam addin is easy, except there's no tooling for creating "builds".
On a separate but related note, since writing XML for the ribbon by hand is so annoying (and you also have to write callback wrappers for each Sub you want to expose) I have actually written a python tool that parses annotations from comments in .bas files in a given folder and spits out a .xlam file. Haven't gotten around to publishing it but if folks are interested I can give it a little oomph and finish in the next few weeks, so lmk
bilekas|6 years ago
While I don't think it needs to continue, I believe it's been replaced in all aspects to date.. I do think that there is a requirement for a knowledgeable person to at the very least lead the re-write.
> 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.
One of the main points of contact for my VBA adventure picked up vanilla javascript super fast, and within a few weeks he was already explaining how it could be made semi strongly typed, he introduced us then to a newly formed TypeScript subset and we never looked back.
It's not a language issue, its an understanding issue, give a good engineer/developer/hacker any language and they will figure it out and know how to make it work.
That said, if I ever see VB again, I will still shed some salty tears.
clausok|6 years ago
For example, your vba code would pick up a range of index (or ETF) tickers from a sheet, use Application.Run("lib.constituents") to call a C# function that pulls the stock tickers and weights that represent each indices' constituents, your vba code would receive back an array of arrays and use Excel's row grouping feature to group the members & weights under the parent index and perhaps add some formatting and\or formulas.
The advantage of this division of labor is that you get faster dev & debug feedback loops within your Excel-centric code, while minimizing the amount of time you spend working in a dev environment that has stood still for 20+ years as others have raced far past.
jbeam|6 years ago
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.
nikanj|6 years ago
cm2187|6 years ago
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|6 years ago
alexisread|6 years ago
I don't think C# integrates with the o365 codebase, but I'd consider both JS and C# as attempt to move people to good dev practices, C# with IDE/versioning/debug etc and JS with the approach of funneling data in and out of excel eg. Cloud compute, and then using excel for basic functions that don't involve using macros etc.
to11mtm|6 years ago
But it's not as easy to use as VBA, nor was it incredibly easy to work with from a development standpoint when I last tried to use it (Maybe I was doing it wrong, but I had to do a full VS install with the add-in module.)
HenryKissinger|6 years ago
chaostheory|6 years ago
unnouinceput|6 years ago
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|6 years ago
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 ?
thanatropism|6 years ago
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.
mnm1|6 years ago
smitty1e|6 years ago
* 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.
markus_zhang|6 years ago
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|6 years ago
mlazos|6 years ago
__app_dev__|6 years ago
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).
gliese1337|6 years ago
zchrykng|6 years ago
A4ET8a8uTh0|6 years ago
Weirder things have happened, but whatever would replace it, would create an industry overnight.
tombert|6 years ago
Does anyone here have a side-by-side comparison of the LibreOffice BASIC vs the VBA?
stan_rogers|6 years ago
ptx|6 years ago
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|6 years ago
pix64|6 years ago
andybak|6 years ago
_bxg1|6 years ago
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.
KineticLensman|6 years ago
michaelmrose|6 years ago
What is the difference between what you are imagining and Java or python?
marcosdumay|6 years ago
But current programs are 99% incidental complexity that it won't help solving, so programmers tend to avoid the language.
kilon|6 years ago
tracker1|6 years ago
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|6 years ago
dfox|6 years ago
wolrah|6 years ago
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.
disposedtrolley|6 years ago
senderista|6 years ago
unknown|6 years ago
[deleted]
jerry1979|6 years ago
phendrenad2|6 years ago
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|6 years ago
buybackoff|6 years ago
boshomi|6 years ago
StreamBright|6 years ago
wernercd|6 years ago
samfisher83|6 years ago
sn_master|6 years ago
stormdennis|6 years ago
NoPicklez|6 years ago
vxNsr|6 years ago
marcosdumay|6 years ago
They don't seem to be in that mood, so no, not today.
grma1|6 years ago
pjmorris|6 years ago
The real question is whether VB6 will ever die.
musicale|6 years ago
anonsivalley652|6 years ago
skittleson|6 years ago
LilBytes|6 years ago
gauravjain13|6 years ago
pgt|6 years ago
unknown|6 years ago
[deleted]
mc3|6 years ago
animalnewbie|6 years ago
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
markus_zhang|6 years ago
And we already have VSTO.
oaiey|6 years ago
Or they do the real deal: Port VBA to .NET ... that however, would be a little bit difficult to explain with VB.NET in place as well ;)
flomo|6 years ago
dntbnmpls|6 years ago
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.
bitxbit|6 years ago
Edit: I believe Libre has python.
warpech|6 years ago
estebank|6 years ago
https://youtu.be/u6EV2jiKRfc
ShakataGaNai|6 years ago
dang|6 years ago
unknown|6 years ago
[deleted]
Gusen|6 years ago
[deleted]