Why functional programming?

Longer answer ...

There are several issues here, and many people conflate them. They are realted, and I'm not going to be able to do them justice in a quick reply here. It's Christmas Eve, and I have a lot to do.

So, briefly ...

Learning FP, really learning it, gives you a new insight into programming. It can change the way you work, and the way you think. If nothing else, it's mind expanding, and that's always a good thing.

There's a seminal paper "Why Functional Programming Matters"[0] (WFPM). It dates back to 1984, but it's still relevant. In fact it's so relevant that raganwald[1] wrote "Why Why Functional Programming Matters Matters." That's also a really good read, with many useful insights.

fogus[2] has included WFPM in his list of 10 technical papers every programmer should read twice.[3] There's also a StackOverflow discussion[4], probably several.

There are many, many programmers out there, capable, productive, useful programmers getting stuff done, but knowing nothing (significant) about FP. And that's fine. But personally, I think that if you want to be serious about your craft, you should learn about FP, what it is, what it's good for, how to think in it, when to use it, and when to avoid it. It's not the One True Style(tm), but it is

[0] http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html

[1] https://news.ycombinator.com/submitted?id=raganwald

[2] https://news.ycombinator.com/submitted?id=fogus

[3] http://blog.fogus.me/2011/09/08/10-technical-papers-every-pr...

[4] http://stackoverflow.com/questions/36504/why-functional-lang...

One bit of advice though; "trying it out" means getting to the point where you can actually "do things" with it, not running through two tutorials, filtering a couple of lists and writing a factorial function. That's the equivalent of learning how to write an if statement or a for loop or something, not the payoff. It's likely been a long time since you've actually felt like you don't know what you're doing, but that will be a sign you're on the right track.

You might also be interested in this: http://www.jerf.org/iri/post/2908 Being in the embedded world, you've probably just gotten used to certain things being "just the way it is" after 28 years, but one of the things that FP can show you is that those things aren't "just the way it is"; they are that way as a result of the choices we've collectively made. You've probably independently partially rediscovered a lot of FP's insights about state management over the years; you've probably also not independently pushed it as far as the FP community as a whole has. We don't actually have to live in a world where a flag flipped 25 million instructions ago is now causing a crash in seemingly unrelated code; we chose that world. It is not without its advantages, but it is not all gravy either.

In short: Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

Interestingly enough, I think the Blub Paradox greatly informs how pg views people too. You can be a "normal person" or you can be a "super smart person." Normal people can't understand super smart people because it's just beyond them. (part of the whole "people aren't created equal—some are just better than everybody else" selectivist philosophy.)

You dont have too,but if you like your job, you should be curious about stuff you dont know. Dont you want to learn how you could solve problems a better way?

FP tries to do that but with behavior, so that any given operation can be cleanly plugged into other behavior via function composition and higher-levels such as maps, folds and their math-ey equivalents functors and monads. FP is pipes. Stuff goes in, other stuff comes out, and we have an elaborate system of pipe ends to make sur one's out fits into the other's in.

OOP is good when a lot of persistent state has to hang around; objects in a game, objects floating around in a GUI window, client, transaction, product objects in a commercial application that must be created, viewed, modified, deleted. Boxes in a warehouse, bills and client data in boxes, running and shooting boxes in your Xbox.

FP is good when data has to come in, be transformed, and get out. Text treatment for example. grep is obviously made out of super-low-level procedural C, but it would be a perfect fit for the FP model: a bunch of text comes in, gets chopped into lines, a search algo is performed on each one, and it all gets spitted out, possibly into another, well, pipe. Compilers are also a nice fit: yet some more text comes in, it's chopped into a flat list of tokens, it's parsed into an abstract syntax tree, then into a type-checker, then a few other pieces of optimisation piping, and finally gets spit out as some other lower-level representation.

Server-side scripting is the most common real-life application of functional-ish langs; a request comes in, a few DB requests are made, the return values are chopped into HTML (or whatever mid-level representation then html), and that stuff is spit on the wire, which as far as it goes is isomorphic to a pipe.

Symbolic computing is a pretty sweet match for FP: some notation for an equation comes in, is turned into an expression tree, then into some standard form, then gets solved or integrated or whatever (recursive tree-walks all over the place), then turned back into a human-friendly form and spit back to the display.

Pandoc is a neat Haskell lib that takes some document format (LaTeX, HTML, markdown, whatever), turns it into a unified representation, then spits it back as another format.

JavaScript is funny because it totally embraces the fact that behavior is data, that pipes are also boxes. You give a callback to a handler, which then puts stuff like it as if were a pipe, and then you have functions that implicitly act on a global, implicit data structure (the DOM), some of them that take a description of where does one want to go in the DOM and returns a node of that recursively-defined tree, such that functions can still be chained and it's relevant to do so even if they're mostly used for their side-effects. JS is the weirdest and most wonderful thing. It even has JSON, which is the funniest example of the code-is-data ethos since LISP and it's exposed AST.

But yeah, it's in the nature of FP to not care about state, so it's normal that keeping state around in FP-styled programs is a pain. Passing a global data structure/container to a function that reaches down into the structure and returns a new, modified instance of that global and re-assigning the new into the old is just... Yuck. If a player gets killed in my game state, I want to just delete it from my player list, not replace my player list with a new one.

It's in the nature of OOP to see behavior as a second-class citizen to state. In patterns parlance, FP means using the iterator and the strategy pattern all over the place as they were themselves...

Why? Because I have the same questions you do, only I'm a much worse programmer/developer.

Insert Nike slogan here.

What's the worst thing that can happen by learning something?

1) functions as first class citizens (this is a great read that relates to this: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...)

2) immutable data: mutable state is the enemy of threading/concurrency/parallelism. Things can change underneath you in unexpected ways causing unforeseen consquences. When the data never changes, this sort of thing becomes much easier.

3) Referential transparency: This is related to #2. Whenever you pass A into function Z, you get B. There's no chance of side effects or other possible outcomes. A goes in, B comes out.

1. It's different, especially from what it seems you're already doing. Therefore it is likely that if you do FP in earnest, you will learn new problem-solving techniques, many of which will prove useful elsewhere.

2. In FP, the abstraction and composition model – functions – scales down farther than do objects, modules, or compilation units. That is, functions remain practical in smaller places where objects or modules would be too expensive to insert, syntactically or semantically. In FP languages, then, you can use abstraction and composition even within the "leaves" of your logic, and that's where the bulk of your code actually lives.

3. Functions have a mathematical basis that you can draw on for intuition. In some FP languages, the mathematical parallels are so reliable that you can even calculate the code you need. Calculation can work in places where main force of intellect and the search for "aha! moments" fail.

There you go, three reasons: it's different, it not only scales up but down, and it comes with useful theory.

So in general, forced immutable state means that any class of problems which require both high performance and a lot of mutation are going to be very poor candidates for functional programming. This is actually a large share of embedded programming and why the OP probably hasn't found that much use for it - embedded programming often comes down to accepting large amounts of data from sensors and manipulating it.

The problems where functional programming shine are where you have a chunk of data and need to create an answer from it. Given 10mb of data, should I do X or Y? Functional programming is a very good tool here because of aspects such as composability allowing for extra steps to be chained into a calculation, and immutable data ensuring that multiple steps can be run on the same data at the same time.

Hopefully that helps a bit in deciding when functional would be useful or less useful.

FP and OOP is not in conflict with each other and you can certainly use both. FP is more in conflict with procedural programming. With procedural programming you are teaching the computer how to do things step by step (for i while i < len i++). With FP, you declare what you want to be done, and the computer figure it out on its own on how to get it done. An example would be for each loop on a collection. You are not telling the computer to increment index. You just want to iterate each element. The computer is free to spawn 20 threads to iterate the collection, so long that it accomplish the goal of your expression.

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.

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.

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

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.

At least for the sake of thinking in another paradigm, having another «environment» to think about same issues.

I have scarce experience in functional language but AFAIK there are not only good for in->process->out like it's explained in other post.

Lately I've been studying the source code of Aleph, a web server written by Zach Tellman. Zach is a very smart guy, and reading his source code is an education (I've actually found this true of the majority of Clojure projects: the quality of the code is very good, and Clojure is the only language I've worked with so far where I have been able to learn so much reading the source code of the 3rd party libraries that I rely on).

Let's start with an interesting comment about Java, on StackOverflow:

Why doesn't more Java code use PipedInputStream / PipedOutputStream?

http://stackoverflow.com/questions/484119/why-doesnt-more-ja...

In response to that question, matt_b suggests this is part of the reason why people don't use pipedinputstream or pipedoutputstream:

"Typically, data is read from a PipedInputStream object by one thread and data is written to the corresponding PipedOutputStream by some other thread. Attempting to use both objects from a single thread is not recommended, as it may deadlock the thread."

So now, look at how PipedInputStream and PipedOutputStream are used in Aleph:

https://github.com/ztellman/aleph/blob/perf/src/aleph/format...

In particular, look at this function:

(defn channel->input-stream "Consumes messages from a channel that emits bytes, and feeds them into an InputStream."

  ([ch]

     (channel->input-stream ch "utf-8"))

  ([ch charset]

     (let [out (PipedOutputStream.)
           in (PipedInputStream. out 16384)
           bytes (map* #(bytes->byte-array % charset) ch)]

       (future
         (try
           (loop []
             (when-let [msg @(read-channel* bytes :on-drained nil)]
               (.write out ^bytes msg)
               (recur)))
           (finally
             (.close out))))
              
       in)))

On a different subject, I have learned a new style of programming by using closures in a functional language. Maybe I am a bit stupid, but it took me a long time before I began to realize how useful closures are. My only other exposure to closures was with Ruby and Javascript, but I never did concurrent programming with Ruby or Javascript, and it seems to me the greatest use of closures is when you are dealing with a lot of threads. When I first started writing Clojure code, I did not use closures at all. I wrote some clumsy code. For instance, I wrote a function that got some data from the database, and I wrote another function that stored that data in a hashmap in memory (using the memory as a cache) and I wrote another function that would check the hashmap for the data, before making the call to the database, and then I wrote another function that ran every 15 minutes and erased items in the hashmap, thus invalidating the cache. But then I realized I could combine several of these operations by creating a closure at the moment that I store data in the hashmap: the closure could call Thread.sleep(900000) and then delete the data from the hashmap. I found it convenient to create the closure while I was storing the data in the hashmap as, at that moment, I have all the ...

One of the perks of FP is that it exposes pure functions, functions that have a fixed output for a given input. Since it's really bad at storing and mutating state(canonically can only be done via monads), it encourages you to separate your code into pure and mutable states. Let's take, for instance, a function that reads a file and xor's that with a random byte stream. A non functional approach would be something like this:

  void xor_file_stream(file input, stream random_stream){
    result = []
    file_byte = read_byte(input)
    while(file_byte != EOF){
      stream_byte = read_byte(random_stream)
      res.append(file_byte^stream_byte)
      file_byte = read_byte(input)
    }return result
  }

  byte xor(byte b1, byte b2){
    return byte(byte b2){
      return b1^b2
    }
  }
  //Here I assume the language has file and random_stream as iterables
  void xor_file_stream(file input,stream random_stream){
    return map(map(xor,random_stream),input)
  }

But remember that most "pure" FP languages are bad at keeping state, turning a huge game(for instance) into a challenge both to the programmer and to the compiler.

[1] - http://en.wikipedia.org/wiki/Currying

[2] - http://en.wikipedia.org/wiki/Map_%28higher-order_function%29

EDIT: Formmating, not used to posting to hackernews comments

But with functional programming, I want to learn, but I have far less direction. Scala is perhaps the biggest, but still small. Haskell seems to be the most "hardcore", which appeals to me, whereas I keep anecdotally seeing people who like Ruby and Javascript (my two main languages) also tend to gravitate towards Clojure, and I can't explain why.

So far I've hated Scala's syntax and formatting (much like I hated Objective-C). Haskell is making my brain melt. Clojure seems quite simple and reminds me of my days writing Scheme in school. Any thoughts?