No, it's really not a strict improvement. A meaningless name like `v2` does at least convey that you, as the analyst, haven't understood the role of the variable well enough to rename it to something more fitting to its inferred purpose. If the LLM comes up with an "informative" variable name that is not very well-suited towards what it actually does, the name can waste your time by misleading you as to the role of the variable.
I think Ghidra could do better even without any LLM involved. Ghidra will define local variables like this:
SERVICE_TABLE_ENTRY* local_5c;
I wish it at least did something like:
SERVICE_TABLE_ENTRY* local_5c_pServiceTableEntry;
Oh yeah, there’s probably some plugin or Python script to do this. But I just dabble with Ghidra in my spare time
It would be great if it tracked the origin of a variable/parameter name, and could show them in a different colour (or some other visual distinction) based on their origin. That way you could easily distinguish “name manually assigned by analyst” (probably correct) vs “name picked by some LLM” (much more tentative, could easily be a hallucination)
Ghidra does have an extensive scripting API, and I've used LLMs to help me write scripts to do bulk changes like you've described. But you would have to think about how you would ensure the name suffix is synchronized as you retype variables during your analysis.
I disagree with it as a blanket statement. It’s related to the problem of hallucinations in LLMs; sometimes they come up with plausible, misleading bullshit. The user quickly relies on the automatic labeling as a crutch, while exhausting mental effort trying to distinguish the bullshit from the accurate labels. The cryptic symbols do not convey meaning but consequently can’t mislead you.
I don’t reject the whole concept and am bullish on AI-assisted decompilation. But the UX needs to help the user have confidence in the results, just like source code-level static analyzers generate proofs.
At least in Postgres, table-valued functions can't take tables as arguments, only scalars. That's the main difference: functors can not just return tables, but take tables satisfying some interface as arguments.
If there's any company who can afford "real-time LLM training" at this moment, I'm 100% sure they will win this AI race since they probably have at least ~10x compute compared to competitors. Of course, no one can do that right now.
My take is that `auto` is basically a tool to reduce local redundancies rather than typing convenience. Rule of thumb: you should avoid `auto` unless it actually improves readability (e.g. significant reductions of syntactic redundancies), or there is no other option.
Google seriously needs to scale up their generative models to all of crawling/indexing/ranking infrastructure. Their current ranking models are not capable of dealing with the next-gen web filled with 99% gen AI craps. I think they also know this. The problem is the cost and they're hyper-focused on bringing it down, but it is not fast enough.
This is because programming is not a work in a continuous solution space. Think in this way; you're almost guaranteed to introduce obvious bugs by randomly changing just a single bit/token. Assembler, compiler, stronger type system, etc etc all try to limit this by bringing a different view that is more coherent to human reasoning. But computation has an inherently emergent property which is hard to predict/prove at compile time (see Rice's theorem), so if you want safety guarantee by construction then this discreteness has to be much more visible.
When you write something like that, you probably want to add what are "far more important issues to worry over" and why pursuing this legislation would cause delay on that issues. And just in case you're not aware of, "far more important issues to worry over" is usually much harder and more complex to gather consensus across stakeholders and passing this kind of minor legislations doesn't really have any impacts or delay there. This is more of "spare time" stuff.
You may think in that way, but in order to make a such strong statement you probably want to do your homework first, like searching up the discussions and its rationale. Usually there is a good reason to pass a law if it's almost universally voted for.
It it apparently _is_ an actual problem, which is why an attempt at solving it is being made. A black market for reservations is bad not just for customers, but for the establishment that loses out on business if the reservations aren't actually sold, and therefore nobody shows up.
they should go after ticketmaster and livenation which is a far, far bigger issue except of course they lobby hard while black market reservation folk don’t. they need to unionize or something and then lobby hard too :)
It's not a problem at all. Cook at home or go to another restaurant. These legislators should be put on a strict diet of water and bread for a few years until they learn.
Exactly. How is this so called problem even possible without the restaurants allowing it? If they don't like it, stop allowing it. If they don't care, then why should the public care?
This is a prevalent misconception that assumes advertisers don't care about how their money is spent! Advertisers and Google are actually concerned about SEO garbage. Nowadays, most advertisers tend to pay based on # of conversions, its value and ROI. Those spammy sites usually yield a garbage CVR even though their CTR seems great. Advertisers don't like this.
Looks like people don't acknowledge that # of clicks is no more important metric. That seemed to be important when it was the only meaningful performance metric. But the ultimate metric that matters to money is advertiser budget allocation. If they see Google search performs worse in terms of conversions, they will cut their budget there. And this is the real problem that Google has.
reply