Why functional programming?

I can appreciate your position, because I mostly write programs that model the physical world. The state is what you care about, and the state changes over time, and you have to solve for the state iteratively-- which means that the transition from state [i] to state [i+1] includes a bunch of intermediate guesses at the state. Furthermore, those state updates take place element by element-- you rarely update an entire vector at once, but rather update one or two elements at a time, based on calculations related to some item in the physical world.

In short, you have a vector of reals that you update over and over, one element at a time. This is simply not an operation that functional programming excels at (there is an idea in the functional programming community that the state of a system, because it is a snapshot in time, never changes, and that therefore it is appropriate to model this as a bunch of immutable vectors that stream along in time-- but in practice I don't find that a very powerful, or useful, abstraction).

So my reaction to functional programming, after reading a couple of articles and books, was "Huh, it's cool, but not that applicable to my work."

I can imagine how this also would be the case in embedded systems programming. My brother designs and builds robotic manufacturing systems, and from my limited experience looking over his shoulder, it sure looks like those systems are all about managing state transitions.

Nevertheless, there are a lot of powerful ideas alive in the functional programming world, and over time these have influenced the way I do things. At the most basic, when I design programs, I try to represent the lowest-level descriptions of physical processes as pure functions-- no globals, all state passed in as immutable arguments, and all results returned as numbers. I do find this style of programming easier to test, and to reason about, and that's one of the primary benefits of FP you hear about.

There are other things, too, like my approach to input and output, and how I think of certain operations as "maps" now, but I think you get the point. In the big picture, I'm scavenging for ideas, rather than adopting an approach wholesale. It's like reading about Extreme Programming, and shifting to test-driven development but not pair programming.

My advice would be, look to adopt FP ideas piecewise, rather than all at once. Look for the small ideas and approaches that will make your programming more clear, or easier to test, or easier to re-apply from one system to another. If you've put in an honest effort to understand FP, and you just don't see how any of it applies to your work, then don't worry about it. There's no need for you to "be convinced" of anything. It's about building up your toolbox of tricks that work for your application domain.

Totally agree on the hardware implementation.

Mutable state has two uses. First, when what you are modelling really has state the varies with time (e.g. real world stuff, UI stuff). Second, as a kind of optimization.

One good reason for learning FP is that you think more clearly about what mutable state you are using and why.

For example, OOP programmers tend to instinctively write

  obj.setX(x)
  obj.doG()
  y = obj.doF()

when it could be done as

  y = F(G(x))

They instinctively cache G(x) in case they need it later, even though this never actually happens.

Higher order functions is what made it click for me. Immutability, purity and the other stuff is nice, but certainly not mandatory to use FP.

The reduction in verbosity due to easier ways to approach things is what sold FP to me. Common patterns that I'd write several times in OO are easy to abstract in FP.

Tim Sweeny, of Epic Games (Unreal Engine) says that in their C++ codebase, 90% of loops are functional folds or maps.

I imagine the biggest issue, especially as an embedded programmer, is the lack of excellent optimizing compilers that let you write functional, but still obtain the same performance.

As others have said, immutability and referential transparency enable you to reason about your programs much more cleanly that you are generally able to in imperative code. Functional programming also forces you to think about problems in a recursive manner, which is inherently very valuable, as the idea of solving problems by recursion is extremely powerful. Take a simple problem like this: given k different denominations of coins, how many ways can you make change for n dollars? (This is a problem from SICP, which also seems to come up on HN a lot). The functional code for this is about 10 lines. I don't even know how you would solve this imperatively...

You may look at this example and think it's contrived, that "real world problems" aren't anything like counting ways to make change. But just because you haven't encountered it in your daily work doesn't mean that other people haven't, or that it's not valuable as a tool in itself. And ultimately, having conceptual tools for thinking about problems is always going to be a good thing.

Btw, I find it slightly amusing that you don't want "to write programs like I'm writing on a Turing machine" since imperative programming maps pretty directly onto TMs as a model of computation...but I digress :)

Well, some toughts are easier to represent in abstract algebra. Really.

Functional programming is too generical a label to make it possible to answer your question. It may apply to anything from C-like functions to no side effect languages, but I guess most people around here use the term to mean Lisp.

If that's what you meant, Lisp'll give you a huge amount of reflexivity that you can use to change the language so it better fits your problem. In addition, Lisp has a very simple environment, what makes it the go-to language when you must embbeb an interpreter.

Now, if you were thinking about Haskell, it has a very powerfull type system that helps creating bug-fre software, and makes type-driven programming possible. It also has explicit side effects, what makes it possible for the compiler to paralelize your program for you, and a quite good optimizer (but not as good as you'll get by manually writting low level code).

And there are plenty of other languages people call functional. Each of them have some interesting aspects that may be usefull for solving a problem. Again, it's a very generic label, and a quite old one, so that all current languages already adopt functional features - in consequence it's not a very usefull label.