What i don't get is...why? why not just use VB.net (or some other tool)
XLIDE: VBA without excel
21–30 of 31 posts
Re: XLIDE: VBA without excel
#22What i don't get is...why? why not just use VB.net (or some other tool)
If you want to automate Excel from the inside VBA is a lot simpler than VB.Net
From the brief look I gave it this project seems to be about modifying existing VBA code that lives in Excel files
VB.Net is a different language, neither a sub-set nor super-set of VBA.
Re: XLIDE: VBA without excel
#23Wonder how extensively VBA is used in today's Excel. I know that macros are considered dangerous but would love to know if there are exceptions for that rule. On the other hand I wonder why aren't they run in such a sandbox where the most destructive action they can do is to wipe the sheets.
> extensively VBA is used in today's Excel Very. Although I don't believe it's being used for greenfield hacks as much now, the world largely still runs on workbooks & apps built in Excel + VBA years and years ago. There are entire supply chains that likely run on this built by some analyst a decade or more ago. It remains by far the largest source of Shadow IT there is, and there isn't enough dev time or appetite to…
The good news is that my VBA calls out to some old compiled(?) fortran for the matrix maths that I'd otherwise be too slow to run!
Re: XLIDE: VBA without excel
#24Earlier quoted context omitted.
> especially of other people's work. Claude ain't “other people” so I don't think this applies. By the way, the guidelines proscribe AI-generated comments, so I don't see why AI-generated posts should be treated differently.
This is a nice demonstration of how AI enables people to build things that just wouldn't have existed before because the hassle was prohibitive. Negativity is still unwarranted here.
AI ain't magical, you can vibe code a plausible project in a week-end, but having something that actually works still requires lots of work, in the form of testing and iterating on the result in order to get a working piece of software.
Until you've done this work, the result is just a low-effort piece of content.
Re: XLIDE: VBA without excel
#25Very cool in theory. Unfortunately it's just 12klocs of a vibe-coded week-end project. Edit: it's actually 50klocs since the pyOpenVBA dependency is from the same author and has been made the week-end before.
Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something. https://news.ycombinator.com/newsguidelines.html
Knowledge of it being absolutely useless slop is very useful for those of us that want to avoid all this garbage. There’s nothing shallow about it, it taught me that this project is slop.
Re: XLIDE: VBA without excel
#26Earlier quoted context omitted.
My first exposure to professional programming was writing VBA and SQL (yes, together) at a massive manufacturing facility that had really old equipment. Now with AI it's much easier to replace the code but VBA still has a stranglehold on legacy systems.
I think with AI and the continued availability of VBA, people will create a lot of new monstrosities.
Kinda disagree. The code I had worked with was super unoptimized and difficult to run because there was just enormous amounts tribal knowledge that was just gone over the years as the company evolved. Also basically all the original devs had left.
LLMs can help with that so much they know random minute details of lets say ADOdb and whatnot.
Re: XLIDE: VBA without excel
#27Earlier quoted context omitted.
When was this specific guideline written? In 2008? And dies it really apply when we’re talking about slop?
When it was written has no bearing on its validity. It applies when you're talking about someone else's work. Not every repo is slop. If you want to make a claim that this code is bad, then claim that rather than saying "they used AI therefore it's bad" which is, as the rule says, a shallow dismissal that teaches us nothing.
> It applies when you're talking about someone else's work.
It doesn’t apply when writing a thoughtful reply takes more time than original “project” ever took.
Re: XLIDE: VBA without excel
#28Wonder how extensively VBA is used in today's Excel. I know that macros are considered dangerous but would love to know if there are exceptions for that rule. On the other hand I wonder why aren't they run in such a sandbox where the most destructive action they can do is to wipe the sheets.
I'm not at liberty to talk more about the details, but last year I worked on a project to modernize a process that critically relied on a VBA macro to handle billions (yes, with a B). > they run in such a sandbox What makes them interesting is that they can talk with the outside world: API calls, databases, the terminal named after a former Democratic primary candidate...
> critically relied on a VBA macro to handle billions
Why is this surprising (or a secret)? It probably runs entirely bug-free and has done so for a decade or three - it would be hard to imagine still running if it regularly had issues or sent just a small percentage of those billions of dollars to the wrong place. What does your modernization do better?
Re: XLIDE: VBA without excel
#29What i don't get is...why? why not just use VB.net (or some other tool)
If you want to automate Excel from the inside VBA is a lot simpler than VB.Net From the brief look I gave it this project seems to be about modifying existing VBA code that lives in Excel files VB.Net is a different language, neither a sub-set nor super-set of VBA.
There are some differences, although stuff like Me and having a REPL got eventually added back.
Using VB.NET with Windows Forms is quite similar to VB 6 with COM components.
However VB 6 had much easier way to deal with COM interop, and had better AOT developer experience versus Native AOT in .NET.
Now, it isn't as if Microsoft cares that much about VB.NET in 2026, beyond keeping some interoperability updates with C# going on.
Re: XLIDE: VBA without excel
#30Earlier quoted context omitted.
When was this specific guideline written? In 2008? And dies it really apply when we’re talking about slop?
When it was written has no bearing on its validity. It applies when you're talking about someone else's work. Not every repo is slop. If you want to make a claim that this code is bad, then claim that rather than saying "they used AI therefore it's bad" which is, as the rule says, a shallow dismissal that teaches us nothing.
> If you want to make a claim that this code is bad, then claim that rather than saying "they used AI therefore it's bad"
I'm not claiming that at all. The fact that it's AI written isn't even disclosed anywhere on that repo!
The reason why I posted about this being AI slop is after I checked the repo.
> Not every repo is slop.
But this one is. Hence my criticism.
> It applies when you're talking about someone else's work.
The issue at stake is that I'm not criticizing someone else's work, I'm actually criticizing someone's lack of it. This repo is low effort content and that's the problem.