8 ms·

I love VBA, it’s so easy and powerful. My first job was being a developer/consultant at a big 4 firm, developing a disclosure management software with VB6. It e

by richx 6y ago

I love VBA, it’s so easy and powerful. My first job was being a developer/consultant at a big 4 firm, developing a disclosure management software with VB6. It even had a ORM to map objects from SQL queries. It was lightning fast, Office integration so superb. Later it was ported to .NET with a proper client/server architecture, still it never reached the speed and simplicity of the VB6 version.

foepys 6y ago
People are downvoting you but are overlooking the fact that it's not always about making things in the newest tech but more often than not about making things work. Most software will only be seen by industry specific users that don't care that the program is React Native and runs on AWS. A simple VBA script is sometimes completely sufficient to input the data into a spreadsheet. Scott Hanselman called devs doing this "Dark Matter Developers" [1]. 32bit VB6 programs are still able to run on modern Windows 10 machines, even on x64. The hours that would've been lost on porting everything to the newest macOS can be spent on new features or customer wishes. With the .NET Framework it's even possible to seamlessly use VB and .NET in the same program which combines old and modern technology. It's officially unsupported but it works and even gets bugfixes sometimes. 1: https://www.hanselman.com/blog/dark-matter-developers-the-unseen-99 https://www.hanselman.com/blog/dark-matter-developers-the-un...
- bgroat 6y ago
  I don't want to say "anti-pattern" because that's not what I mean... But new tech should be the last resort. If nothing stable, decades old, and well documented can solve the problem then reach for hot new-ness
  - Retric 6y ago
    That’s a little far, old doesn’t mean good. The bleeding edge often gets abandoned, but tech has generally been improving over time. IMO, the sweet spot starts when something was a fad ~5 years ago and is still reasonably popular.
    - DaiPlusPlus 6y ago
      > IMO, the sweet spot starts when something was a fad ~5 years ago and is still reasonably popular. That would mean it's okay to use Angular today, but dev trends (and Google's support "policy") would advise against that.
      - yen223 6y ago
        A good reason to wait a few years is precisely so that we have a clearer picture of what strengths and deficiencies a piece of tech brings to the table, especially out in the real world. We have a good picture of how Angular and React works in production now. We cannot say the same for something like Svelte.
        fpoling 6y ago
        React is far from being stable. It deprecated a lot older API, added entirely new concept of hooks. If one wants stability, then PHP has a way better track record.
        scrollaway 6y ago
        Nonsense. React is extremely stable. It indeed added hooks, deprecating exactly nothing in doing so. React deprecations are very few and far between.
        DaiPlusPlus 6y ago
        > deprecating exactly nothing in doing so De jure deprecation, correct - but reading between the lines in Facebook's own blog article that introduced Hooks ( https://reactjs.org/docs/hooks-intro.html https://reactjs.org/docs/hooks-intro.html ), which put a bit too much emphasis on "There are no plans to remove classes from React.", which to me means they're definitely going to be deprecating class-based controls in the future.
        6y ago
  - nicoburns 6y ago
    > If nothing stable, decades old, and well documented can solve the problem then reach for hot new-ness I think it's a little more nuanced than that. Usually the older technology is more stable and better documented. But not always. Sometimes the new hotness is the new hotness precisely because it's better in these kind of categories.
    - bgroat 6y ago
      You and Retric are right. I'm imagining a checklist of: - Stable - Well Documented - Age In descending order of importance. When choosing between any technology choose the one that is most stable. If multiple options are on a stable release, choose the one that is best documented. If multiple stable releases have excellent documentation, choose whichever is oldest. I don't think this framework is always (or even often) right. But it works for me
      - makapuf 6y ago
        My checklist would be (I'm eager to know other people correct me) suitable (does it some my needs) , stable, available (including documentation, live q&a resources like stackoverflow, blog posts explaining how- not new ones but existing and up to date regarding the version available), and simple.
        josephg 6y ago
        I try to adapt my checklist to the problem at hand. Sometimes I'm making something as a hobby project, or to solve a problem right now. Sometimes I want to write code that will outlive me, and sometimes I'll just throw some code at the wall and call it done. Each situation necessarily results in different priorities and tools. I wouldn't TDD a gamejam project, and I wouldn't start a multi-year project in zig - at least, not yet. For infrastructure projects I want well written deps which are simple, easy to use and have good documentation. When I'm evaluating something I often read bits of its source code (eg to figure out how to do something not listed in the examples). You get a sense of where to put things that way - actix (the actor library, not the web library) is very carefully designed, but seems to go a bit overboard inventing new concepts (+ associated traits). Tide feels pragmatic - its a bit sloppy with allocations, but it doesn't seem to really care. It wants to be fast enough and good enough while being simple to use. For hobby projects I like to follow my nose and pick whatever seems shiny. Over the last few years I've learned svelte, typescript, snowpack, rust (and some rust libraries), zig, wasm and other stuff. I like to make some risky bets and then just play the hand out and see what happens. And I use that as fuel for when I make longer term projects. I'm making a little database at the moment and I'm using rust - which is much slower for me to write (compared to nodejs) but it matches the values of the project I'm working on to a tee.
  - mattmanser 6y ago
    The MVC and ORM revolutions are the counter-argument to this. Rails/Django, then ASP.Net MVC/Laravel/whatever Java was was a massive step forward. If you didn't use it, you were hamstringing yourself. People switched to Rails in droves. As were using ORMs. You'll still get people quibble about this, but never having to go through the tedium of updating 101+ SQL statements when you add a column in a pain you young'uns will never know... JQuery was actually another example. Cross browser Ajax statements were annoying, plus just manually adding individual HTML nodes in HTML was laborious.
    - valenterry 6y ago
      ORMs are not the only way to avoid/solve the problem of having to update many SQL statements. People complain rightfully about them.
    - pjmlp 6y ago
      I have not seen people switching to rails in droves over here, it was a fashion wave that came and went. Apparently they are all now learning Elixir after a short migration wave over to Clojure. C++, Java and ASP.NET over here for the last 20 years.
- smitty1e 6y ago
  I've never ever tried VBA.Net. But my private NVBC (NecroVisualBasiCon) repo has some great stylings that I tap into at least once a year. Nevertheless, when are they going to relase Office with Python bindings included?
  - JJMcJ 6y ago
    Not exactly Python bindings but there is a package called Xlwings that provides a Python<->Excel interface. Somewhat clunky and slow but it does work.
  - jussij 6y ago
    One minor correction which is there is no such thing as VBA.Net. There are basically three VB ecosystems. Visual Basic which many refer to as VB6 and it represents the last version every released. VBA which is Visual Basic for Application and lives on to this day as an embedded language for Microsoft products like, Word, Excel, Outlook etc. VB.Net which is an implementation of the Visual Basic language running on the .Net Framework.
    - tonyedgecombe 6y ago
      There was also VBScript, one of the two active scripting engines shipped with Windows and available from IE and WSH.
sokoloff 6y ago
My frustration with VBA is that it didn’t seem very well documented. If I could record a macro that was “close” and examine it, the ecosystem was very productive. Once I wanted to go beyond that, it seemed like there was an undocumented chasm to cross.
- Pasorrijer 6y ago
  This has gotten a lot better with the internet. Almost everything in VBA can be found with a simple Google search, and Microsoft's technical documentation online has gotten very good.
  - kgwgk 6y ago
    In the dark offline ages there were also those things called "books" :-) https://www.oreilly.com/library/view/vb-vba/1565923588/ https://www.oreilly.com/library/view/vb-vba/1565923588/
    - sokoloff 6y ago
      It wasn’t the VB part of VBA that wasn’t well documented, but rather the “for A” part that was spotty. The application automation model wasn’t as thoroughly documented as most of Microsoft’s stuff. This was well after the Internet was seriously prevalent. Things like destroying [iff present] and recreating Excel charts from scratch, including generating all the series labels, shapes, etc., updating elements in a word doc from an excel sheet, generating on-slide progress indicators in PowerPoint.
      - kgwgk 6y ago
        That’s true. But the ability to record macros, as you mentioned, and the object browser alleviate the problem at least in part.
dccoolgai 6y ago
20 years later it seems I spend months fighting overwrought frameworks like Webpack and React to get the equivalent productivity I could get in one day with VBA.
airstrike 6y ago
VBA is great for many things but it has its flaws. The biggest problem with it is really that the tooling around it is decades old so it hurts your productivity. Maintaining VBA code bases is a painful experience, the IDE sucks and the language has enough quirks and shortcomings that it forces you to take long detours to accomplish what would be very simple tasks in more modern languages The loving part of VBA is its interoperability across the Office suite, but there's no reason why that couldn't be done in, say, Python Oh, I almost forgot. VBA classes are absolute misery.
- ddingus 6y ago
  This is the part which saves crazy time: The loving part of VBA is its interoperability across the Office suite, but there's no reason why that couldn't be done in, say, Python I agree with you, but Python and pretty much every code environment is missing a few things that create a pretty high barrier to entry: For a whole lot of cases, VBA is not even needed. People put data into cells, operate on it with formulas in other cells that drop output into still other cells which are then used to get output. Input can be almost anything these days. Formulas have a well defined, easy to understand syntax that work across a wide variety of operators. Simple copy / paste operations make sense, often with the intended data mapped right in. (given people are a little organized) Output can be almost anything these days too. And it's live. Make a change, see it happen. That's real power! People don't have to know much to make it all work either. I have been using Excel to transform business data for years, model business and a lot of other things, and as a rapid prototype system. I can write code too. Often I do, but the more specific and or variable the task is, like a one off need to solve yesterday, the more attractive just banging it out in Excel becomes. Should one get super crazy, have one of those outputs from Excel be a working program. No joke. A script file is one of my favorite outputs. Mash the data up in Excel, and once the plan of attack is clear, execute the script and watch it run on the real system. Check this thing out: https://github.com/tilleul/apple2/tree/master/tools/6502_assembler https://github.com/tilleul/apple2/tree/master/tools/6502_ass... It's a perfectly usable, and I would suggest one of the easiest, assemblers I've ever seen! I ran it on my mobile. Crazy. I just used it to knock out a little routine for a retro-game project I'm working on and was kind of stunned at how lean, accessible, functional this really is. For Clarity: Replacing VBA with something else costs more than the value add at present, and it's because Excel is the gateway drug into VBA. By the time people reach for VBA, they already are familiar with a lot of it.

by richx 6y ago

foepys 6y ago

People are downvoting you but are overlooking the fact that it's not always about making things in the newest tech but more often than not about making things work. Most software will only be seen by industry specific users that don't care that the program is React Native and runs on AWS. A simple VBA script is sometimes completely sufficient to input the data into a spreadsheet. Scott Hanselman called devs doing this "Dark Matter Developers" [1]. 32bit VB6 programs are still able to run on modern Windows 10 machines, even on x64. The hours that would've been lost on porting everything to the newest macOS can be spent on new features or customer wishes. With the .NET Framework it's even possible to seamlessly use VB and .NET in the same program which combines old and modern technology. It's officially unsupported but it works and even gets bugfixes sometimes. 1: https://www.hanselman.com/blog/dark-matter-developers-the-unseen-99 https://www.hanselman.com/blog/dark-matter-developers-the-un...

bgroat 6y ago
I don't want to say "anti-pattern" because that's not what I mean... But new tech should be the last resort. If nothing stable, decades old, and well documented can solve the problem then reach for hot new-ness
- Retric 6y ago
  That’s a little far, old doesn’t mean good. The bleeding edge often gets abandoned, but tech has generally been improving over time. IMO, the sweet spot starts when something was a fad ~5 years ago and is still reasonably popular.
  - DaiPlusPlus 6y ago
    > IMO, the sweet spot starts when something was a fad ~5 years ago and is still reasonably popular. That would mean it's okay to use Angular today, but dev trends (and Google's support "policy") would advise against that.
    - yen223 6y ago
      A good reason to wait a few years is precisely so that we have a clearer picture of what strengths and deficiencies a piece of tech brings to the table, especially out in the real world. We have a good picture of how Angular and React works in production now. We cannot say the same for something like Svelte.
      - fpoling 6y ago
        React is far from being stable. It deprecated a lot older API, added entirely new concept of hooks. If one wants stability, then PHP has a way better track record.
        scrollaway 6y ago
        Nonsense. React is extremely stable. It indeed added hooks, deprecating exactly nothing in doing so. React deprecations are very few and far between.
        DaiPlusPlus 6y ago
        > deprecating exactly nothing in doing so De jure deprecation, correct - but reading between the lines in Facebook's own blog article that introduced Hooks ( https://reactjs.org/docs/hooks-intro.html https://reactjs.org/docs/hooks-intro.html ), which put a bit too much emphasis on "There are no plans to remove classes from React.", which to me means they're definitely going to be deprecating class-based controls in the future.
        6y ago
- nicoburns 6y ago
  > If nothing stable, decades old, and well documented can solve the problem then reach for hot new-ness I think it's a little more nuanced than that. Usually the older technology is more stable and better documented. But not always. Sometimes the new hotness is the new hotness precisely because it's better in these kind of categories.
  - bgroat 6y ago
    You and Retric are right. I'm imagining a checklist of: - Stable - Well Documented - Age In descending order of importance. When choosing between any technology choose the one that is most stable. If multiple options are on a stable release, choose the one that is best documented. If multiple stable releases have excellent documentation, choose whichever is oldest. I don't think this framework is always (or even often) right. But it works for me
    - makapuf 6y ago
      My checklist would be (I'm eager to know other people correct me) suitable (does it some my needs) , stable, available (including documentation, live q&a resources like stackoverflow, blog posts explaining how- not new ones but existing and up to date regarding the version available), and simple.
      - josephg 6y ago
        I try to adapt my checklist to the problem at hand. Sometimes I'm making something as a hobby project, or to solve a problem right now. Sometimes I want to write code that will outlive me, and sometimes I'll just throw some code at the wall and call it done. Each situation necessarily results in different priorities and tools. I wouldn't TDD a gamejam project, and I wouldn't start a multi-year project in zig - at least, not yet. For infrastructure projects I want well written deps which are simple, easy to use and have good documentation. When I'm evaluating something I often read bits of its source code (eg to figure out how to do something not listed in the examples). You get a sense of where to put things that way - actix (the actor library, not the web library) is very carefully designed, but seems to go a bit overboard inventing new concepts (+ associated traits). Tide feels pragmatic - its a bit sloppy with allocations, but it doesn't seem to really care. It wants to be fast enough and good enough while being simple to use. For hobby projects I like to follow my nose and pick whatever seems shiny. Over the last few years I've learned svelte, typescript, snowpack, rust (and some rust libraries), zig, wasm and other stuff. I like to make some risky bets and then just play the hand out and see what happens. And I use that as fuel for when I make longer term projects. I'm making a little database at the moment and I'm using rust - which is much slower for me to write (compared to nodejs) but it matches the values of the project I'm working on to a tee.
- mattmanser 6y ago
  The MVC and ORM revolutions are the counter-argument to this. Rails/Django, then ASP.Net MVC/Laravel/whatever Java was was a massive step forward. If you didn't use it, you were hamstringing yourself. People switched to Rails in droves. As were using ORMs. You'll still get people quibble about this, but never having to go through the tedium of updating 101+ SQL statements when you add a column in a pain you young'uns will never know... JQuery was actually another example. Cross browser Ajax statements were annoying, plus just manually adding individual HTML nodes in HTML was laborious.
  - valenterry 6y ago
    ORMs are not the only way to avoid/solve the problem of having to update many SQL statements. People complain rightfully about them.
  - pjmlp 6y ago
    I have not seen people switching to rails in droves over here, it was a fashion wave that came and went. Apparently they are all now learning Elixir after a short migration wave over to Clojure. C++, Java and ASP.NET over here for the last 20 years.
smitty1e 6y ago
I've never ever tried VBA.Net. But my private NVBC (NecroVisualBasiCon) repo has some great stylings that I tap into at least once a year. Nevertheless, when are they going to relase Office with Python bindings included?
- JJMcJ 6y ago
  Not exactly Python bindings but there is a package called Xlwings that provides a Python<->Excel interface. Somewhat clunky and slow but it does work.
- jussij 6y ago
  One minor correction which is there is no such thing as VBA.Net. There are basically three VB ecosystems. Visual Basic which many refer to as VB6 and it represents the last version every released. VBA which is Visual Basic for Application and lives on to this day as an embedded language for Microsoft products like, Word, Excel, Outlook etc. VB.Net which is an implementation of the Visual Basic language running on the .Net Framework.
  - tonyedgecombe 6y ago
    There was also VBScript, one of the two active scripting engines shipped with Windows and available from IE and WSH.

sokoloff 6y ago

My frustration with VBA is that it didn’t seem very well documented. If I could record a macro that was “close” and examine it, the ecosystem was very productive. Once I wanted to go beyond that, it seemed like there was an undocumented chasm to cross.

Pasorrijer 6y ago
This has gotten a lot better with the internet. Almost everything in VBA can be found with a simple Google search, and Microsoft's technical documentation online has gotten very good.
- kgwgk 6y ago
  In the dark offline ages there were also those things called "books" :-) https://www.oreilly.com/library/view/vb-vba/1565923588/ https://www.oreilly.com/library/view/vb-vba/1565923588/
  - sokoloff 6y ago
    It wasn’t the VB part of VBA that wasn’t well documented, but rather the “for A” part that was spotty. The application automation model wasn’t as thoroughly documented as most of Microsoft’s stuff. This was well after the Internet was seriously prevalent. Things like destroying [iff present] and recreating Excel charts from scratch, including generating all the series labels, shapes, etc., updating elements in a word doc from an excel sheet, generating on-slide progress indicators in PowerPoint.
    - kgwgk 6y ago
      That’s true. But the ability to record macros, as you mentioned, and the object browser alleviate the problem at least in part.

dccoolgai 6y ago

20 years later it seems I spend months fighting overwrought frameworks like Webpack and React to get the equivalent productivity I could get in one day with VBA.

airstrike 6y ago

VBA is great for many things but it has its flaws. The biggest problem with it is really that the tooling around it is decades old so it hurts your productivity. Maintaining VBA code bases is a painful experience, the IDE sucks and the language has enough quirks and shortcomings that it forces you to take long detours to accomplish what would be very simple tasks in more modern languages The loving part of VBA is its interoperability across the Office suite, but there's no reason why that couldn't be done in, say, Python Oh, I almost forgot. VBA classes are absolute misery.

ddingus 6y ago
This is the part which saves crazy time: The loving part of VBA is its interoperability across the Office suite, but there's no reason why that couldn't be done in, say, Python I agree with you, but Python and pretty much every code environment is missing a few things that create a pretty high barrier to entry: For a whole lot of cases, VBA is not even needed. People put data into cells, operate on it with formulas in other cells that drop output into still other cells which are then used to get output. Input can be almost anything these days. Formulas have a well defined, easy to understand syntax that work across a wide variety of operators. Simple copy / paste operations make sense, often with the intended data mapped right in. (given people are a little organized) Output can be almost anything these days too. And it's live. Make a change, see it happen. That's real power! People don't have to know much to make it all work either. I have been using Excel to transform business data for years, model business and a lot of other things, and as a rapid prototype system. I can write code too. Often I do, but the more specific and or variable the task is, like a one off need to solve yesterday, the more attractive just banging it out in Excel becomes. Should one get super crazy, have one of those outputs from Excel be a working program. No joke. A script file is one of my favorite outputs. Mash the data up in Excel, and once the plan of attack is clear, execute the script and watch it run on the real system. Check this thing out: https://github.com/tilleul/apple2/tree/master/tools/6502_assembler https://github.com/tilleul/apple2/tree/master/tools/6502_ass... It's a perfectly usable, and I would suggest one of the easiest, assemblers I've ever seen! I ran it on my mobile. Crazy. I just used it to knock out a little routine for a retro-game project I'm working on and was kind of stunned at how lean, accessible, functional this really is. For Clarity: Replacing VBA with something else costs more than the value add at present, and it's because Excel is the gateway drug into VBA. By the time people reach for VBA, they already are familiar with a lot of it.