The bigger problem is that "something happening after something else" is not related to the idea of an if-then-else.

In Common Lisp the if-then-else construct is IF. The "something happening after something else" construct is PROGN. The whole point of if-then-else is that only one thing happens; "something happening after something else" requires a minimum of two things.

I don't really get your point. If/else expressions are in principle free to evaluate both branches, but that would be needless. But when we provide an IO Monad for example, if/else expressions will not suffice in the naive way -- you have to use the monad "bind" operation to actually provide an order -- what it boils down to basically: the A; B; C; in imperative languages become C(B(A())) in pure FP ones -- with implicit ordering.

> If/else expressions are in principle free to evaluate both branches, but that would be needless.

This is true only in a pure functional language; if you admit the existence of side effects, then it is a crucial part of an if statement that the code associated with the other branch is never executed.

My point is just that it makes no sense to say "some languages have no form of if statement; for example, Haskell doesn't have the concept of one thing happening after something else". That example is untrue. But if it were true, it still would not interfere with Haskell's ability to have an if statement. Thus, defending Haskell's ability to run one statement after another statement is unnecessary to refute the claim; the claim never worked in the first place.