Yours an other similar comments are disproportionally rude given that the author was very upfront about their methodology.

And I don't think it's constructive to cherrypick commits in this context.

> I even started trying out the fully autonomous coding: instead of examining its every action, I just write a TODO list with many tasks, and ask it to finish the tasks one by one.

> I never had to fully understand the code. What I had to do is: I asked it to give me a plan of changes before implementation, it gave me a few options, and then I chose the option that seemed most reasonable to me. Remember, I’m not an expert on this. I think most of the time, anybody who has taken some undergraduate compiler class would probably make the right choice.

The idea has merits. Take it as a PoC.

▲

wavemode 2 days ago | parent | next [-]

I don't see anything that is the slightest bit "rude" in the comment you're replying to. It actually begins with enthusiastic praise of the project and its goals.

I don't understand why you feel it's not "constructive" to review the quality of code of a project. Are people supposed to just blindly believe in the functionality without peeking under the hood?

	▲	hu3 2 days ago \| parent [-]
		Let's agree to disagree then. Initial praising doe not preclude rudeness. And complaining about a commit that was undone 30 minutes later is not only pointless in the presented context, it's a cheap attempt at insulting. > Are people supposed to just blindly believe in the functionality without peeking under the hood False dichotomy. No one said that. And we both know this is not the way regardless of the codebase. I think the idea has merits and given the honesty of the post, it's rather more productive to comment on it instead.

▲

UncleMeat 2 days ago | parent | prev [-]

> The idea has merits. Take it as a PoC.

Does it? There have been a gazillion such static analyzers. They all do one of two things: ignore the hard parts of tackle the hard parts. If you ignore the hard parts then your tool is useless. If you tackle the hard parts then your tool is orders of magnitude more complex and it still struggles to work well for real world projects. This is in the former category.

The article says "And since the static analysis is mostly statically scoped, it doesn’t require heavy cross-file analysis."

Oops. Suddenly you either handle aliasing soundly and your tool is plagued with zillions of false positives or you handle aliasing unsoundly and... you aren't getting what makes rust different. Separate compilation has been a problem for C++ analyzers for ages. Just declaring it to not actually be a big deal is a huge red flag.

Heck, even just approaching this as an AST-level analysis is going to struggle when you encounter basic things like templates.

The article says this: "Everybody tries to fix the language, but nobody tries to just analyze it." This is just flagrantly false. What's bizarre is that there are people at Stony Brook who have done this. Also, introducing new syntax (even if they are annotations) is more-or-less the same thing as "fixing the language" except that there is almost no chance that your dependencies (including the standard library) are annotated in the way you need.