Why are IOC containers unnecessary with dynamic languages

Question

Someone on the Herding Code podcast No. 68, http://herdingcode.com/herding-code-68-new-year-shenanigans/, stated that IOC containers had no place with Python or Javascript,

Answer 1

I have a different opinion. I think IOC containers certainly have a role in dynamic languages.

I do not share the opinion that a language being dynamic removes the need for a clearly structured composition of objects. Or that a dynamic language 'provides' the same functionality.

An IOC container is simply a tool to manage this organization.

Even in a dynamic language I want to 'wire' together components. Without making hard dependencies between those components. Or maybe even without specifying the actual implementation class for those components.

Answer 2

IoC containers really allow for a compositional layer in statically typed, procedural/OO languages.

This compositional layer exists relatively naturally in dynamic languages such as Python or Javascript (consider that Javascript is heavily based on Scheme).

You could probably make a good argument that IoC containers are just a generalization of the Interpreter pattern.

Answer 3

IoC provides a mechanism to break the coupling you get when an object calls 'new' on another class.

It's naive view on IoC. Usually IoC also solves:

• dependency resolving
• automatic component lookup and initialization (if you use 'require' with IoC, there's something wrong)
• works not only with singletons but also with dynamic scope
• 99.9% of time it's invisible for developer
• eliminates need of app.config

full article You underestimate the power of IoC