Unravelling 'if' statements | Hacker News Reader

Unravelling 'if' statements

snarky.ca

30 pointsazhenley38 comments

The real brain damage in most programming syntax is the distinction between expressions and statements. Expressions are all you need.

My favorite thing about rust is how it encourages you to keep `return` at the end of your function. `return` is one of the most annoying syntax elements to me because you mostly don't need it, and it kind of has "side effects" in a way that's not obviously visible in the structure of the function.

They are expressions in rust

    fn main() {
        let () = return ();
    }

You have just discovered Brainf*ck, where every control flow is implemented via while. `if (current cell) { ... } else { ... }` for example would have to be implemented like `temp = 1; while (current) { ...; temp = 0; current = 0; } while (temp) { ...; temp = 0; current = 0; }` (there are many other approaches [1]).

[1] https://esolangs.org/wiki/Brainfuck_algorithms#if_.28x.29_.7...

Seems weird to replace an if sentence with a while, since a while is just an if with two gotos isn't it?

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.

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.

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.

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

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?

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?

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

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

All CPUs have jump instructions. General purpose computation isn't possible without it.

Even 'if' / 'while' / etc. are syntactic sugar for 'goto'.

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

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

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.

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.

How could anyone believe that switch would work without evaluating its argument or branching?

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.

i avoid some ifs for perf.. but only when i can write something equivalent with like 1 line and certainly not a switch

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.

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.

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.

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

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

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"?

The idea behind this series of posts is to see how much of python, concretely, is syntactic sugar and how much is necessary. How much could you do with e.g. doing macro transformation on top of a minimal core?

The last post before this was titled: "MVPy: Minimum Viable Python".

So, since python doesn't have goto, you can't replace while with an if with two gotos (without adding a goto to the language).

You can replace an `if` with a while tho, easily.

Tbf python isn't exactly a language that's high in sugar to start with, it doesn't even have switch statements. Not sure why you'd want to take away even more until there's nothing usable left. People have the weirdest hobbies hah

No, but it has the `match` statement which is even better: https://docs.python.org/3/whatsnew/3.10.html#pep-634-structu...

I wouldn't exactly call something only available in 3.10 as something python "has". Most of us haven't moved past like 3.8 at best, some still using 2.7 for legacy stuff even.

Waiting for the solution that involves transforming Python code into an encoded Turing machine and implements a minimal UTM in some tiny subset of Python.

2 gotos?

  While:
    If X
      Stuff
      Goto while.
  //Outside of while statement

That actually shows two gotos (as you've written it) because the if is itself a goto, under the hood. The way to get it down to one is this pseudo-code:

    jump test
  loop:
    stuff
  test:
    test X
    jump if (not-equal/greater-than/less-than/etc) loop
    other stuff

It still uses two jump or branch instructions, but the loop body only uses one. It falls through if the test fails. In the case of a do/while it's the same except you remove the initial jump.

True, but The parents comment

>since a while is just an if with two gotos isn't it?

The if has to include at least one branch instruction so you already have 2 branches to play around with.

Plus python doesn't have a goto so my code is pseudo code so I don't think that you can declare it is a goto under the hood.

I would call an unconditional jump inherently different from a conditional one, i.e. both if and goto are primitives.

Of course on some machines everything can be predicated and the line between an if and a goto is blurred.

Then there are indirect jumps...

I can barely manage to keep nested if's straight... Trying to make sense of that is giving me a headache haha. I'm becoming a proponent of guard clauses, but its still a shift in thinking as it is. (also, first post here.)

Nested if's are a sign the code is bad.

Guard clauses are a good thing and you should use them.

goto's are good because the label documents why the path was taken.

There are two kinds of programmers, those that love programing as math and people that want to get shit done.

Reply on news.ycombinator.com