What's wrong with using a framework that has a lot of dependencies?

Question

Hi, all.

I recently told a friend that I was starting to learn Catalyst (Perl) and he fairly strongly emphasized that because Catalyst has so freakin' many dependencies, I should use something like Rails instead.

Isn't that a good thing that there are a lot of dependencies? Doesn't that indicate a lot of code re-use? I understand that there might be more effort involved with installing the framework but are there any other disadvantages?

I will resume my Catalyst tutorial until I get some juicy responses. :-)

Answer 1

When there are version dependencies between components, you can find yourself backed into a non-working situation if you're forced to upgrade one component (say, for security reasons) before a compatible version of a dependent component is available.

That assumes you can get into a working state in the first place. It may be that if you try to use the current versions of all dependencies, you'll find that they don't play along.

The larger the number of dependencies, the greater the risk.

Rails isn't free of this problem, either. With every new Ruby release, there's a scramble to update instructions for how to get, say, database drivers built.

To be fair, this problem has trended towards "better" over time, albeit with bumps in the road.

Answer 2

My personal experience is that the more dependencies you have, the more versioning you have to keep track of, and this can lead to nightmarish situations. In particular, updating one dependency (due to a bug you want fixed, for example) can bring you compatibility issues with the other dependencies. As an example, I personally had a situation where gcc 4.0.3 worked with foo but not with bar (dependency of foo), and gcc 4.0.5 worked with bar but not with foo. Fortunately, 4.0.2 worked.

Also, more dependencies tend to point out at "Frankenstein's monsters" products, made of parts that were not designed upfront to play together. A well integrated framework is designed to play nice and consistent. This, of course, can be fixed by proper wrapping the differences.

Answer 3

There is nothing particularly wrong with this. The advantage of Catalyst is that its pieces can be used by people not using all of Catalyst. This means that there are more eyes looking at, and fixing bugs in, the critical parts.

The biggest complain I hear of is that it's annoying to watch all those messages go by in the CPAN shell as Catalyst is installing. The solution is to take advantage of your OS's package manager as you are getting started. On Debian, apt-get install libcatalyst-perl takes 15 seconds to install on a machine with no other Perl modules installed. 15 seconds. (A plain CPAN install is not difficult either, but I guess the standard CPAN shell asks you a lot of dumb questions, and that puts off the newbies.)

Don't worry about the dependencies, there are good tools for managing them, and they make the framework stronger and more flexible.

Answer 4

This is a subject I've seen postings about before. I've been meaning to write an article about it and have finally done so.

It is here: The Lie of Independence

I encourage you to read it. The gist is simple, though. The question is wrong. It's not 'Do you use an application or framework with lots of dependencies, or one that doesn't have them?'

It is: 'Do you use an application or framework that has lots of external dependencies, or one that tries to do it all internally?'

And the question that follows is 'Do you really have faith that the person or people writing this framework understand every nuance of every tiny detail of every task that needs to be done to process a web request?'