It's the mindset, not the implementation, that actually makes functional programming so valuable a tool.

Anyway I agree with the overall sentiment, and will check out the talk you linked. There's another good one along similar lines: "The Clean Architecture in Python" by Brandon Rhodes: http://pyvideo.org/pyohio-2014/the-clean-architecture-in-pyt...

Yes, but, say, in Haskell, that's not an option.

It's useful to note that Haskell is usually touted as efficient, and lack of efficiency is a #1 concern around functional programming. That concern I personally find revolting: Haskell is slower than C, yes, but orders of magnitude faster than many widely used languages.

    forM_ [1, 2, 3, 4] $ \n ->
        print n

Haskell does have the ST monad, which lets you encapsulate a non-pure algorithm (as in, one that relies on mutable state) within a pure function.

In fact, any monad will let you write imperative looking code (whose behavior is determined by the semantics of the particular monad), the standard library even provides for and while loops as functions.

You can also look at OCaml, which is very clearly a functional language, but has 1st class support for side effects and loops.

I'd say you have at least three fairly straightforward options.

1. Mechanically translate the loop to a recursive call. Not always idiomatic, but easy and pretty much guaranteed to compile to the same/similar assembly for a tight loop.

2. Use StateT and lenses. Your code can even look almost exactly like C if you want, with for and while loops with the same semantics as in C. I often use this when implementing heavily imperative papers in Haskell. It's still pure and everything, but looks just like an imperative language and performs well (if maybe not always full C speed).

3. If for some reason neither of those approaches work (e.g. If you're writing an algorithm that really benefits from mutation), you can use IO or ST for mutable variables. ST is really cool; it provides local mutability, but uses the type system to ensure that mutability never "escapes" into pure Haskell.

I am no Haskell expert and that sounds quite interesting. Do you have any links to examples?

Here's a fairly in-depth analysis of the approach: http://www.haskellforall.com/2013/05/program-imperatively-us...

The gist of it is that StateT gives you nice syntactic sugar around state-update functions of type `state -> (state, result)`.

Let's say your state type is like

    data Boss = Boss {
        health :: Int,
        ...
    }
    
    data Player = ...
    
    data State = State {
        boss :: Boss,
        player :: Player,
        ...
    }

    boss.health -= 1
    player.stats.score += 5

Unless you make the mistake of using a String, in which case it will be orders of magnitude slower than any widely used language.

> Yes, but, say, in Haskell, that's not an option.

Sure it is! It might not be a "for" loop or a "while" loop with a "for" or "while" keyword, but a tail recursive function is a loop, and pretty much every loop in an imperative language can easily be translated into a recursive function in a functional language.

> any loop can be turned into a recursive function so long as your stack is big enough, even if they're usually hideous

What amuses me to no end is how TCO turns around and converts that recursive function call right back into a loop before executing it.

And this summarizes my thoughts about the main disadvantage of functional programming - you're working against the way the computer fundamentally works, and relying on the compiler to get it right.

To be clear, it's always possible in a purely functional language, just not always reasonable or efficient.

As far as your point goes, I totally agree. There are algorithms that are better suited for functional languages (ones that involve tree's and lists) and there are algorithms that are better suited for imperative languages (disjoint sets, hashing algorithms, lots of graph algorithms).

    loop fn cond update i acc:
        if (cond i):
            return acc
        else:
            return loop fn cond update (update i) (fn i acc)

  count_to_ten(n) ->
    count_to_ten(n+1);
  count_to_ten(10) ->
    done.

    countToTen n = countToTen (n + 1)
    countToTen 10 = done

The fold/or Foldable interface factors out the mechanism of the traversal of the relevant data-structure - list, vector, tree etc.

Functional languages are an improvement in this respect over C/C++/Java etc with their explicit loop iteration statements.

Agree strongly with this. Long complex for-loops in imperative languages that are mutating a counter along the way, building up a list along the way, have "if (...) { continue; })" parts, have nested loops etc. make me cringe now.

Break your code up into a series of folds, maps and filters and it's miles more readable. I find a lot of imperative programmers just don't think in this way and mangle folds, maps and filters into one big confusing ball.

Not to put too fine a point on it, but Smalltalk had folding way back when (inject:into:). Higher order functions are not a specialty of functional programming; technically, even C has higher order functions, they're just more verbose because C doesn't support inline closure literals.

So does an iterable/enumerable in anything else (writing a red-black tree that supported the Iterable interface in Java was something I did in college). Certainly not a material improvement over explicitness that, unless you have a rather particular shop, your fellow programmers won't have to scratch their heads about three weeks after you commit it.

I have been the too-clever-by-half developer before. It was a bad idea. The principles of functional purity as a design goal do not have to have the baggage of "look at this neat thing I know about," yanno?

I'm genuinely curious why you think that it's worse in functional languages than, eg Python or C.

It's not like you don't specify all of those variables when using a loop in C -- you just have a special syntax to. I was outlining the actual recursion mechanism, not showing what you'd have to code....

You can make it look basically the same, with a signature like...

    loop (idx test update) fn acc

    loop (0 (\ x -> x < 5) (+1)) fn 0

And, frankly, the idea that you have to soft-pedal it as "you could do this" should be a red flag for you. I could meditate about a `loop` function or I could write the code I actually care about.

Looking at how human languages work, it's hard to see how it could be otherwise. Your own language is always going to be easier to use than an unfamiliar one.

And this is why language debates can't be settled via logic alone.