In regards to global vs local optimum it is useful to look at the alternatives like pattern matching.

For languages that don't support pattern matching or passing in functions as values, "if" is probably the best you can do with. You might be able to do something with boolean short-circuit operators but it's debatable if that that is better than the if statement.

In React, if you are using JSX, they don't have "if" statements within the markup they just use the boolean short-circuit (&&) operator.

For more ML style languages that support pattern matching, it is often easier to express solutions that way than with traditional if statements. In those situations I would say that "if" is less desirable in terms of expressive power and code readability.

Also, "if / else" only supports 2 cases, with pattern matching you can have an arbitrary amount of cases.

Without pattern matching, expressing more than 2 cases becomes a combination of nested if statements combined with "&&" and "||" expressions. This makes it much harder to read and write.

> Also, "if / else" only supports 2 cases, with pattern matching you can have an arbitrary amount of cases.

Coming from a non-pattern marching language (python) I’ve yet to see what the big deal is, maybe you can help.

I can have as many elif’s as I need cases and other than maybe not needing to repeat `x==...` I’m not sure what I’m missing out on.

With that being said, I do often wish for more elegant solutions to long winded if else

To get an intuition for the expressive power you can look up examples of quicksort and factorial in languages that support pattern matching. Haskell is a good example.

It is true that you can always just use if statements, it's more about the convenience and cleaner syntax. You can also do destructuring with pattern matching. Pattern matching is almost a requirement if you are going to use algebraic data types.

As Paul Graham says in Beating the Averages, you have to look at the other language from the perspective of knowing it. Nobody can really explain it. It's just going to seem equivalent or weird syntax otherwise.

Thank you for the thoughtful answer.

It made me rethink the premise of my question.

It is an interesting questions. My feeling is if-then-else falls some where between invented and discovered, something like mathematics. Once we had discovered the need for conditional control flow, any decent assembly language programmers would quickly discover many patterns for how it could be used. Eventually, these patterns were clarified and codified into languages and more abstract formalism. Like in much mathematics, that abstract formalism was am inevitable discovery once we took as axiom the basic logic of program control flow with conditional jumps.

It is such a basic, clear, and useful formalism, it is hard to imagine it not becoming widespread under some name/syntax.

But if-then-else is only clearly inevitable if you take as axiom the existence of store program computers with control flow. I can much more easily imagine that early on we invented a very different way to do computation as a whole. It seems likely that what we have actually invented is on a path toward a local optima.

Is pattern matching a generalization of if/then/else, a reframing of it, or something else entirely?

I see it as a cross between a switch and if statement. You’re saying based on what `x` is (a switch), do these things that a switch can’t do (an if).

If-then-else is pattern matching on a value of type Bool. I think of general pattern matching on algebraic data types as a generalization.

"if then else" is indicative of an underlying pattern that exists at a more fundamental level. In that sense, it was "discovered", not invented.

Depending on the language, the syntax of "if then else" is not needed and is syntactic sugar.

In the Lambda Calculus you can implement "if else" using "first" and "second".

Here is something equivalent in JavaScript.

  const trueFn  = (first, second) => first
  const falseFn = (first, second) => second

  const ifFn = (boolFn, first, second) => boolFn(first, second)
  
  ifFn(trueFn,  'yes', 'no')  // returns 'yes'
  ifFn(falseFn, 'yes', 'no')  // returns 'no'

Not truly equivalent!

let's define `delete(file)`, which returns 0 if it successfully deletes the file, and 1 if there's an error.

ifFn(trueFn, delete('A'), delete('B')) will not do what you want it to.

This is true. In a lazy language it is the same, in imperative languages that do eager evaluation it will indeed have the problem you mention.

I lean toward "if a b c" being a true primitive, due to it being one of the special forms in Lisp. This is necessary to avoid evaluating the arguments in the road-not-taken, without fexprs, and I daresay that would be a distraction at the moment.

It's also embodied in actual machine words. The actual verbiage of "if a then b else c" is clearly less important, C elides the "then" after all.

I'm presuming you mean the construct, not the happenstance of how it's spelled out, because you're clearly referring to the electron, not the word for amber-the-stone which we happened to adopt for it.

The historical truth is that Lisp had COND first; IF was added later. Also, LAMBDA before LET.

MacCarthy writes, in History of Lisp:

I invented conditional expressions in connection with a set of chess legal move routines I wrotein FORTRAN for the IBM704 at M.I.T. during1957-58. This program did not use list processing. The IF statement provided in FORTRAN1 and FORTRAN2 was very awkward to use, and it was natural to invent a function XIF(M, N1, N2) whose value was N1 or N2 according to whether the expression M was zero or not.

Yet, no such thing was added to Lisp, initially. The 1960 Lisp 1 Programmer's Manual only lists COND.

An interesting historical note, but it says nothing about the relative 'primitiveness' of COND vs IF.

It's not uncommon at all in mathematics to build a system with certain axioms, and then improve them later, when it's realized that simpler axioms can be used to build more complex constructs.

Either one of cond and if can be primitive and the other one a macro.

I wondered whether there was a conscious link in the minds of early language designers to Church encoding of booleans. (well, other than McCarthy and Lisp)

A Church boolean is either:

  true = λt.λf.t
  false = λt.λf.f

So instead of writing an expression with keywords like

  if bool then yep else nope

Just use the boolean as a function and apply it to the then and else clauses like

  bool yep nope

So the shape is very similar to modern languages, but with less syntactic scaffolding.

It underlies the decision tree model of computation: https://en.wikipedia.org/wiki/Decision_tree_model

>How do we know whether this choice was the global optimum vs a local one?

By letting anyone free to find a better alternative. Waiting...