5 ms·

Agreed, I wouldn't call ifs a code smell but rather OOP itself a code smell. In any decent language, if will be an expression, not a statement. There is no dif

Agreed, I wouldn't call ifs a code smell but rather OOP itself a code smell. In any decent language, if will be an expression, not a statement. There is no difference between if and a function.

Bootvis 14y ago
In what languages is if a function?
- entropy_ 14y ago
  LISP maybe?
- jeremiep 14y ago
  In Haskell/Ruby/CoffeeScript: a = if b then c else d In Lisp: (setq a (if b c d)) Only Lisp implements them as a function (more precisely, a macro), but to the programmer there's no difference between using if and calling a function. Of course, they don't compile into function calls in assembly code :)
  - tarabukka 14y ago
    If is an expression in a lot of languages. The syntax you describe is identical to the "ternary statement" in C-style languages.
    - jeremiep 14y ago
      The ternary is an expression, not a statement :) You can write: a = b ? c : d; in C/C++, you can't write a = if(b) { c; } else { d; }.
      - tarabukka 14y ago
        Oh, yeah. My mistake. Although what you describe is a lot more functional in style. You could probably emulate it in a language with higher-order functions.
  - adobriyan 14y ago
    It is called "special form". http://www.lispworks.com/documentation/HyperSpec/Body/03_ababa.htm http://www.lispworks.com/documentation/HyperSpec/Body/03_aba... IF can't be implemented as a function because of evaluation rules.
    - jeremiep 14y ago
      Ah, that is correct. You can't use if as a first-class function in Lisp. I still thought you could pass macros around like normal functions in Common-Lisp. The Lisp interpreter I wrote for fun could do that since the function value is resolved before arguments are evaluated for late macro expansions.
  - Bootvis 14y ago
    Also R and I think were mostly in agreement here. However I'm of the opinion that more than just these languages (languages with lazy evaluation or macro's) are decent and that in for example Ruby there are differences between if and a function, as this example shows (my first lines of Ruby) def iff(cond, x, y) if cond then x else y end end puts iff(true, 1, puts('2')) echoes 2 1 if may behave as a function, but you can't write a function that acts like if. edit: R does have real lazy evalution, e.g. > iff <- function(cond, x, y) { if (cond) x else y } > iff(TRUE, 1, cat('foo')) [1] 1
  - philwelch 14y ago
    There is a difference to the programmer, and it's pretty important as far as "if" goes: if "if" were a function, its arguments would need to be evaluated before they were passed in, which defeats the purpose of "if", which is to conditionally execute only one branch.
  - tomjakubowski 14y ago
    You did say that only Lisp implements "if" as a function, but I thought I'd share that in Haskell "if" is syntactic sugar for a case expression. That is: if x then y else z is sugar for: case x of True -> y False -> z There have been suggestions to replace this sugaring with a proper "if" function, e.g.: if :: Bool -> a -> a -> a if True x _ = x if False _ y = y to remove arguably redundant syntax, but it seems unlikely that this change would happen. See more here: http://www.haskell.org/haskellwiki/If-then-else http://www.haskell.org/haskellwiki/If-then-else
meaty 14y ago
Oh yes we all live in the land of the ideal where everything is functional and has no side effects of course and we're blessed with parenthesis. There is a huge difference between an if and a function. Consider SICP where lazy evaluation is introduced (read it if you haven't). An if statement encompasses the lazy evaluation as a native concept whereas a function's arguments are always evaluated (assumption for now - please carry on reading). So consider an if statement as a control flow structure which automatically supports lazy evaluation and leaves the return semantics up to the user. This abstraction is clean from the highest level, right down to the CPU which uses conditional branching to perform the if operation. There is a 1:1 match all the way down. The function on the other hand does not natively support lazy evaluation and enforces the return semantics. You then have to apply a lazy evaluation mechanism over the top (another layer of abstraction!). This layer of abstraction conveniently ends up using conditional branching to perform the if operation when it gets to CPU level. There is not a 1:1 match all the way down. Big hint there: your functional if at the end of the day is just a compiler abstraction over a state machine which uses ifs. As for OO, the industry I think has decided who won that battle. But alas, no religious war is required. Use what tools work for you.
- raverbashing 14y ago
  But for functional programming there's lambda calculus. OTOH there's no "OOP" calculus "your functional if at the end of the day is just a compiler abstraction over a state machine which uses ifs" Yes, that's the 'sad' part of it. In the end there's the Intel/AMD/ARM chip and nothing more

Agreed, I wouldn't call ifs a code smell but rather OOP itself a code smell. In any decent language, if will be an expression, not a statement. There is no difference between if and a function.

Bootvis 14y ago

In what languages is if a function?

entropy_ 14y ago
LISP maybe?
jeremiep 14y ago
In Haskell/Ruby/CoffeeScript: a = if b then c else d In Lisp: (setq a (if b c d)) Only Lisp implements them as a function (more precisely, a macro), but to the programmer there's no difference between using if and calling a function. Of course, they don't compile into function calls in assembly code :)
- tarabukka 14y ago
  If is an expression in a lot of languages. The syntax you describe is identical to the "ternary statement" in C-style languages.
  - jeremiep 14y ago
    The ternary is an expression, not a statement :) You can write: a = b ? c : d; in C/C++, you can't write a = if(b) { c; } else { d; }.
    - tarabukka 14y ago
      Oh, yeah. My mistake. Although what you describe is a lot more functional in style. You could probably emulate it in a language with higher-order functions.
- adobriyan 14y ago
  It is called "special form". http://www.lispworks.com/documentation/HyperSpec/Body/03_ababa.htm http://www.lispworks.com/documentation/HyperSpec/Body/03_aba... IF can't be implemented as a function because of evaluation rules.
  - jeremiep 14y ago
    Ah, that is correct. You can't use if as a first-class function in Lisp. I still thought you could pass macros around like normal functions in Common-Lisp. The Lisp interpreter I wrote for fun could do that since the function value is resolved before arguments are evaluated for late macro expansions.
- Bootvis 14y ago
  Also R and I think were mostly in agreement here. However I'm of the opinion that more than just these languages (languages with lazy evaluation or macro's) are decent and that in for example Ruby there are differences between if and a function, as this example shows (my first lines of Ruby) def iff(cond, x, y) if cond then x else y end end puts iff(true, 1, puts('2')) echoes 2 1 if may behave as a function, but you can't write a function that acts like if. edit: R does have real lazy evalution, e.g. > iff <- function(cond, x, y) { if (cond) x else y } > iff(TRUE, 1, cat('foo')) [1] 1
- philwelch 14y ago
  There is a difference to the programmer, and it's pretty important as far as "if" goes: if "if" were a function, its arguments would need to be evaluated before they were passed in, which defeats the purpose of "if", which is to conditionally execute only one branch.
- tomjakubowski 14y ago
  You did say that only Lisp implements "if" as a function, but I thought I'd share that in Haskell "if" is syntactic sugar for a case expression. That is: if x then y else z is sugar for: case x of True -> y False -> z There have been suggestions to replace this sugaring with a proper "if" function, e.g.: if :: Bool -> a -> a -> a if True x _ = x if False _ y = y to remove arguably redundant syntax, but it seems unlikely that this change would happen. See more here: http://www.haskell.org/haskellwiki/If-then-else http://www.haskell.org/haskellwiki/If-then-else

meaty 14y ago

Oh yes we all live in the land of the ideal where everything is functional and has no side effects of course and we're blessed with parenthesis. There is a huge difference between an if and a function. Consider SICP where lazy evaluation is introduced (read it if you haven't). An if statement encompasses the lazy evaluation as a native concept whereas a function's arguments are always evaluated (assumption for now - please carry on reading). So consider an if statement as a control flow structure which automatically supports lazy evaluation and leaves the return semantics up to the user. This abstraction is clean from the highest level, right down to the CPU which uses conditional branching to perform the if operation. There is a 1:1 match all the way down. The function on the other hand does not natively support lazy evaluation and enforces the return semantics. You then have to apply a lazy evaluation mechanism over the top (another layer of abstraction!). This layer of abstraction conveniently ends up using conditional branching to perform the if operation when it gets to CPU level. There is not a 1:1 match all the way down. Big hint there: your functional if at the end of the day is just a compiler abstraction over a state machine which uses ifs. As for OO, the industry I think has decided who won that battle. But alas, no religious war is required. Use what tools work for you.

raverbashing 14y ago
But for functional programming there's lambda calculus. OTOH there's no "OOP" calculus "your functional if at the end of the day is just a compiler abstraction over a state machine which uses ifs" Yes, that's the 'sad' part of it. In the end there's the Intel/AMD/ARM chip and nothing more