I am not a fan of CoffeeScript for my own reasons (it doesn't offer enough for me to drop drop JS), but there is nothing stopping the author from writing his CS like so:
move = (aDistanceOf) ->
it = @name or "It"
alert arguments[1] if arguments[1]
"#{it} moved #{aDistanceOf} meters"
snake =
name: "Sammy"
horse =
name: "Tommy"
move.call snake, 5, "Slitering"
move.call horse, 45, "Galloping"
But really, this is just JS wearing some new clothes. The string interpolation is nice, but apart from that, you really gain nothing over the JS version.
Dude. Really ? You've just invented objects, but you'd rather not call it that. You have two attributes ( name & distance ) and you've made an attribute out of the method ( move_verb ?! heh heh ) as well, very clever. You are then calling a function & asking it to sort it all out. If we are going to call this FP, that's a real stretch. What objects buy you is that name,distance & move_verb are common to both snake & horse, so they should be refactored to some base class & then snake & horse should be instances of that class. But then you won't do OO, so you must encapsulate in this roundabout fashion:) I'll grant it does give you FP + encapsulation.
shiffern's example uses the same coding style you use in Clojure. It doesn't feel like stretch to call it FP. Start with a basic data structure (the object in shiffern's example would translate to a map in Clojure) and then operate on it with simple functions.
The example given by author is very FP and not OOP, since the move function doesn't modify shared state and the only side-effect is output.
We use CoffeeScript for node.js and browser client code. I think classes more useful for control patterns, like EventEmitter in node.js, and much less for wrapping of data, as done in traditional Java/C++ -style OOP or ORM models.
I'll chip in Erlang (real production-grade code with type-specs, not a short REPL example):