Re: RFC: A Perlesque Introduction to Haskell, Part One (draft)

[etcshadow]

I've always understood the difference between functional programming and imperative programming (maybe some people don't even know that imperative is the term for "not functional") is basically this:

• Imperative programming means just that: you are giving orders (or "instructions", if you want to put it nicely) to the computer.
• Functional programming is about evaluation. It's about getting answers to questions. "What is this thing squared?" "What is the representation of this data as a binary search tree?". It's not about doing things. Rather, it's about composing answers to questions. Things like ordering of events and even the passage of time itself (time in programs often being measured in terms of operations, or in terms of tracing through program execution one step at a time) don't really exist in functional programming.
• Probably the biggest direct consequence of this is that functional programming has no concept of "state", as imperative programming does. "State" being the current value of all the variables (or memory or disk or however you want to think about it) being used by your program. "Current" is an important part of that, because these values change over time (after all, you're giving orders like "set this variable's value to 5" all over the place), and as I said... there's not the same concept of time in functional programming.

Anyway, describing functional languages by noting some of their "common features" is really not the way to go. It's a philosophical difference, all the way.

(Granted, as you noted, there is a limited concept of "state" in LISP, and, in general side-effect can't be completely avoided or you'd have no means by which to perform I/O... but you're getting into details, there.)