4 ms·

For some strange reason there exists a subpopulation of developers who hate goto/if/switch etc. statements and feel compulsion to replace it with an equivalent

For some strange reason there exists a subpopulation of developers who hate goto/if/switch etc. statements and feel compulsion to replace it with an equivalent solution that does not use goto/if/switch even if this is done at the cost of readability. They red somewhere that goto/if/switch is bad and now mistakenly think if they only get rid of it their code will somehow be better. Which is sad and led to a lot of wasted time on my part trying to untangle their mess.

throwaway2j94 4y ago
goto/if/switch have their uses (especially in C) but I consider them low level and deprecated in favor of pattern matching, expression-based loops, and fmap / map/reduce combinators.
- twawaaay 4y ago
  Of course, I do prefer higher level constructs. Even then goto/if/switch are effective, readable solution especially if you use them within idioms. The problem is when people start replacing low level statements with other low level equivalents. Or low level equivalents that are masquerading as high level. Which means they did not understand why you may want to get rid of the low level construct and only caused loss of readability for no structural benefit.
- ok_dad 4y ago
  > 2022: "If/else considered dangerous." I never thought this would happen, does this mean I should quit programming? I feel like you can't get much done in a computer without branching in a CPU, but maybe I misunderstand modern CPU architecture.
  - moffkalast 4y ago
    Nah, if I understand the guy correctly it's not about the low level stuff. That's hardly going to change any time soon. But in terms of a logic development perspective I guess it may be clearer to set up something like instead of your average while(true) if (boolean) callback_function() put an async on(boolean,callback_function) or something and let the language deal with the low level implementation of it. Not sure why it would be "dangerous" to use the explicit definition, but we can maybe do a bit better in terms of clarity by removing the optimizable boilerplate?
    - anikom15 4y ago
      At least with the while version I have complete control over the loop. With the async version I have to figure out what the timing model is by reading documentation and assume it’s accurate. Async can make things easier but it’s not going to magically make code more maintainable. It’s hard to debug async problems. With a loop I can debug it on a sheet of paper. Choose abstractions and higher-order expressions when it makes sense to do so, not just to avoid low-level or ‘deprecated’ ones. I believe arithmetic ifs are higher-level than boolean ifs from the computer’s perspective, but you wouldn’t prefer that over a boolean if, would you?
  - lmm 4y ago
    > I never thought this would happen, does this mean I should quit programming? Yes. > I feel like you can't get much done in a computer without branching in a CPU, but maybe I misunderstand modern CPU architecture. Most CPUs have jump instructions, that doesn't mean it's a good idea to have gotos in your programming language.
    - ok_dad 4y ago
      > > I never thought this would happen, does this mean I should quit programming? > Yes. Not sure what I expected, I'll turn in my resignation effective immediately.
    - rep_lodsb 4y ago
      All CPUs have jump instructions. General purpose computation isn't possible without it. Even 'if' / 'while' / etc. are syntactic sugar for 'goto'.
      - lmm 4y ago
        > All CPUs have jump instructions. General purpose computation isn't possible without it. Technically not true, a Turing machine in the original sense only moves its head one position at a time (and I can imagine some early drum memory CPUs might have operated like that in real life). Of course one can emulate a processor that has jumps on a machine like that. > Even 'if' / 'while' / etc. are syntactic sugar for 'goto'. Structured programming is not just syntactic sugar; it gives you important properties that you can't get from using goto directly, hence why so many languages discourage or ban goto.
the_gastropod 4y ago
(Note: I don't think an aversion to `if` statements is the motivation behind the blog post here. Seems more an exploration into the minimum feature set needed in Python) If people are removing if statements at the cost of readability, I think they're probably bad candidates for replacement. The reason for removing if statements is (especially when deeply nested), they're very hard to reason about and test. Untangling these things (e.g., polymorphism) is intended to improve readability / understandability / ability to be changed. Everything in software engineering is a compromise—sometimes a simple if statement is a lot clearer than introducing polymorphism unnecessarily. Each case will vary.
Wowfunhappy 4y ago
Wait. People put `if` in the same category as `goto`? I understand the problems with `goto`, but I'd never heard a case against `if` before.
- naikrovek 4y ago
  there are lots of "experts" who will tell you that the branch for either outcome of an if can only be executed after the if condition is evaluated, and that therefore "ifs are slow; don't use if". I had a colleague once that would turn all his "if" statements into "switch" clauses because "no branches means it is so much faster" and people listened to him closely.
  - rep_lodsb 4y ago
    How could anyone believe that switch would work without evaluating its argument or branching?
    - naikrovek 4y ago
      if you believe the person saying it is an "expert", that's how. "i-am-an-expert" syndrome often seen in 24-yo "senior" developers with sizeable egos.
  - 8n4vidtmkvmk 4y ago
    i avoid some ifs for perf.. but only when i can write something equivalent with like 1 line and certainly not a switch
- moffkalast 4y ago
  Can't say about how impactful it is on a CPU, but if you're using them on a GPU you can run into serious issues of stalling out other cores with significant branching, since the same code runs for multiple data units at the same time and if all don't finish at the same time the rest in the batch will just sit around and wait until it's all done.
lmm 4y ago
I'll take a function that looks and acts like you'd expect over a magical keyword any day. Code that behaves consistently is worth a bit of overhead; it costs some readability in the small, but it more than makes up for it in the large.
jemmyw 4y ago
I don't have an aversion to if statements per se, but there's a logic to wanting to not over-use them or keep them out of code if possible: every code branch requires more work to unit test it. However, if you can restructure such that instead of using an `if`/branching you instead use whatever higher level structures the language provides then you only need to test the way it selects code to run is correct rather than multiple branches.
- flohofwoe 4y ago
  There's just two options: either you compute both branches and ignore one of the results, or you decide upfront which result to compute (both are valid strategies depending on situation, target hardware etc...). In either case, there's a pretty high chance that the compiler turns your code into either of those options anyway, no matter what the input source code looks like. But just hiding if statements and loops under some high level functional mumbo jumbo just makes the code harder to understand for humans, and for the compiler harder to remove all the layers of 'expressiveness' and 'abstractions'.
tester756 4y ago
yea, I've been reading those enterprise architects for too long and I've had mixed feelings about ifs too fortunately I've went into real world code bases that saved me from those ivory tower ideas like prefering OOP approaches over control flow instructions just because
Joker_vD 4y ago
I've once seen the following approach: do { SomeConnection *conn = conn_open(...); if (!conn) break; do { SomeSession *ses = sess_open(conn, ...); if (!ses) break; do { // ... } while(false); ses_close(ses); } while(false); conn_close(f); } while(false); The idea was apparently to use "break" instead of "goto fail" because goto is bad. P.S. Also, why is "connection" abbreviated as "conn", but "session" as "ses"?

throwaway2j94 4y ago

goto/if/switch have their uses (especially in C) but I consider them low level and deprecated in favor of pattern matching, expression-based loops, and fmap / map/reduce combinators.

twawaaay 4y ago
Of course, I do prefer higher level constructs. Even then goto/if/switch are effective, readable solution especially if you use them within idioms. The problem is when people start replacing low level statements with other low level equivalents. Or low level equivalents that are masquerading as high level. Which means they did not understand why you may want to get rid of the low level construct and only caused loss of readability for no structural benefit.
ok_dad 4y ago
> 2022: "If/else considered dangerous." I never thought this would happen, does this mean I should quit programming? I feel like you can't get much done in a computer without branching in a CPU, but maybe I misunderstand modern CPU architecture.
- moffkalast 4y ago
  Nah, if I understand the guy correctly it's not about the low level stuff. That's hardly going to change any time soon. But in terms of a logic development perspective I guess it may be clearer to set up something like instead of your average while(true) if (boolean) callback_function() put an async on(boolean,callback_function) or something and let the language deal with the low level implementation of it. Not sure why it would be "dangerous" to use the explicit definition, but we can maybe do a bit better in terms of clarity by removing the optimizable boilerplate?
  - anikom15 4y ago
    At least with the while version I have complete control over the loop. With the async version I have to figure out what the timing model is by reading documentation and assume it’s accurate. Async can make things easier but it’s not going to magically make code more maintainable. It’s hard to debug async problems. With a loop I can debug it on a sheet of paper. Choose abstractions and higher-order expressions when it makes sense to do so, not just to avoid low-level or ‘deprecated’ ones. I believe arithmetic ifs are higher-level than boolean ifs from the computer’s perspective, but you wouldn’t prefer that over a boolean if, would you?
- lmm 4y ago
  > I never thought this would happen, does this mean I should quit programming? Yes. > I feel like you can't get much done in a computer without branching in a CPU, but maybe I misunderstand modern CPU architecture. Most CPUs have jump instructions, that doesn't mean it's a good idea to have gotos in your programming language.
  - ok_dad 4y ago
    > > I never thought this would happen, does this mean I should quit programming? > Yes. Not sure what I expected, I'll turn in my resignation effective immediately.
  - rep_lodsb 4y ago
    All CPUs have jump instructions. General purpose computation isn't possible without it. Even 'if' / 'while' / etc. are syntactic sugar for 'goto'.
    - lmm 4y ago
      > All CPUs have jump instructions. General purpose computation isn't possible without it. Technically not true, a Turing machine in the original sense only moves its head one position at a time (and I can imagine some early drum memory CPUs might have operated like that in real life). Of course one can emulate a processor that has jumps on a machine like that. > Even 'if' / 'while' / etc. are syntactic sugar for 'goto'. Structured programming is not just syntactic sugar; it gives you important properties that you can't get from using goto directly, hence why so many languages discourage or ban goto.

the_gastropod 4y ago

(Note: I don't think an aversion to `if` statements is the motivation behind the blog post here. Seems more an exploration into the minimum feature set needed in Python) If people are removing if statements at the cost of readability, I think they're probably bad candidates for replacement. The reason for removing if statements is (especially when deeply nested), they're very hard to reason about and test. Untangling these things (e.g., polymorphism) is intended to improve readability / understandability / ability to be changed. Everything in software engineering is a compromise—sometimes a simple if statement is a lot clearer than introducing polymorphism unnecessarily. Each case will vary.

Wowfunhappy 4y ago

Wait. People put `if` in the same category as `goto`? I understand the problems with `goto`, but I'd never heard a case against `if` before.

naikrovek 4y ago
there are lots of "experts" who will tell you that the branch for either outcome of an if can only be executed after the if condition is evaluated, and that therefore "ifs are slow; don't use if". I had a colleague once that would turn all his "if" statements into "switch" clauses because "no branches means it is so much faster" and people listened to him closely.
- rep_lodsb 4y ago
  How could anyone believe that switch would work without evaluating its argument or branching?
  - naikrovek 4y ago
    if you believe the person saying it is an "expert", that's how. "i-am-an-expert" syndrome often seen in 24-yo "senior" developers with sizeable egos.
- 8n4vidtmkvmk 4y ago
  i avoid some ifs for perf.. but only when i can write something equivalent with like 1 line and certainly not a switch
moffkalast 4y ago
Can't say about how impactful it is on a CPU, but if you're using them on a GPU you can run into serious issues of stalling out other cores with significant branching, since the same code runs for multiple data units at the same time and if all don't finish at the same time the rest in the batch will just sit around and wait until it's all done.

lmm 4y ago

I'll take a function that looks and acts like you'd expect over a magical keyword any day. Code that behaves consistently is worth a bit of overhead; it costs some readability in the small, but it more than makes up for it in the large.

jemmyw 4y ago

I don't have an aversion to if statements per se, but there's a logic to wanting to not over-use them or keep them out of code if possible: every code branch requires more work to unit test it. However, if you can restructure such that instead of using an `if`/branching you instead use whatever higher level structures the language provides then you only need to test the way it selects code to run is correct rather than multiple branches.

flohofwoe 4y ago
There's just two options: either you compute both branches and ignore one of the results, or you decide upfront which result to compute (both are valid strategies depending on situation, target hardware etc...). In either case, there's a pretty high chance that the compiler turns your code into either of those options anyway, no matter what the input source code looks like. But just hiding if statements and loops under some high level functional mumbo jumbo just makes the code harder to understand for humans, and for the compiler harder to remove all the layers of 'expressiveness' and 'abstractions'.

tester756 4y ago

yea, I've been reading those enterprise architects for too long and I've had mixed feelings about ifs too fortunately I've went into real world code bases that saved me from those ivory tower ideas like prefering OOP approaches over control flow instructions just because

Joker_vD 4y ago

I've once seen the following approach: do { SomeConnection *conn = conn_open(...); if (!conn) break; do { SomeSession *ses = sess_open(conn, ...); if (!ses) break; do { // ... } while(false); ses_close(ses); } while(false); conn_close(f); } while(false); The idea was apparently to use "break" instead of "goto fail" because goto is bad. P.S. Also, why is "connection" abbreviated as "conn", but "session" as "ses"?