The canonical paper one points at for "why should I care about functional programming?" is John Hughes, "Why Functional Programming Matters". Its examples lean towards the mathematical, though, and while they do show the sorts of things FP lets one do while avoiding the gruntwork an imperative version would require, not
showing examples of how to do the state-laden stuff J. Random Hacker thinks of as his or her bread and butter makes it easy to brush off FP as not being generally applicable.
Actually, if any Forth rubbed off +Vakkotaur
onto you, you have experience with a functional programming language, though it's strict rather than lazy. Forth was a concatenative functional language before concatenative functional languages were cool. (Concatenative corresponds to what Haskell users call "point-free" programming, where the source for a function never
names any of its parameters.)
Laziness, BTW, makes some things possible to write without magic, like short-circuit && and ||. C and C++ compilers have to have magic code buried in the compiler to not necessarily evaluate both operands. In Haskell, which is lazy, no magic required:
False && _ = False
_ && x = x
True || _ = True
_ || x = x
("_" matches anything of the appropriate type without bothering to evaluate it, and patterns are evaluated in order, so you get the short-circuit evaluation you expect.)
Other things laziness lets you write in a way that minimizes gratuitous coupling. Hughes gives the square root example; here's another. We all recall the old Fibonacci sequence benchmark with the function that evaluated the nth Fibonacci number about as inefficiently as one could--it was more a test of function call overhead than anything else. If you really were interested in the values for something, you'd remember what you'd already evaluated. Haskell's laziness lets you write a definition for the Fibonacci sequence that's the whole thing in one line--but since you'll never ask for the whole thing, it will evaluate up to the highest-number term you asked for, with no fuss.
Haskell type classes are kind of like "interfaces" in languages like Java--there's a type class for things you can check for equality, or things that have an order, etc. That's far from all they're used for, though--they let you set up a way to write clean code that handles errors without writing endless "call foo; if foo failed handle error; call bar; if bar failed handle error; call baz;..." sequences.
It does call for a different way of thinking about things; most notably, notions from abstract algebra and category theory will help. (I'm trying to go the other way around and use Haskell as a leg up on algebra, sort of the way I didn't really
understand integration by substitution until we went over Gaussian quadrature in numerical analysis class.
I'll look around some to see what people recommend for those coming to FP from an imperative background.worrydream.com - worrydream.com/refs/Hughes-WhyFunctionalProgrammingMatters.pdf