Oh, both of them are stuck in a false dichotomy. The right answer is obviously a mix of both. They could have a valid debate about budgets (both dev and runtime costs) and precision-recall tradeoffs, and long-tail utterances, and whether the problem is simple enough that it’s anywhere close to true that the rules will fit in someone’s head in order to be testable and debuggable. They can talk about what parts of the problem are best addressed by what tools. But a general discussion of “if we have only one tool, should it be a hammer or a screwdriver” is probably unhelpful.
“Just try it” is probably fairly costly to do, so I understand Bob’s reluctance. He’s wrong, because “try it” includes “learn enough about it to actually understand it’s strengths and weaknesses”. Alice is wrong because “you’re reasoning too much” is not what’s happening, and trying it is not an alternative to reasoning, it’s an aid to reasoning better.
I don’t find much use in trying to analyze whether Alice is trying to shut down the conversation, or whether Bob is confusing things that are basic enough that Alice is understandably frustrated and unable to give good advice on a practical level. Again, specifics of the discussion matter—is this a friendly, low-stakes brainstorm, or are they teammates trying to solve a specific problem, or is it some other relationship?
That said, I’m now shutting down this conversation :) I’ll read any further responses, but probably won’t further engage.
That said, I’m now shutting down this conversation :) I’ll read any further responses, but probably won’t further engage.
Thanks for your patience. Your response is by far the most useful one I have. I really appreciate that.
If you find replying a short sentence isn’t much burden, can you tell why you don’t want to continue this conversation? Is it because continuing it doesn’t stimulate your interest as you have on it in the beginning? Can you share why?
I don’t know that my reasons are all that legible, but some combination of:
I’ve now heard enough details that my curiosity about the framing of the discussion is satisfied.
I actually know quite a bit about the object-level discussion (having worked on large NLP projects, though before the dominance of LLMs), and I don’t think there’s much value to you or to me in trying to go deeper on a problem I’m not invested in.
My estimate of future enjoyment or education from further exploration of the topic is pretty low. I got good value from a small time/thought investment in early conversation, and it feels like we’ve passed the peak of marginal enjoyment for additional effort.
I’m still a little annoyed at the incorrect and wasteful generalization at the start, when the specifics dominate the interpretation that should be used.
Ok, that sounds a lot more harsh than I actually feel. I probably should have said “I think we’ve explored the overall question about Alice and Bob, and that’s all I was looking for in the first place.”
They could have a valid debate about budgets (both dev and runtime costs) and precision-recall tradeoffs, and whether the problem is simple enough that it’s anywhere close to true that the rules will fit in someone’s head in order to be testable and debuggable.
I’m not sure what “it’s anywhere close to true that the rules will fit in someone’s head in order to be testable and debuggable” means. I guess you just mean if the problem is simple enough then the rule-based approach is better. Is that correct?
I’ll assuming yes here. While Bob indeed doesn’t mention explicitly about budgets, I guess we can all assume that everyone wants budgets as low as possible. And since Bob thinks that since the context is small here, I think he thinks that the problem is simple enough, and if using the rule-based approach then the precision-recall tradeoffs won’t bee applied here. Overall, I think that in his mind the rule-based approach is the perfect tool for the problem.
They can talk about what parts of the problem are best addressed by what tools. But a general discussion of “if we have only one tool, should it be a hammer or a screwdriver” is probably unhelpful.
So while I really agree with this, I suppose the reason both sides stuck is because both assume that their tool has superiority over the other on the problem. Alice sees the problem and concludes that this must be a nail and can never be a screw, so obviously the screwdriver is bad. Bob sees the problem and concludes that this must be a screw and can never be a nail, so obviously the hammer is bad.
So I guess instead of arguing whether the solution should be a screwdriver or a hammer, they should argue on whether the problem is a screw or a nail. Perhaps it’s a combination of screw and nail. Bob does give more detail about the problem when he says “the context is small”, and I guess in his mind it’s a distinctive feature of a screw, but perhaps the reality is that it’s a shared feature of both. He sees the shank and mistakes it with the helical thread.
Oh, both of them are stuck in a false dichotomy. The right answer is obviously a mix of both. They could have a valid debate about budgets (both dev and runtime costs) and precision-recall tradeoffs, and long-tail utterances, and whether the problem is simple enough that it’s anywhere close to true that the rules will fit in someone’s head in order to be testable and debuggable. They can talk about what parts of the problem are best addressed by what tools. But a general discussion of “if we have only one tool, should it be a hammer or a screwdriver” is probably unhelpful.
“Just try it” is probably fairly costly to do, so I understand Bob’s reluctance. He’s wrong, because “try it” includes “learn enough about it to actually understand it’s strengths and weaknesses”. Alice is wrong because “you’re reasoning too much” is not what’s happening, and trying it is not an alternative to reasoning, it’s an aid to reasoning better.
I don’t find much use in trying to analyze whether Alice is trying to shut down the conversation, or whether Bob is confusing things that are basic enough that Alice is understandably frustrated and unable to give good advice on a practical level. Again, specifics of the discussion matter—is this a friendly, low-stakes brainstorm, or are they teammates trying to solve a specific problem, or is it some other relationship?
That said, I’m now shutting down this conversation :) I’ll read any further responses, but probably won’t further engage.
Thanks for your patience. Your response is by far the most useful one I have. I really appreciate that.
If you find replying a short sentence isn’t much burden, can you tell why you don’t want to continue this conversation? Is it because continuing it doesn’t stimulate your interest as you have on it in the beginning? Can you share why?
I don’t know that my reasons are all that legible, but some combination of:
I’ve now heard enough details that my curiosity about the framing of the discussion is satisfied.
I actually know quite a bit about the object-level discussion (having worked on large NLP projects, though before the dominance of LLMs), and I don’t think there’s much value to you or to me in trying to go deeper on a problem I’m not invested in.
My estimate of future enjoyment or education from further exploration of the topic is pretty low. I got good value from a small time/thought investment in early conversation, and it feels like we’ve passed the peak of marginal enjoyment for additional effort.
I’m still a little annoyed at the incorrect and wasteful generalization at the start, when the specifics dominate the interpretation that should be used.
Ok, that sounds a lot more harsh than I actually feel. I probably should have said “I think we’ve explored the overall question about Alice and Bob, and that’s all I was looking for in the first place.”
I see. Thanks for replying. I wonder if we move the topic to how your interest works, would that be your interest?
I’m not sure what “it’s anywhere close to true that the rules will fit in someone’s head in order to be testable and debuggable” means. I guess you just mean if the problem is simple enough then the rule-based approach is better. Is that correct?
I’ll assuming yes here. While Bob indeed doesn’t mention explicitly about budgets, I guess we can all assume that everyone wants budgets as low as possible. And since Bob thinks that since the context is small here, I think he thinks that the problem is simple enough, and if using the rule-based approach then the precision-recall tradeoffs won’t bee applied here. Overall, I think that in his mind the rule-based approach is the perfect tool for the problem.
So while I really agree with this, I suppose the reason both sides stuck is because both assume that their tool has superiority over the other on the problem. Alice sees the problem and concludes that this must be a nail and can never be a screw, so obviously the screwdriver is bad. Bob sees the problem and concludes that this must be a screw and can never be a nail, so obviously the hammer is bad.
So I guess instead of arguing whether the solution should be a screwdriver or a hammer, they should argue on whether the problem is a screw or a nail. Perhaps it’s a combination of screw and nail. Bob does give more detail about the problem when he says “the context is small”, and I guess in his mind it’s a distinctive feature of a screw, but perhaps the reality is that it’s a shared feature of both. He sees the shank and mistakes it with the helical thread.
I hope this make sense.