Hacker News Reader

Comment by eropple | Hacker News Reader

If what you care about is "everything is a beautifully curried function that actually doesn't do anything", the concern about loops is definitely a thing (but any loop can be turned into a recursive function so long as your stack is big enough, even if they're usually hideous). But pretty much everybody I've ever worked with considers functional purity in the logic layer to be "functional programming" at its most useful (Gary Berhardt's functional-core, imperative-shell talk is a good one). Is it easier to write with a loop? Then use a loop! If that loop is contained in a pure function that has no side effects and encapsulates something that isn't the most beautiful crystalline code formation anybody ever did see, nobody cares.

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

View on HN

The concern about stack space is slightly misleading since many languages, i.e. Scheme, can easily optimize such functions to use O(1) space by reusing stack frames across recursive calls. The problem is that while Scheme guarantees this tail-call optimization in the spec the are many other languages that leave it up to implementation, or intentionally omit it because they don't want to lose stack traces.

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...

Functional API, efficient implementation. It's always a good rule of thumb

> Is it easier to write with a loop? Then use a loop!

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.

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

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

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

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.

> in Haskell, that's not an option.

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.

> 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).

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

Shoot, I had some great example code from a few years ago but it was part of a uni assignment so the university made us take it off github.

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,
        ...
    }

Using Lenses, you can construct StateT operations like this:

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

Where each of those updates the state as you imagine. So your code just looks like a bunch of stateful OO-style updates, but it's actually pure. This also lets you do a bunch of cool stuff that you can't do with real imperative code in this fashion, like re-interpret the semantics of assignment or modification, but that's for another time.

> > Is it easier to write with a loop? Then use a loop!

> 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.

> Haskell is slower than C, yes, but orders of magnitude faster than many widely used languages.

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

Something of a tangent, but:

> 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.

It's not that silly, really. The same argument could be made regarding GOTO. The compiler can't really avoid turning everything into jumps, because it's all the machine understands. And yet structured programming is hands down far more advantageous for the human who has to be able to reason about the program at the end of the day.

YES. Functional programming is more of a pattern. I can write functional ruby/es6, but neither of those are purely functional languages.

Reply on news.ycombinator.com