> Claude ain't “other people” so I don't think this applies.
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.
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.
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.
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.
As long as no one is trying to hide anything, I won't complain. Working on VBA outside of Excel seems useful, especially if reliably integrated with source control.
Ultimately this project's success will be determined by its test suite... it's tough to get quality tests by vibe coding.
Wonder 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.
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.
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...
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.
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.
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.
Very 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
> 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.
> Claude ain't “other people” so I don't think this applies.
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.
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.
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.
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.
As long as no one is trying to hide anything, I won't complain. Working on VBA outside of Excel seems useful, especially if reliably integrated with source control.
Ultimately this project's success will be determined by its test suite... it's tough to get quality tests by vibe coding.
Wonder 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.
https://www.incometax.gov.in/iec/foportal/downloads/income-t...
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.
The world lives on Excel macros. The amount of “shadow it” where the business logic allowing big businesses to run is encoded is unfathomable.
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...
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.
> 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 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.
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!
Probably more VBA used today from "yesterday's" Excel spreadsheets than new development. There's a reason Microsoft still produces 32-bit Office.
Enormously!
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.
What 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.
Gonna have some fun with this!
Also known as: downside without the upside.