Hacker News Reader

Comment by surement | Hacker News Reader

Biggest disadvantage for me comes when trying to implement a complex algorithm where the paper uses pseudocode that's imperative (which is almost always). In the best case you can implement parts of it functionally but when it comes time to put these together you will likely use some kind of loop, but that's not possible in "purely" functional languages.

Otherwise -- and in particular when coming up with algorithms -- I find it preferable for languages to be efficient with functional idioms (recursion, map, filter, etc.).

Edit: I understand that anything's possible in a functional language that's possible in other languages. My point is that conversion from imperative to functional can be complex and might not be worth the trouble, and that doing it purely functionally might defeat the purpose: it will be nearly impossible to read or incredibly inefficient.

View on HN

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.

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.

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

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

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.

> that's not possible in "purely" functional languages

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

Not to get all FP on you, loops and recursion are isomorphic. It is a hurdle to convert imperative code to functional code, just like the opposite, but it is unconditionally possible.

I'm aware of that. It's still not always trivial to implement.

Isn't it trivial to implement a loop via recursion?

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

I'm not sure how using such a loop wouldn't be "functional", since you're not updating anything. (I believe you get TCO, so it shouldn't be that bad performance wise.)

That's "functional", but I sure don't want to read it.

One of the things that I really love about Erlang, is that it unrolls loops and recursion like:

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

which is much cleaner than how the same code is presented in 99% of functional programming languages.

That's just a combination of pattern matching and tail call optimization. That code would look exactly this same in Haskell:

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

The 10 case would have to be first, or that's an infinite loop. Cases are checked in order. That said, the compiler will give you a warning about it.

Why?

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

...which in practice will look like...

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

The only annoyance is the slightly verbose lambda syntax for the test, but if you're using a function as a test, it becomes a smaller issue.

Python (well, sort of) and C (despite its numerous other flaws) have a special syntax that doesn't read poorly, yes. The code you just described reads awfully. It's line noise. One of the most important aspects of a programming language is encouraging code that can be trivially read by someone who is familiar-but-not-reflexive with the language and does not necessarily understand the domain well enough to be managing both application state and syntactic state. If I have to think about what the code's syntax means, I'm not thinking about the problem.

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.

Are you sure you've got it the right way around? For-loops in C are syntactic garbage. "This is what I'm used to" is not the same as "this is good."

Why not? "What I'm used to" will tend to win in most usability studies. Weird and unfamiliar are harder to use.

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.

For readability and conciseness you would most likely use a fold instead.

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.

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

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?

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

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.

> For readability and conciseness you would most likely use a fold instead.

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.

I ran into this exact problem and figured out you can fix it with StateT and Lenses. You can reproduce imperative code exactly, but in pure Haskell. You can even write things like for loops, no problem.

yeah but functional operations just abstracts imperative statements.. so your pseudo code is almost like a granular expansion of the eventual implementation

Reply on news.ycombinator.com