4 ms·

What is your justification for the restriction though? Personally i dislike the latter form because it requires me to spend extra time reading what is boilerpl

What is your justification for the restriction though? Personally i dislike the latter form because it requires me to spend extra time reading what is boilerplate that is functionally identical to a ternary. Edit: Not impressed by the down-voting of an earnest question of someone trying to learn more about how other people see things, HN.

ProblemFactory 9y ago
Ternary is the only option if you are using "B ? X : Y" as an expression, want to get the value of X or Y. If-else is the only option if you want to have multiple statements in a {} block, instead of only one function call. So it seems more consistent to use ternary for expressions and if-else for statement control flow.
- Mithaldu 9y ago
  Why are those the only options? I know languages where if/else blocks return values. (Rust, Julia, Python, Perl, R) I also know languages that allow easy ways to embed multi-line blocks into a ternary. (Rust, Perl) I'm sorry, but i really don't follow your logic, can you try to explain it more clearly?
  - TeMPOraL 9y ago
    Does Rust/Julia/Python/Perl/R feature ternary operators? The classic languages with ternary (C, C++, Java, PHP, JavaScript) all have the deficiency of distinction between statements and expressions. When everything in your language is an expression, the need for ternary disappears.
    - Mithaldu 9y ago
      Apparently Rust doesn't. Julia/Perl have it, Python has it with words, and R code can import it.
      - tripzilch 9y ago
        In Python the if/else block does not return a value. Python has a ternary operator, which does return a value. It just so happens this operator uses the tokens `if` and `else`. But it's the same thing what you'd write in C or Javascript as `C ? T : F`, would be written `T if C else F` in Python. Different order of arguments and tokens, but it's still the ternary operator and not an if/else block. You can't get a result from block statements in Python. Just because the ternary operator uses the same tokens as the if/else block, doesn't mean it's the same thing.
    - steveklabnik 9y ago
      Rust has "if is an expression" already anyway, so no ternary. let x = if true { 5 } else { 6 };
  - ProblemFactory 9y ago
    My comment, and the comments above it are all about C-style languages (C, C++, C#, Java). Languages with very different syntax like Python are of course going to have different style preferences. Eg. Python doesn't have a ?: operator at all, just an inline if-else expression, so the entire discussion of "should you use ?: for control flow" is meaningless for Python.
    - Mithaldu 9y ago
      Perl is a C style language.
emodendroket 9y ago
Well for me it's the same reason I don't give functions names that suggest something different from what they do.
- Mithaldu 9y ago
  Are you saying this suggests it does something different from what it does? What does it suggest? boolean_flag ? do_this() : do_that(); It seems so terse as to be impossible to misinterpret. The only possibly feasible way i see for it doing something unexpected would be if it were the last statement in a function in a language that implicitly returns the value returned by the last statement in a function; but users of such languages usually are aware that can happen.
  - emodendroket 9y ago
    Ternaries strongly suggest "side effect-free statement being run for its return value." Perhaps a more apt analogy would be to say it's like writing a method called "getX" with side effects.
    - Mithaldu 9y ago
      > Ternaries strongly suggest "side effect-free How do they suggest that? As far as i am aware ternaries put no restriction whatsoever on what kind of code you can put in its branches. I don't buy the comparison with getX either, since ternaries have no name, they're just some punctuation, and even if implemented as if/else word pairs are completely vague.
      - TeMPOraL 9y ago
        > How do they suggest that? It might be a convention in some circles. I don't think it's a well-established one, though. For me, ternaries strongly suggest "expressions being run for its return value", but without any indication whether or not it's side effect-free. In practice, most of the time such expressions end up being side effect-free (getters, finders, etc.), but every now and then you do want to have a stateful expression (e.g. getting something from a map, and storing a default value there if the key is missing in the map). I believe such stateful expressions are fine to use with ternaries as well.

ProblemFactory 9y ago

Ternary is the only option if you are using "B ? X : Y" as an expression, want to get the value of X or Y. If-else is the only option if you want to have multiple statements in a {} block, instead of only one function call. So it seems more consistent to use ternary for expressions and if-else for statement control flow.

Mithaldu 9y ago
Why are those the only options? I know languages where if/else blocks return values. (Rust, Julia, Python, Perl, R) I also know languages that allow easy ways to embed multi-line blocks into a ternary. (Rust, Perl) I'm sorry, but i really don't follow your logic, can you try to explain it more clearly?
- TeMPOraL 9y ago
  Does Rust/Julia/Python/Perl/R feature ternary operators? The classic languages with ternary (C, C++, Java, PHP, JavaScript) all have the deficiency of distinction between statements and expressions. When everything in your language is an expression, the need for ternary disappears.
  - Mithaldu 9y ago
    Apparently Rust doesn't. Julia/Perl have it, Python has it with words, and R code can import it.
    - tripzilch 9y ago
      In Python the if/else block does not return a value. Python has a ternary operator, which does return a value. It just so happens this operator uses the tokens `if` and `else`. But it's the same thing what you'd write in C or Javascript as `C ? T : F`, would be written `T if C else F` in Python. Different order of arguments and tokens, but it's still the ternary operator and not an if/else block. You can't get a result from block statements in Python. Just because the ternary operator uses the same tokens as the if/else block, doesn't mean it's the same thing.
  - steveklabnik 9y ago
    Rust has "if is an expression" already anyway, so no ternary. let x = if true { 5 } else { 6 };
- ProblemFactory 9y ago
  My comment, and the comments above it are all about C-style languages (C, C++, C#, Java). Languages with very different syntax like Python are of course going to have different style preferences. Eg. Python doesn't have a ?: operator at all, just an inline if-else expression, so the entire discussion of "should you use ?: for control flow" is meaningless for Python.
  - Mithaldu 9y ago
    Perl is a C style language.

emodendroket 9y ago

Well for me it's the same reason I don't give functions names that suggest something different from what they do.

Mithaldu 9y ago
Are you saying this suggests it does something different from what it does? What does it suggest? boolean_flag ? do_this() : do_that(); It seems so terse as to be impossible to misinterpret. The only possibly feasible way i see for it doing something unexpected would be if it were the last statement in a function in a language that implicitly returns the value returned by the last statement in a function; but users of such languages usually are aware that can happen.
- emodendroket 9y ago
  Ternaries strongly suggest "side effect-free statement being run for its return value." Perhaps a more apt analogy would be to say it's like writing a method called "getX" with side effects.
  - Mithaldu 9y ago
    > Ternaries strongly suggest "side effect-free How do they suggest that? As far as i am aware ternaries put no restriction whatsoever on what kind of code you can put in its branches. I don't buy the comparison with getX either, since ternaries have no name, they're just some punctuation, and even if implemented as if/else word pairs are completely vague.
    - TeMPOraL 9y ago
      > How do they suggest that? It might be a convention in some circles. I don't think it's a well-established one, though. For me, ternaries strongly suggest "expressions being run for its return value", but without any indication whether or not it's side effect-free. In practice, most of the time such expressions end up being side effect-free (getters, finders, etc.), but every now and then you do want to have a stateful expression (e.g. getting something from a map, and storing a default value there if the key is missing in the map). I believe such stateful expressions are fine to use with ternaries as well.