Putting the structure and thinking behind something you have in your head into plain but *precise* English is very hard actually, so I'm not too sure this is a good way to interact with a coding AI, honestly.
>"Here's what I want for the macro system:
>[explicit control flow description]
>[clear data structure spec]
>"it should call the same functions that are called when the user presses a key"
>NOT STATED: The implicit assumptions about what to do when you hit a minor ambiguous spot in the implementation
The AI:
>"I should ignore the data structure spec and make a different thing for macro files that then gets converted to spec at runtime"
>"The user said an optional time field for each function in the macro list? He must mean that it's a delay between the last and this call, even though he explicitly states that the last call is pop()ed from the fucking list after running so there would be no way to calculate if the delay A to B is elapsed, because again, I received a spec that explicitly fucking removes A from memory.
>"He said to roll macro processing into the key handling? Let me forget that ten lines in and instead put it outside and before the key handling"
I think I should try to talk to it entirely in pseudocode. At least it can infer the implicit design from my code's layout then.
The question is how much I gain by doing that instead of just coding myself. I don't learn, I miss out on understanding my program at all times, and the closer I get to just writing code, the less time I gain from not writing it myself.
>"Here's what I want for the macro system:
>[explicit control flow description]
>[clear data structure spec]
>"it should call the same functions that are called when the user presses a key"
>NOT STATED: The implicit assumptions about what to do when you hit a minor ambiguous spot in the implementation
The AI:
>"I should ignore the data structure spec and make a different thing for macro files that then gets converted to spec at runtime"
>"The user said an optional time field for each function in the macro list? He must mean that it's a delay between the last and this call, even though he explicitly states that the last call is pop()ed from the fucking list after running so there would be no way to calculate if the delay A to B is elapsed, because again, I received a spec that explicitly fucking removes A from memory.
>"He said to roll macro processing into the key handling? Let me forget that ten lines in and instead put it outside and before the key handling"
I think I should try to talk to it entirely in pseudocode. At least it can infer the implicit design from my code's layout then.
The question is how much I gain by doing that instead of just coding myself. I don't learn, I miss out on understanding my program at all times, and the closer I get to just writing code, the less time I gain from not writing it myself.