[flagged]
--dangerously-skip-reading-code
31–40 of 219 posts
Re: --dangerously-skip-reading-code
#32Earlier quoted context omitted.
Yep, calling it an "unsolved" problem is a misnomer. We already have mathematical proof that it's impossible. But that aside, it's such a shame that many drinking the AI Kool-Aid aren't even aware of the theoretical limits of a computer's capabilities.
This sort of theoretical result is not always as clear-cut as you suggest. Computers are finite machines. There is a theorem that although a machine with finite memory can add, multiplication requires unbounded memory. Somehow we muddle along and use computers for multiplication anyway. More to your point there is a whole field of people who write useful programs using languages in which every program must be accompa…
But it's not like these systems make theory go away, they make compromises. So the question is, what's the compromise required for an algorithm that can check the conformance of computer programs to natural language specifications that doesn't involve hoping for the best?
Re: --dangerously-skip-reading-code
#33> Rework is almost free Is it? All the electricity and capital investment in computing hardware costs real money. Is this properly reflected in the fees that AI companies charge or is venture capital propping each one up in the hope that they will kill off the competition before they run out of (usually other people's) money?
Yeah, a lot of Claude Code users(me included) found in March if rework is free or not.
Re: --dangerously-skip-reading-code
#34Instead of accepting 20,000 lines of slop per PR (and never-ending combinatorial complexity), maybe we should aim to think about abstractions and how to steer LLMs to generate code similar to that of a skilled human developer. Then it could actually be a maintainable artifact by humans and LLMs alike.
Re: --dangerously-skip-reading-code
#35Entertaining flag name! React team seems to really have set a precedent with their "dangerouslySetInnerHTML" idea. Or did they borrow it somewhere? I'm just curious about that etymology, of course the idea is not universally helpful: for example, for dd CLI parameters, it would only make a mess. But when there's a flag/option that really requires you to be vigilant and undesired the input and output and all edge case…
I’m pretty sure this comes from Claude code’s --dangerously-skip-permissions
Re: --dangerously-skip-reading-code
#36Entertaining flag name! React team seems to really have set a precedent with their "dangerouslySetInnerHTML" idea. Or did they borrow it somewhere? I'm just curious about that etymology, of course the idea is not universally helpful: for example, for dd CLI parameters, it would only make a mess. But when there's a flag/option that really requires you to be vigilant and undesired the input and output and all edge case…
I’m pretty sure this comes from Claude code’s --dangerously-skip-permissions
which sounds like it came from React's "dangerouslySetInnerHTML", per the comment you replied to.
Re: --dangerously-skip-reading-code
#37I wonder if with the speed of iteration with AI the industry will switch back to waterfall. Clear documentation first so the LLM can easily produce what's being asked with a round of testing before going back to the documentation stage and running it again. History does repeat itself.
Re: --dangerously-skip-reading-code
#38> If I had to roll out such a development process today, I’d make a standardized Markdown specification the new unit of knowledge for the software project. Product owners and engineers could initially collaborate on this spec and on test cases to enforce business rules. Those should be checked into the project repositories along with the implementing code. There would need to be automated pull-request checks verifyin…
What we really we need is some kind of more detailed spec language that doesn't have edge cases, where we describe exactly what we expect the generated code to do, and then formally verify that the now generated code matches the input spec requirement. It'd be super helpful to have something more formal with no ambiguity, especially because the english language tends to be pretty ambiguous in general which can result in spec problems
I also tend to find especially that there's a lot of cruft in human written spec languages - which makes them overly verbose once you really get into the details of how all of this works, so you could chop a lot of that out with a good spec language
I nominate that we call this completely novel, evolving discipline: 'programming'
Re: --dangerously-skip-reading-code
#39Earlier quoted context omitted.
Yep, calling it an "unsolved" problem is a misnomer. We already have mathematical proof that it's impossible. But that aside, it's such a shame that many drinking the AI Kool-Aid aren't even aware of the theoretical limits of a computer's capabilities.
This sort of theoretical result is not always as clear-cut as you suggest. Computers are finite machines. There is a theorem that although a machine with finite memory can add, multiplication requires unbounded memory. Somehow we muddle along and use computers for multiplication anyway. More to your point there is a whole field of people who write useful programs using languages in which every program must be accompa…
> There is a theorem that (...) multiplication requires unbounded memory
What theorem is that?
The multiplication of any two integers below a certain size (called "words") fits in a "double word" and the naive multiplication algorithm needs to store the inputs, an accumulator and at most another temporary for a grand total of 6*word_size
Sure, you can technically "stream" carry-addition (which is obvious from the way adders are chained in ALU-101) and thus in a strict sense addition is O(1) memory but towards your final point:
> Theory is important, but engineering is also important.
In practice, addition requires unbounded memory as well (the inputs). And it's definitely compute-unbounded, if your inputs are unbounded.
I dislike the term "we muddle along". IEEE 754 has well specified error bars and cases, and so does all good data science. LLMs do not, or at least they do not expose them to the end user
So then, how exactly do we go about proving that the result of chaining prompts is within a controllable margin of error of the intended result? Because despite all the specs, numerical stability is the reason people don't write their own LAPACK.
Re: --dangerously-skip-reading-code
#40> If I had to roll out such a development process today, I’d make a standardized Markdown specification the new unit of knowledge for the software project. Product owners and engineers could initially collaborate on this spec and on test cases to enforce business rules. Those should be checked into the project repositories along with the implementing code. There would need to be automated pull-request checks verifyin…
What we really we need is some kind of more detailed spec language that doesn't have edge cases, where we describe exactly what we expect the generated code to do, and then formally verify that the now generated code matches the input spec requirement. It'd be super helpful to have something more formal with no ambiguity, especially because the english language tends to be pretty ambiguous in general which can result…
yes, am familiar with the "code is spec" trope.
Shame us all for moving away from something so perfect, precise, and that "doesn't have edge cases."
Hey - if you invent a programming language that can be used in such a way and create guaranteed deterministic behavior based on expressed desires as simple as natural language - ill pay a $200/m subscription for it.