> Pattern matching and polymorphism is not allowed

Using dynamic dispatch on different functions of type Int -> Int is, precisely, polymorphism. Doesn't look much like the OO polymorphism that some people are used to, but FP folks use this kind of functional polymorphism all the time.

That being said, the main premise of the article is quite valuable: yes, you can program with no conditionals. And i think it's quite useful to know that polymorphism can be used like that without suffering too much of an unfriendly syntax (see lmm's comment on Smalltalk: http://news.ycombinator.com/item?id=5198419).

Finally, although pattern matching can be seen as an overpowered if-statement, the relation can be also turned around: the if-statement is a special case of pattern matching. I won't say that pattern matching is not conditional statements, but i think it's also quite valuable to notice that you can use pattern matching as a new programming primitive instead of the if-statement. For example, the if-statement implemented in Haskell:

  if :: Bool -> a -> a -> a
  if True  x _ = x
  if False _ y = y

Where I disagree with the author is in pointing out that there is no real difference between declaring "fib(1) -> 1" in a pattern matching function definition and inserting a pointer to a function that returns 1 into an array of function pointers. Pattern matching and subtype polymorphism can even still get all the gains the author is looking for--namely, being able to debug branching by inspecting the call stack. For that matter, so would pushing a dummy stack frame every time you come to a branch, or even building a separate branch stack.

Sorry, but "n < 2" is a conditional, whether you're using an if statement, the "?" operator, or to reference an array of function pointers (at least from this old-school C/assembler programmer's perspective). Whereas that Erlang code looks elegantly conditional-free. Clearly branching will appear behind the scenes, but the Erlang code has no conditionals.

    int res = (*fn[(n < 2)])(n);

So we choose our function pointer with:

    int res = (*fn[m])(n);

    uint32_t m = n < 2?1:0;

    uint32_t top_bits = n & 0xFFFFFFFEu;
    uint32_t p = 0;
    for (int i = 0; i < 32; i++){
        p |= (top_bits & (1u << i)) >> i;
    }
    uint32_t m = 1 - p;

You can do the for loop to check if any bits are set in logarithmic time. For general comparisons see http://stackoverflow.com/questions/10096599/bitwise-operatio...

Oh and the "i < 32" doesn't count as you could just unroll it...

[1] http://codon.com/programming-with-nothing

    if(a > b) {...code...}

    (a > b).ifTrue({...code...})

https://en.wikipedia.org/wiki/SKI_combinator_calculus#Boolea...

  #include <stdio.h>
  #include <stdint.h>
  
  void prettyprint(int a, int b)
  {
      int lt_mask = (a-b) >> (sizeof(int) * 8 - 1);
      intptr_t lt = (intptr_t)"%d is < %d\n";
      intptr_t ge = (intptr_t)"%d is >= %d\n";
      char *text = (char*) (lt & lt_mask) + (ge & ~lt_mask);
      printf(text, a, b);
  }
  
  int main(int argc, char **argv)
  {
      prettyprint(atoi(argv[1]), atoi(argv[2]));
      return 0;
  }

And if what you're interested in is using the call stack to keep track of executed code, a more effective approach would be to convert the program to CPS, see https://en.wikipedia.org/wiki/Continuation-passing_style and http://matt.might.net/articles/cps-conversion/ .

Let True = (λ x y => x) Let False = (λ x y => y)

Then to do an if, you just apply the conditional ((λ x y => x) 1 2) ---> 1 ((λ x y => y) 1 2) ---> 2

It's funny, really. Pure lambda calculus can feel a lot like a object oriented message passing style.

No, they are not. Having called functions instead of evaluating conditional statements doesn't change anything to the state of the [non-stale part of the] stack at the time you reach the breakpoint.

To achieve this one would need to execute the code following the branching (and containing the breakpoint) as callback of any of the "conditional" functions, so the followed branch would indeed appear in the stack. But that would just be impractical as you would reach stack overflow extremely quickly - not to mention the hit on performances.

    def prettyprint(a, b):
        fmt_string = {True:'%d is less than %d',False:'%d is higher than %d'}[a < b]
        return fmt_string % (a, b)

    def prettyprint(a, b):
        fmt_string = '%d ' + ['is higher than', 'is less than'][int(a < b)] ' %d'
        return fmt_string % (a, b)

It uses recursion, while a simple loop will suffice. Your fib(10000000000) will blow your RAM limit with growing stack (and will be slow) while implementation with loop would consume zero RAM and would run several times faster.

"And as if by magic, there's no need for conditionals" : also incorrect. You have a conditional in int res = (fn[(n < 2)])(n); specifically the (n < 2) part. All you have done after the hard work is moving conditional from one line to another.

"But we're still not sure of which branch we took." - So why don't you put the breakpoint before* the condition occurs, and step through it in the debugger??

After reading it, there's a chance I will use some of the insight I've gained in my Conception project.

Whether that's actually faster is debatable though. If you're writing in C, you're probably concerned about performance, and the function pointer invocation is going to be a lot slower than a branch mispredict. A sufficiently complex array dereference will slow it down too, but I wouldn't be surprised if the compiler can turn simple cases like this into an equivalent switch/jumptable.

Thus conditional-free programming (as presented here, in C) is mostly academic. Debug tracing is an interesting application, but readability and performance both suffer.

If a language could internalize conditional-free constructs natively, however, it could be an interesting study.