Points: 42

# Comments: 33

I can't speak for all orgs but at the end of the day, the only metric that my org cares about is how AI is improving our work. Holding the line for quality is definitely a good thing, but when your org doesn't care about the pressure on PR reviewers, and the effort it took to fix those PR mistakes or their repeat, those reviews are only helping the loop case and that AI is without flaws. I am not saying AI is a bad thing all together, but when the org ignores those metrics, I am only contributing and helping to prove that the other side is right.

I feel like if we assume this is in good faith, and they want to make sure adults can ensure minors don't have access to certain content, why would they use age as the information? This can be solved, or even have been solved by having Parental Control feature like in IOS which provides finer options than what you would get with age.

This could OK if this was requiring that any device or operating system have access to parental control in any capacity (either by default or via third party application) and limited for things that would be used by minors so that VMs or other stuff don't have to worry about this. Or, they could mandate products to indicate that the feature exist. That way, a parent can decide what to give their child.

The bill itself sort of goes against its "purpose". If the purpose is to make a convenient API for stores to know their user, and avoid showing them certain content then why did the bill state: "If an operator has internal clear and convincing information that a user's age is different than the age indicated by a signal received in accordance with this Section, the operator shall use that information as the primary indicator of the user's age."

because many people lie in those forms. Many people on steam will select they were born in 1900, including myself. So how will this API help? the only way for it to be useful is if they later require full verification.

while this is due to Zig maintainers' code quality, I think a large contributing factor is the choice of syntax. As an exercise, try navigating a C, C++ and any other language source code without an IDE or LSP. things like:

- "Where did that function come from?"

- "What and where is this type?"

what do you have to do to find that out? due to the flexible ways you can declare things in C, it may take you a lot of steps to find these information. even in search, a variable and a function can share the same prefix due to the return type placement. hence why some people prefer function return types in a separate line.

Even with languages like Rust for example, finding if a type in a function parameters is an enum or struct and finding its definition can require multiple steps like search "enum Foo" or "struct Foo", in Zig i can search "const Foo" and i will immediately know what it is.

while i do hope that C gets defer and constexpr functions in the next standard or maybe better generics or enums, Zig syntax is much better to work with in my opinion.

> The key thing is to develop an intuition for questions it can usefully answer vs questions that are at a level of detail where the lossiness matters

the problem is that in order to develop an intuition for questions that LLMs can answer, the user will at least need to know something about the topic beforehand. I believe that this lack of initial understanding of the user input is what can lead to taking LLM output as factual. If one side of the exchange knows nothing about the subject, the other side can use jargon and even present random facts or lossy facts which can almost guarantee to impress the other side.

> The way to solve this particular problem is to make a correct example available to it.

My question is how much effort would it take to make a correct example available for the LLM before it can output quality and useful data? If the effort I put in is more than what I would get in return, then I feel like it's best to write and reason it myself.

Comments URL: https://news.ycombinator.com/item?id=45065455

Points: 44

# Comments: 6

Comments URL: https://news.ycombinator.com/item?id=44090094

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=42268310

Points: 297

# Comments: 82

Comments URL: https://news.ycombinator.com/item?id=41419632

Points: 2

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=41058862

Points: 3

# Comments: 0

[1] https://www.icann.org/en/public-comment/proceeding/proposed-...

Comments URL: https://news.ycombinator.com/item?id=40484521

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=40189818

Points: 2

# Comments: 0

I do find some false positives, but I haven't had many of them to be a deal breaker for me. Aside from what I mentioned about the errors being descriptive, I do like the defaults and that it's part of the compilation process.

for example, possible malloc null warning is on by default (which i don't think is on clang).