3 ms·

> Can we agree that the ternary operator in C provides a way to write if-statements with different syntax? I can neither agree or disagree because I don't know

> Can we agree that the ternary operator in C provides a way to write if-statements with different syntax? I can neither agree or disagree because I don't know, but we are not talking about C and my code example didn't use a ternary operator either, so from my POV it doesn't matter. > async/await was a better example. That moves something to a higher level of abstraction. However, it is not clear how to make that generalize It is clear. Just not to you. Check Haskels do-notation or Scala for-comprehension or F#'s do!-notation and how they work. They all generalize over what async/await does (all with slightly different syntax though)

9rx 2y ago
> so from my POV it doesn't matter. It matters because it is an attempt to explain what I am trying to convey. Technical people in particular tend to not share a common vernacular, so it is likely that I am using words in ways that do not match your understanding of them. Communication is hard. I may have fallen short in my attempt, but surely we can try again? What do you hope to gain from this standoffishness? > It is clear. Just not to you. Fair enough, but that's the whole reason we're here, isn't it? To change that. If it were already clear, what purpose would the discussion serve? So, let's go back to the opening comment with the age check problem. That is the explicit case where a higher level abstraction is being sought, and I think it serves as a good place to think about generalization without getting caught in the weeds. I looked at Haskell's do notation and don't see how it helps. I prompted several LLMs in hopes that maybe they could resolve, but in every case they reversed back to using the exact same if-statements we started with. We're going to have to rely on your wisdom here.
- valenterry 2y ago
  Why don't you just explain it direct and concrete based on my actual code example? You claim that there is some kind of if in it where there is none. > Fair enough, but that's the whole reason we're here, isn't it? To change that. I'm afraid to tell you that I can't change that with my explanation. You will have to actually apply this in practice for a while. So long, that you have gotten used to it. And then compare it to how you work in golang. Because otherwise the code will just look unfamiliar to you and you'll potentially suffer from the blub paradox. Of course this takes tons of time, so I can't expect you (or anyone) to do it. I can only tell how it looks from my POV since I've done it both ways.
  - 9rx 2y ago
    > Why don't you just explain it direct and concrete based on my actual code example? I did. But you said it doesn't matter. Now it does matter? > I'm afraid to tell you that I can't change that with my explanation. No need for an explanation. Code will suffice. Perhaps I cannot write it myself, but I will eventually be able to understand it. > Because otherwise the code will just look unfamiliar to you That may be true in the first instant, but time marches forward and familiarity grows. This isn't an issue. Is the real problem here that the code is so long and arduous that you don't have the time to write it? I don't think that satisfies the intent, if so. The idea is that the abstraction should be better than an if-statement, not the same or worse.
    - valenterry 2y ago
      Well, you said: > Assuming we do agree, there is no literal "if" being used when using the ternary operator. However, it doesn't take the concept to a higher level. So does it mean that you take back your original claim of "if in a different syntax" then and move the goalpost to "higher level"? If so, I think "higher level" is too subjective and I'm tired of discussing this topic. > No need for an explanation. Code will suffice. Perhaps I cannot write it myself, but I will eventually be able to understand it. Then please do me a favor and explain the requirements again, because I'm not sure what exactly you have in mind for the age constraint(s). > That may be true in the first instant, but time marches forward and familiarity grows. This isn't an issue. I don't think so. You have to actually use it yourself, over time. At least that's true for everyone I know. Otherwise the abstraction will not and can not feel better to you, because you assess it in the wrong context. Its like showing someone prolog code who is used to C. That just doesn't work. I can write you the code, but I doubt it will help you. You already called the other example of the divide function to not look great, so from there it only gets worse for you if that style is unfamiliar to you.
      - 9rx 2y ago
        > So does it mean that you take back your original claim of "if in a different syntax" then and move the goalpost to "higher level"? Take back what now? I said that your code example demonstrated an "if" statement written in different syntax; that it did not approach things from a higher level. The same would be true if you had written it with a ternary operator, if the language in question had such a feature. How does restating the same thing in a slightly different way lead to some kind of contradiction or whatever it is you are seeing here? > If so, I think "higher level" is too subjective and I'm tired of discussing this topic. I suspect once again you're getting too caught up in what words mean to you and not what they mean to me. As much as I'd like to use words as you know them, I haven't quite figured out how to drill into your brain to extract that information. Best I can do is use what I have and work with you to clarify intent as needed. But we've already discussed that to death. There was no need to say it again – especially if it has tired you. Why did you bring it up again, exactly...? > You have to actually use it yourself, over time. Time I have. All we lack is your code. > I can write you the code, but I doubt it will help you. Humorously, you've put way more effort into telling me this than the supporting if-statement approach would have required. Does this one again suggest that what you envision is so long and arduous that you are avoiding it because of the effort required? Otherwise you may as well try me. If it doesn't help we're still in the same place with much less energy expenditure on your part as compared to whatever this is. > It's like showing someone prolog code who is used to C. That just doesn't work. No, it works just fine. Prolog is perfectly understandable to read. It is harder to write without first understanding a bunch of technical nuance, but we don't need the uninitiated to write code here. Why not admit that you can't write the code in question? This act isn't fooling anyone.

9rx 2y ago

> so from my POV it doesn't matter. It matters because it is an attempt to explain what I am trying to convey. Technical people in particular tend to not share a common vernacular, so it is likely that I am using words in ways that do not match your understanding of them. Communication is hard. I may have fallen short in my attempt, but surely we can try again? What do you hope to gain from this standoffishness? > It is clear. Just not to you. Fair enough, but that's the whole reason we're here, isn't it? To change that. If it were already clear, what purpose would the discussion serve? So, let's go back to the opening comment with the age check problem. That is the explicit case where a higher level abstraction is being sought, and I think it serves as a good place to think about generalization without getting caught in the weeds. I looked at Haskell's do notation and don't see how it helps. I prompted several LLMs in hopes that maybe they could resolve, but in every case they reversed back to using the exact same if-statements we started with. We're going to have to rely on your wisdom here.

valenterry 2y ago
Why don't you just explain it direct and concrete based on my actual code example? You claim that there is some kind of if in it where there is none. > Fair enough, but that's the whole reason we're here, isn't it? To change that. I'm afraid to tell you that I can't change that with my explanation. You will have to actually apply this in practice for a while. So long, that you have gotten used to it. And then compare it to how you work in golang. Because otherwise the code will just look unfamiliar to you and you'll potentially suffer from the blub paradox. Of course this takes tons of time, so I can't expect you (or anyone) to do it. I can only tell how it looks from my POV since I've done it both ways.
- 9rx 2y ago
  > Why don't you just explain it direct and concrete based on my actual code example? I did. But you said it doesn't matter. Now it does matter? > I'm afraid to tell you that I can't change that with my explanation. No need for an explanation. Code will suffice. Perhaps I cannot write it myself, but I will eventually be able to understand it. > Because otherwise the code will just look unfamiliar to you That may be true in the first instant, but time marches forward and familiarity grows. This isn't an issue. Is the real problem here that the code is so long and arduous that you don't have the time to write it? I don't think that satisfies the intent, if so. The idea is that the abstraction should be better than an if-statement, not the same or worse.
  - valenterry 2y ago
    Well, you said: > Assuming we do agree, there is no literal "if" being used when using the ternary operator. However, it doesn't take the concept to a higher level. So does it mean that you take back your original claim of "if in a different syntax" then and move the goalpost to "higher level"? If so, I think "higher level" is too subjective and I'm tired of discussing this topic. > No need for an explanation. Code will suffice. Perhaps I cannot write it myself, but I will eventually be able to understand it. Then please do me a favor and explain the requirements again, because I'm not sure what exactly you have in mind for the age constraint(s). > That may be true in the first instant, but time marches forward and familiarity grows. This isn't an issue. I don't think so. You have to actually use it yourself, over time. At least that's true for everyone I know. Otherwise the abstraction will not and can not feel better to you, because you assess it in the wrong context. Its like showing someone prolog code who is used to C. That just doesn't work. I can write you the code, but I doubt it will help you. You already called the other example of the divide function to not look great, so from there it only gets worse for you if that style is unfamiliar to you.
    - 9rx 2y ago
      > So does it mean that you take back your original claim of "if in a different syntax" then and move the goalpost to "higher level"? Take back what now? I said that your code example demonstrated an "if" statement written in different syntax; that it did not approach things from a higher level. The same would be true if you had written it with a ternary operator, if the language in question had such a feature. How does restating the same thing in a slightly different way lead to some kind of contradiction or whatever it is you are seeing here? > If so, I think "higher level" is too subjective and I'm tired of discussing this topic. I suspect once again you're getting too caught up in what words mean to you and not what they mean to me. As much as I'd like to use words as you know them, I haven't quite figured out how to drill into your brain to extract that information. Best I can do is use what I have and work with you to clarify intent as needed. But we've already discussed that to death. There was no need to say it again – especially if it has tired you. Why did you bring it up again, exactly...? > You have to actually use it yourself, over time. Time I have. All we lack is your code. > I can write you the code, but I doubt it will help you. Humorously, you've put way more effort into telling me this than the supporting if-statement approach would have required. Does this one again suggest that what you envision is so long and arduous that you are avoiding it because of the effort required? Otherwise you may as well try me. If it doesn't help we're still in the same place with much less energy expenditure on your part as compared to whatever this is. > It's like showing someone prolog code who is used to C. That just doesn't work. No, it works just fine. Prolog is perfectly understandable to read. It is harder to write without first understanding a bunch of technical nuance, but we don't need the uninitiated to write code here. Why not admit that you can't write the code in question? This act isn't fooling anyone.