5 ms·

Okay then, how about "at least 3 languages with each at least a few thousand devs using them supports it" And my example is not "if". There is no if. Maybe the

Okay then, how about "at least 3 languages with each at least a few thousand devs using them supports it" And my example is not "if". There is no if. Maybe there is "if" being used in the underlying functions? Again, eventually everything is machine code, but then every discussion about PLs is meaningless...

9rx 2y ago
> And my example is not "if". There is no if. It doesn't literally include the keyword "if", but you've only rewritten an "if" statement in different syntax – and with worse syntax at that. It doesn't take things to a higher level. But, again, I understand that this is probably not a good example on which to start from. We only ended up with it because it is a common snippet found elsewhere. How about you pick something that is a better demonstration? > Again, eventually everything is machine code Right, but we have higher level languages that enable expressing ideas beyond what the machine is directly capable of. The "if" statement itself is one such abstraction, albeit a fairly low-level one.
- valenterry 2y ago
  > 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

> And my example is not "if". There is no if. It doesn't literally include the keyword "if", but you've only rewritten an "if" statement in different syntax – and with worse syntax at that. It doesn't take things to a higher level. But, again, I understand that this is probably not a good example on which to start from. We only ended up with it because it is a common snippet found elsewhere. How about you pick something that is a better demonstration? > Again, eventually everything is machine code Right, but we have higher level languages that enable expressing ideas beyond what the machine is directly capable of. The "if" statement itself is one such abstraction, albeit a fairly low-level one.

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