Are conditionals necessary in computation?

Question

I know this question might seem weird, maybe I'm just overthinking, but this is really troubling me because I've been a computer engineer for some time now and conditionals (if statements for instance) always seemed pretty clear and intuitive!

I mean, let's assume that I have a program which starts at

int main(int argc, char** argv) // in C

How am I supposed to know what is inside argv and argc? My old, intuitive answer: if statements. Using if statements, I would decide based on the input how to execute my program... I never considered any possibility other than having the input provided under this way, and I, as a programmer, could only mess with what is after the call to the program, with the input already defined. Hence I had no doubt that I needed to use conditionals.

I have ONLY 1 PROGRAM that needs to execute for ANY input and provide the right answers, hence I can't avoid if statements. It all seemed alright, for years now... until I started to think... Could there be other ways?

What if I had a different version of my program for each possible input? The operating system or the hardware could then call a different version according to the input. Then I thought – this would simply delegate the if statements to either the operating system or the hardware, respectively.

Then I even thought, what if the user had a different computer for each different input? I know this might seem really stupid, but I'm just trying to understand the "law" behind the need for conditionals in our physical world!

Also, in this last example it could be argued that the conditional would simply have to be executed in the user's brain (when he decides which computer to use based on the intended input).

Can someone give me some light in this subject? This is really troubling me :( maybe I've overthought things and now I'm paying the price for it...

Answer 1

One argument that conditionals are not fundamental to computation is that there are turing complete models of computation that don't use anything resembling conditionals. For example, you can think of the lambda calculus as an untyped programming language where the only operation is function application. There is no branching involved: all the computation is just taking the function's arguments, and substituting it in for all uses of that argument inside the function itself.

But, another way of looking at this is that any turing complete model of computation can simulate conditionals in some way. For example, a simple idea for branching in the lambda calculus is that "true" is a function that takes 2 inputs, an if branch and an else branch, and then returns the if branch $(\lambda x. \lambda y . x)$. Meanwhile "false" is a function that takes 2 inputs, an if branch and an else branch, and returns the else branch $(\lambda x. \lambda y . y)$.

Then, in the lambda calculus, a program like "if T then foo else bar" would be encoded like $(T)(foo)(bar)$, which is to say applying foo and bar as arguments to the function T.

Or, more trivially, every turing complete model can simulate the turing machine, which is a state machine (and thus evaluates based on a conditional at every time step).

Anyways, as for the more realistic models of computation that you are used to, one reason you need conditionals is because if you didn't have conditionals, every program you write would either loop forever or execute in O(1) ((where we consider the size of your program to be constant)). Think about it: no conditionals means no loops (unless you use an unconditional jump, but then you will just loop forever). But, without loops, each line of your program will be executed exactly once. Thus, every program runs in O(1). This essentially means you can't solve any interesting problems.

However, I would argue that the more fundamental issue here is that loops (or some equivalent, such as combinators) are fundamental for computation. If you remove the ability to make a "goto", then even with conditionals your language will not be turing complete (by the same argument: your code will simply execute along some control flow path exactly once then terminate in O(1), and not every problem can be solved in O(1)).