Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Friday May 26, 2006
07:09 PM

Describing Functional Programming in Fewer than 25 Chapters

[ #29731 ]

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'"?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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 co
    • That's pretty good. It's a lot like what I planned to write.

      • 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, becau
    • 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 sufficie

  • 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 wha