Describing Functional Programming in Fewer than 25 Chapters

Ovid on 2006-05-27T00:09:05

I'm not a great programmer. Instead, I'm a good programmer who has two solid skills which make me valuable. I consider the business needs of my code and I can explain things well. The latter point, though, is bugging me right now.

Sometimes my non-programmer friends ask me about programming. I usually don't go into too much detail because watching them fall asleep over a beer is never fun. Every once in a while, though, they start to grill me about what it is that I actually do. Sometimes the concept of "programming paradigms" is discussed. I really have no problem describing to my friends what imperative, objective, and logical programming are. But what about functional programming? I think I understand it. I have a pretty good grasp of the basics and use functional techniques when I think they're appropriate, but how do I describe it in such a way that the average person would understand. I'm stumped.

I've learned a long time ago that if I can't describe things in simple terms, there's a good chance that I don't really understand what those things are. How would one explain functional programming to a non-programmer? Particularly, how would one explain this in an unambiguous fashion which doesn't lead to the question "how is that different from 'X'"?

---

An explanation I'm waiting to try out...

Alias on 2006-05-27T13:20:57

It would go something like this:

"In programming, there's only two things. There is Data, which is just numbers and words and other sorts of values. And there is Code, which are like really detailed instructions for really stupid people that will run really quickly.

The most basic sort of programming is called Imperative, which just mixes code and data together without any special rules, so you have to do all the work yourself.

Object-Oriented programming is where your data sort of automagically knows which code to use without you having to tell it all the time. So if you have some data that represents a Cat or a Dog and you want to say "be happy", one purs and the other wags it's tail.

Logic programming is where you mostly don't have code at all. You just say how bits of data relate to other bits of data, and the computer automagically works out the details.

Functional programming is where you mostly don't have data at all. You just say how bits of code relate to other bits of code, and the computer automagically works out the details when you actually want to do something. Also, functional programming is built directly on top of pure maths, so sometimes you can do funky things like have code that can mathematically prove it doesn't have any mistakes in it. So crypto people love it.

etc etc

Re:An explanation I'm waiting to try out...

chromatic on 2006-05-27T15:41:43

That's pretty good. It's a lot like what I planned to write.

Re:An explanation I'm waiting to try out...

Alias on 2006-05-28T08:35:31

On a side note, my basis for that is how I learned Objects and Closures.

First I learned imperative, which I think is the best, since "do this, do that, take this number and blah" makes sense to people.

Then I learned about namespaces, which makes sense, because of course you want to have function names and variable names that are seperated from each other.

The Objects are "when you bless a bit of data, it magically knows where the functions for it are".

And once you get objects, closures are much easier, because then "If an object is a variable that magically knows where its functions are, a closure is a function that magically knows where its variables are"

And from there, a continuation is "Like a closure, but as well as the variables it also remembers the call stack, which is what you see with caller()"

That's a very summarised version of the path I took learning Perl.

As for functional programming, from what I see of Haskell so far, it's kind of nutso. But then hey, it's a mathematician's language.

Audrey's talk teaches is in about the best order I've seen so far.

And monads ? :)

rafael on 2006-05-28T21:50:24

For functional programming, I also speak of time. Imperative programming relies on time: do this, then do that. Then, your data changes, and where there's changes, there's flow of time.

In functional programming, take away the data, then time disappears automatically: like in a mathematical formula, or a set of formulas. [With this additional remark, you can even hint at what are monads, as in "where time reappears, because some input is added to your program". Not a very accurate description, but a sufficient one for that purpose.]

Consider the blacksmith ...

drhyde on 2006-05-28T22:45:08

Blacksmith goes to pub, the conversation goes something like this:

Q: so what do you do then?
A: I'm a blacksmith.
Q: so what to you do then?
A: I fit shoes to horses, and occasionally mend broken ploughs.

at this point, if we were really talking to a blacksmith, the questioner finds something else to talk about. He doesn't want to know about heating and bending metal and stuff. But because he's talking to a programmer:

Q: so how do you do that?
A: I take bars of metal and heat them to make them softer, then whack them with hammers until they're the right shape.
Q: how does that work?
[blacksmith whacks idiot with hammer]

At the point the third question is asked, I say something along the lines of ...

" it would take far too long to explain, but I can demonstrate easily if you buy me a pack of pork scratchings. [pause] Thanks. Now, you have to remember that computers are very very stupid and only understand simple unambiguous instructions. A programmer breaks a task down into those simple instructions. This seems easy, but I now want you to tell me how to open this bag and feed you its contents. "

After you've poked his eye out a few times, run around the pub clucking like a chicken, put pork scratching in his pockets, and all the other creative misinterpretations you can think of for his instructions, he will understand that programming is, at heart, a masochistic exercise in frustration. Hopefully this will prompt him to buy you a beer.