ZH version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
67% Positive
Analyzed from 978 words in the discussion.
Trending Topics
#vba#excel#don#run#why#still#net#project#applies#code
Discussion (29 Comments)Read Original on HackerNews
Edit: it's actually 50klocs since the pyOpenVBA dependency is from the same author and has been made the week-end before.
https://news.ycombinator.com/newsguidelines.html
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.
Claude didn't make the post or come up with the idea or execute it independently, so not sure how that applies.
If you want to comment on the code quality or the engineering itself, that would be a good critical comment that teaches us something.
> By the way, the guidelines proscribe AI-generated comments, so I don't see why AI-generated posts should be treated differently.
That's your opinion and not the guideline, so again not sure how it applies.
You're free to e-mail hn@ycombinator.com and suggest, but I'm sure it crossed their mind when they wrote about AI comments so I don't think it's been decided that AI-aided projects are somehow automatically invalidated.
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.
Ultimately this project's success will be determined by its test suite... it's tough to get quality tests by vibe coding.
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.
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 untangle these monstrosities into actual apps.
They aren't sandboxed because that would remove the usefulness. The reason VBA+Excel got its tentacles into everything is precisely because its not sandboxed. Anything the user can access is fair game, including network shares, SQL, and Win32 calls.
> 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...
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?
There are lots of data manipulation tasks I've run into at client or customer sites where, if I had my druthers, I'd use perl or python -- but there's no way to get those in the environment. But Excel is there, and Excel has VBA and a strong API.
If you internalize how Excel works (which is to say: you use the native concepts and don't just leap to how you might do it in perl), there's great power available there. I've written things in Excel with abstractions and class structures I'd be proud to have implemented in "better" languages.
I've also seen "normal" end users discover this power, and find it a tremendous boon to their day to day working life. (This was also true 35 years ago with Lotus macros.) People who would never think of themselves as programmers still have muscle memory for Alt-F11.
You need a genuine licensed excel to run the file and prepare returns. Thankfully you can file same returns online on the portal for free so they get a safe pass that way.
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.
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.