4 ms·

> but you've only rewritten an "if" statement in different syntax I don't understand what you mean. There is, to my knowledge, no different syntax for if-state

> but you've only rewritten an "if" statement in different syntax I don't understand what you mean. There is, to my knowledge, no different syntax for if-statements. In my code example there simply is no if being used. Care to elaborate?

9rx 2y ago
> There is, to my knowledge, no different syntax for if-statements. Can we agree that the ternary operator in C provides a way to write if-statements with different syntax? > In my code example there simply is no if being used. 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. It is still leans on the exact same conceptual if-statement expression, albeit written in a slightly different way. The same is true of your code example.
- valenterry 2y ago
  > 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

> There is, to my knowledge, no different syntax for if-statements. Can we agree that the ternary operator in C provides a way to write if-statements with different syntax? > In my code example there simply is no if being used. 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. It is still leans on the exact same conceptual if-statement expression, albeit written in a slightly different way. The same is true of your code example.

valenterry 2y ago
> 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.