It's not about technology for its own sake. It's about being able to implement your ideas.
With the growing interest in a functional programming style, there are more tutorials and blog entries on the subject, and that's wonderful. For anyone so inclined to write their own, let me pass along a few quick tips.
Decide if you're writing a tutorial about functional programming or a specific language. If you're covering the feature set of Haskell, from the type system to laziness to monads, then you're writing about Haskell. If you show how to explore interesting problems and the executable parts of your tutorial happen to be written in Haskell, then you're writing about functional programming. See the difference?
Let types explain themselves. The whole point of type inference is that it's behind the scenes and automatic, helping you write more correct code with less bookkeeping. Don't negate that benefit by talking about the type system explicitly. Let it be silently assimilated while working through interesting examples and exercises that have nothing to do with types.
Don't talk about currying. There's a fascinating theoretical journey from a small set of expressions--the lambda calculus--to a more useful language. With just the barest of concepts you can do seemingly crazy things like recursion without named functions and using single-argument functions to mimic functions that take multiple arguments (a.k.a. currying). Don't get so swept up in that theory that you forget the obvious: in any programming language ever invented, there's already a way to easily define functions of multiple arguments. That you can build this up from more primitive features is not useful or impressive to non-theoreticians.
Make sure you've got meaningful examples. If you have functions named foo or bar, then that's a warning sign right there. If you're demonstrating factorials or the Fibonacci sequence without a reason for calculating them (and there are reasons, such as permutations), then choose something else. There are curious and approachable problems everywhere. It's easy to write a dog_years function based on the incorrect assumption that one human year equals seven dog years. There's a more accurate computation where the first two years of a dog's life are 10.5 human years each, then each year after that maps to four human years. That's a perfect beginner-level problem.
(If you liked this, you might enjoy You, Too, Can Be on the Cutting Edge of Functional Programming Research.)
permalink June 11, 2013
I'm James Hague, a recovering programmer who has been designing video games since the 1980s. Programming Without Being Obsessed With Programming and Organizational Skills Beat Algorithmic Wizardry are good starting points. For the older stuff, try the 2012 Retrospective.
Where are the comments?