Ask HN: Functional Programming Differences

I think numbers 2 and 4 are going to be the most valuable in introducing functional programming. I've been using Scala to learn functional programming, and the hardest conceptual pieces for me have been been staying immutable and using recursion.

Another point I'd consider is "avoid side-effects".

Programming with expressions (functional) vs programming with statements (imperative).

"Our programming model does not have to match how our computer works."

I think one of the biggest intellectual hurdles with functional programming is that we know, deep down, that modern computers don't work like that. They do have side-effects and changing, carried state. It's a revelation to realize that the programming model you use to write programs doesn't have to match how the computations will be physically carried out.

You might include something more explicit about function composition (e.g. the power of currying).

Closures might be another thing to mention. For instance, you could show how they can be used to implement objects (which should be familiar to C# people).

    f: R  -> R
       x |-> blah(x)

    f : (float -> float)
      = fun x  -> blah x

    o : (R->R), (R->R)  -> (R  -> R      )
        (f    , g    ) |-> (x |-> f(g(x)))

    o : ((R->R), (R->R) , R)  -> R
        (f     , g      , x) |-> f(g(x)))

I tend to avoid naked recursion whenever possible. It is not much better than loops. Combinators like foldr, filter and map reduce the cognitive overhead.

  splitAt :: Int -> [a] -> ([a], [a])
  splitAt n xs = (reverse before, reverse after)
    where
      (before, after, _) = foldl' incr ([], [], 0) xs
      incr (ys, zs, m) x | m < n = (x:ys, zs, m + 1)
      incr (ys, zs, m) x = (ys, x:zs, m + 1)

  let slice l b e =
          let rec slice_2 l b e f =
                  match l with
                  [] -> f
                  | h::t -> if (b<2)
                          then
                                  if (e>0)
                                  then ( slice_2 t b (e-1) (f@[h]) )
                                  else f
                          else
                                  ( slice_2 t (b-1) (e-1) f )
          in
          slice_2 l b e [];;

How about using an application to illustrate the power of FP. Combinatorial parsers are a neat non-trivial, but (hopefully) understandable, choice.

Functional programming make testing easier. Functional programming make threading easier. Functional programming make understanding things easier. (i.e. easier to understand something that will never change vs understanding all the possible permutations of something)

(Sorry for my bad english)

My version would be slightly bigger-picture (some are the same as yours, though):

- Functional design is about breaking a problem up into a series of transformations (functions) on data, rather than modelling object states and behaviors.

- Compose the transformations by treating functions as first-class citizens. Introduce map, filter, foldr, etc. here

- "Functional" = Avoid side-effects! (wrap an I/O layer around your pure core processing instead) Otherwise the composing breaks.

(optional):

- "Start little, grow big", "factor relentlessly" - these are good concepts in ALL programming, and they apply here too.

I think if you just get those points in an hour, along with a nice example (I think F# comes with a web crawler that illustrates all these points), you'll have done very well.

I'd focus really heavily on "stay immutable", "use recursion", and lambda functions. I think these things take a little effort to get used to, especially if you are stuck heavily in a certain programming paradigm as many Microsoft focused guys often are.

"stay little, grow big" is probably one of the less-appreciated points there and I'm exuberant that you noted it. It's also something that they likely won't encounter until they've actually tried writing something more open-ended in a functional language, like a full-blown program of any sort. It's like telling people to use MVC for a GUI. Important to mention it, but it's going to take some experience before it's down pat.

I think that there is a stepping stone, half-way between "talk" and "code". I remember a question on comp.lang.lisp. A student had the task of writing a "sublist" function, for example, (sublist (a b c d e f g) 3 2) => (d e). He task was to do it functionally and he was stuck.

But would supplying code unstick him? It seemed unlikely. Thinking about the equation "Concepts + details = code" I wondered if there was a way of conveying the concepts first, before getting down to the details, and wrote:

Put on your Dijkstra robe, and sit in your arm chair, with a cup of tea, and write on a pad of paper, made from dead tree, using a pen with real liquid ink. This is mathematics not computation :-)

    (sublist (a b c d e f g) 3 2) = (sublist (b c d e f g) 2 2)
                                  = (sublist (c d e f g) 1 2)
                                  = (sublist (d e f g) 0 2)
                                  = (d . (sublist (e f g) 0 1)) 
                                  = (d e . (sublist (f g) 0 0))
                                  = (d e . nil)
                                  = (d e)

compare this to peano arithmetic

    (- 7 3) = (- 6 2)
            = (- 5 1)
            = (- 4 0)
            = 4

If you want to learn recursion you should move quite quickly to writing code because that animates your recursions and clears up any lingering misconceptions. On the other hand, jumping from the words "learn recursion" direct to code is a big leap. Recursion has its own soul, separate from its embodiements in various programming languages.

"Treat functions as first class citizens"

Actually, Object oriented programmers already do this. If they use "class polymorphism", "mixins", or any mechanism where an object's method could be determined at runtime, they use first class functions. They just don't know it yet. So, take an example where they would use mixins, then present them a closure or lambda equivalent. That should make functions less scary. (Side note: try to avoid the terms "first class" and "anonymous", "closure", and "lambda". "Ordinary" and "literal" are better, less scary. They point out the fact that functions are as mundane as integers, or strings, so of course they could be parameters or return values.)

"stay immutable"

This is indeed crucial. But effectively impossible until you don't change the way you think. Most imperative programmers think about what the objects should do. Of course, without side effect, they won't do anything, making programming impossible. So they have to think more about what the objects should be. Then, they will be able to avoid side effects until they are really needed.

"factor relentlessly"

Talk about that only when you have talked about functions (don't say "first class"!), as an example of how you could really use them. `sort`, `map` and `filter` would be my favourite examples. Insist on the low syntactic burden of factoring.

OT: I fit the profile of your target audience. So, if you don't mind, please post your slides after your talk. Thanks.

I would stress composability (which fits in with that whole DRY fad).

Also, the ability to reason about your code is a big selling point of side-effect free code. When you don't have to keep track of a bunch of state in your head, it's much easier to reason about what code does, and find any bugs or unexpected behavior.