[dxbydt]

or in scala:

    val snake = Map("name"->"Sammy", "dist"->"5m","move"->" slithers ")
    val horse = Map("name"->"Tommy", "dist"->"45m","move"->" gallops ")
    def move(m: Map[String,String]) = println( m("name") + m("move" ) + m("dist")

     scala> move (snake)
     Sammy slithers 5m
     scala> move (horse)
     Tommy gallops 45m

If FP = OO via dictionaries, then yeah, ok :))

[nivertech]

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):

    -module(animal).

    -record(animal{ 
                    name      :: string(),
                    distance  :: integer(),
                    move_verb :: string()
                  }).

    -spec move(animal()) -> ok.
    move(#animal{name=Name, distance=Distance, move_verb=MoveVerb}) -> 
      io:format("~sing... ~s moved ~b meters~n", 
                [default(MoveVerb, "Mov"), default(Name, "It"), default(Distance,1)]).

    -spec default(X::any(), Val::any()) -> any().
    default(undefined,Val) -> Val.
    default(X,        _)   -> X.

    -spec main() -> ok.
    main() ->
      Snake = #animal{name      = "Sammy",
                      distance  = 5, 
                      move_verb = "Slither"},

      Horse = #animal{name      = "Tommy", 
                      distance  = 45, 
                      move_verb = "Gallop"},

      [move(A) || A <- [Snake, Horse]],
      ok.