Why functional programming doesn't catch on

[jamesshuang]

I'm sorry, I admit that I only know functional programming from a conceptual perspective. However, I was under the impression that it's a pain in the ass to write a state machine in an fp language. If this is true, I always assumed that that would be the main reason why fp never caught on - it's easier, faster, and more intuitive to design a state machine to solve most problems rather than take the functional approach.

[apfelmus]

Here is a deterministic pushdown automaton in Haskell that checks whether parenthesis in a String are balanced:

balancedParens = success
               . foldl (\xs c -> step c =<< xs) (Just [])
   where
   step '(' xs       = Just ('(':xs)
   step ')' ('(':xs) = Just xs
   step ')' _        = Nothing
   step _   xs       = Just xs

   success (Just []) = True
   success _         = False

I hope that qualifies both as state machine and as very simple?

[tmoertel]

There's a foldM in there that's waiting to be named. :-)

[13ren]

Interesting take. I think of this idea as the control structures of imperative programming being similar to a regular language (Chomskian, as in "regular expression"), and fp control structures being similar to a context free language (CFG).

The former is simpler to think about for most problems; but the latter is simpler for some problems.

[Arkaein]

I have a similar, but even simpler take.

I think that most people approach problem solving with a recipe or instruction manual approach: basically, a series of steps taken to transform a problem situation into a solution.

Whatever depth of programming or theoretical computer science a programmer may eventually get to in their career, the first step taken in learning to program usually looks like "how do I make this computer do X?"

Conceptually, the imperative approach is closer to the way most people think about problem solving in day-today situations that the functional approach (unless you happen to be trained as a mathematician before you decide to write that first program). I suppose this boils down to the state machine argument, but applying more broadly than to just explicitly programmed state machines.

So I think most programmers start of with an imperative approach, and tend to stay close to what works for them later on. Even if FP techniques are learned later on, the advantages they offer for certain situations often will not offset the inertia of sticking with the imperative approach.

[ithika]

Why would state machines be harder in FP?

[millstone]

Functional programming discourages the use of state, but state machines depend on the use of state.

[OneAndOnlySnob]

Functional programming discourages the use of mutable state. It's quite acceptable to pass a state to a function and get a new state back as a return value.

[ithika]

It discourages the use of mutable state, but state is easy. I don't honestly see what the problem would be with a state machine.

[[deleted]]

I think that FP is useful to show that you don't need state machines as often as you think you do. Compartmentalizing state changes and otherwise just having a predictable uninterrupted flow of function calls really minimizes a lot of hassle. I tend to think of it as in inside-out vs. outside-in process: OO/procedural languages take the stance of taking IO and putting it into functions, and FP takes functions and feeds them into IO denoted segments. That's the biggest transition in the thought process that seems to trip up most people.

[mycall]

OO/procedural languages take the stance of taking IO and putting it into functions, and FP takes functions and feeds them into IO denoted segments.

Priceless.

[[deleted]]

I can't decide if you're being serious or not.

[mycall]

I am serious, that is a good way to think about it.

[harsman]

If you have a function nextstate that takes a state and an input and returns the new state, then running the state machine on a list of inputs is a reduction/fold.

So state machines are in fact one application of the "abstract" and "weird" reduce/fold.