Asking the question 'what are the features of this thing' is a potentially very complicated question in a dynamic language. Each and every line of code could have added or removed a feature. Dynamic language make for very messy and unreliable computing.

>Does this object have a run() method? Does it have a color property? It doesn't matter what type it is..

Only it very much matters...

And to track it you have an ad-hoc, incomplete, custom, buggy, implementation of type checking in your head -- as opposed to in the program, and statically checked.

>Maybe it's a new kind of type that you could not have imagined when you first wrote the code, but if it supports the necessary method, it's going to work and you don't need to change or recompile your code to account for it.

You obviously need to change your code to have objects of that "new kind of type" (even if they are dynamic and untyped). Where would the new objects come from without changing the code in some place, the ether?

Supporting the necessary method is a very poor check for "it's going to work".

A "bomb" and a "lock" object might both have an "activate" method. You wouldn't want to call the former when you meant the latter.

You're still doing the same checks, only know you do only half of them, in your head, and whatever goes...

What you're describing is structural typing, and it doesn't have to be dynamic. Look at OCaml and its object model to see an example of a statically typed system with automatic type inference, that nevertheless checks all these things at compile-time. Which is to say, you can write:

   let frob something = something#run ...

and it will enforce the fact that whatever is passed to frob, it must have a method named "run", and it must have the requisite number of arguments and their types.

The types are still there, though. They're just types like, "some object with method "run" with ...".

In this case I would use something like std::function in C++. An std::function can also be unititialized and one can test for that using 'if'. Obviously, one does not want an inheritance hierarchy as complicated as the one you sketch. It does seem like a dynamic language maps a bit more direct to this problem. However, if one uses a dynamic language there still is the complication that there is not a single place with a list of all possible attributes that the Animal can have. This is one main pain of dynamic objects that one especially feels when one is trying to find out how something works. When something can potentially be any type one might have to read a great amount of code to find out what operations are available for that thing.

I also have to notice that this is not a very typical problem. I don't seem to remember that I have ever had to model something like this in a programming language.

"Doctor, it hurts when I do this"

"Don't do that then"

This kind of problem with using heavily inheritance-based systems for behavior can be addressed by using entity component systems. Often found in game development. The general guidance these days is to use "is-a" relationships less and "has-a" relationships more.

Thanks for this spec. Here's a complete, runnable implementation in OCaml:

    type walker = WalkFn of (animal -> unit)
    and  jumper = JumpFn of (animal -> unit)
    and  swimmer = SwimFn of (animal -> unit)
    and  intoxicator = ToxicFn of (animal -> animal -> unit)
    and  animal = Animal of animal_data
    and  animal_data = {
      name: string;
      color: string;
      mutable walk: walker option;
      mutable jump: jumper option;
      mutable swim: swimmer option;
      mutable intoxicate: intoxicator option
    }

    let can_walk = function
      | Animal { walk = Some _ } -> true
      | _ -> false

    let walk animal =
      match animal with
      | Animal { walk = Some (WalkFn walk_fn) } -> walk_fn animal
      | _ -> invalid_arg "this animal can't walk"

    let default_walker = function
      | Animal { name; color } -> Printf.printf "the %s %s walks\n" color name

    let allow_to_walk (Animal data) =
      data.walk <- Some (WalkFn default_walker)

    (* --- more of the same for the other actions --- *)
    let can_jump = function
      | Animal { jump = Some _ } -> true
      | _ -> false

    let jump animal =
      match animal with
      | Animal { jump = Some (JumpFn jump_fn) } -> jump_fn animal
      | _ -> invalid_arg "this animal can't jump"

    let default_jumper = function
      | Animal { name; color } -> Printf.printf "the %s %s jumps\n" color name

    let allow_to_jump (Animal data) =
      data.jump <- Some (JumpFn default_jumper)

    let can_swim = function
      | Animal { swim = Some _ } -> true
      | _ -> false

    let swim animal =
      match animal with
      | Animal { swim = Some (SwimFn swim_fn) } -> swim_fn animal
      | _ -> invalid_arg "this animal can't swim"

    let default_swimmer = function
      | Animal { name; color } -> Printf.printf "the %s %s swims\n" color name

    let allow_to_swim (Animal data) =
      data.swim <- Some (SwimFn default_swimmer)

    let can_intoxicate = function
      | Animal { intoxicate = Some _ } -> true
      | _ -> false

    let intoxicate animal victim =
      match animal with
      | Animal { intoxicate = Some (ToxicFn toxic_fn) } -> toxic_fn animal victim   
      | _ -> invalid_arg "this animal can't intoxicate"
  
    let default_intoxicator animal victim =
      match animal, victim with
      | Animal attacker, Animal victim ->
          Printf.printf "the %s %s poisons the %s %s\n"
            attacker.color attacker.name victim.color victim.name
  
    let allow_to_intoxicate (Animal data) =
      data.intoxicate <- Some (ToxicFn default_intoxicator)
    (* --- end of actions --- *)

    let create_frog () =
      Animal {
        name = "frog";
        color = "black";
        walk = None;
        jump = None;
        swim = None;
        intoxicate = None
      }

    let create_cow () =
      Animal {
        name = "cow";
        color = "green";
        walk = None;
        jump = None;
        swim = None;
        intoxicate = None
      }

    let story () =
      let frog = create_frog () in
      Printf.printf "newborn frog, can it walk? %s\n"
        (if can_walk frog then "yes" else "no");
      allow_to_walk frog;
      Printf.printf "and now, can it walk? %s\n"
        (if can_walk frog then "yes" else "no");
      walk frog;
      allow_to_swim frog;
      swim frog;
      allow_to_jump frog;
      jump frog;
      allow_to_intoxicate frog;
      intoxicate frog (create_cow ());
      Printf.printf "the end\n"

    (* now run all this *)
    let _ = story ()

And here's what it looks like when it's run:

    $ ocaml frog_story.ml 
    newborn frog, can it walk? no
    and now, can it walk? yes
    the black frog walks
    the black frog swims
    the black frog jumps
    the black frog poisons the green cow
    the end

It's true that the animal type must have types and fields for all possible actions an animal might ever take. It would be possible to compartmentalize things a bit more, maybe. But for a quick prototype this should work quite well, I think.

Use an Entity Component System (ECS).

The problem here is you have a complex inheritance hierarchy, right? So don't do that, use composition instead. It's super flexible. E.g. (OCaml):

    let create_frog () = object
      method color = "black"
      method size = 10
      method speed = 5
      method direction = 3.14
      method swim = print_endline "Frog swimming"
    end

    let allow_frog_to_walk frog = object
      method walk = print_endline "Frog walking"
      method super = frog
    end

    let allow_frog_to_jump frog = object
      method jump = print_endline "Frog jumping"
      method super = frog
    end

    let make_frog_toxic frog = object
      method intoxicate animal = print_endline ("Intoxicate" ^ animal)
      method super = frog
    end

    let frog = create_frog ()
    let frog = allow_frog_to_walk frog
    let frog = allow_frog_to_jump frog
    let frog = make_frog_toxic frog