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?

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.

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)

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.

> 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.

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.

> 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.

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.

Sorry, it was late and you indeed mentioned that it wasn't making it "high level". My bad. Unfortunately, "high level" is quite subjective and I'm not willing to put the time to discuss if something falls under this definition or not.

> Why not admit that you can't write the code in question? This act isn't fooling anyone.

I asked you to clarify what exactly you want to see (which you didn't quote, even though you quoted basically everything else in my reply). In this particular thread here, there was no mention of age, that was in one of the other threads. So before I write code for something that you don't want to you

Again, please explain the requirements for the code again. What exactly do you want to see written in this style?

Uh... https://news.ycombinator.com/item?id=43487167

With respect, are you okay? Between this and your other comment [https://news.ycombinator.com/item?id=43502693] that was completely off the rails, I'm worried for you. You seem to have lost your sense of what is going on.

If it is simply that you are posting too much and can't keep things straight, making up stories like that you could code something but won't because I wouldn't be able to understand your brilliance to cover your tracks, maybe it's time to stop using the internet for a while?