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.
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?'
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.
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.
发布评论
评论（4）
这并没有什么特别错误的地方。 Catalyst 的优点是它的各个部分可以被不完全使用 Catalyst 的人使用。 这意味着有更多的眼睛关注关键部分并修复错误。
我听到的最大的抱怨是，在安装 Catalyst 时，看到所有这些消息在 CPAN shell 中经过是很烦人的。 解决方案是在开始时利用操作系统的包管理器。 在 Debian 上，在未安装其他 Perl 模块的计算机上安装 apt-get install libcatalyst-perl 需要 15 秒。 15秒。 （普通的 CPAN 安装也不困难，但我猜标准的 CPAN shell 会问你很多愚蠢的问题，这会让新手望而却步。）
不用担心依赖关系，有很好的工具来管理它们，并且它们使框架更强大、更灵活。
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-perltakes 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.
这是我之前看到过的一个帖子。 我一直想写一篇关于它的文章，终于这么做了。
在这里：独立的谎言
我鼓励你阅读它。 不过，要点很简单。 问题是错误的。 这不是“您使用的是具有大量依赖项的应用程序或框架，还是没有它们的应用程序或框架？”
它是：“您使用的应用程序或框架是否具有大量外部依赖项，还是尝试在内部完成所有操作？”
接下来的问题是“您真的相信编写此框架的人了解处理网络请求所需完成的每项任务的每一个微小细节的每一个细微差别吗？”
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?'
当组件之间存在版本依赖性时，如果您被迫在依赖组件的兼容版本可用之前升级一个组件（例如，出于安全原因），您可能会发现自己陷入了一种无法工作的情况。
这是假设你首先可以进入工作状态。 如果您尝试使用所有依赖项的当前版本，您可能会发现它们无法兼容。
依赖的数量越多，风险就越大。
Rails 也没有摆脱这个问题。 每发布一个新的 Ruby 版本，都会争先恐后地更新如何构建数据库驱动程序等说明。
公平地说，随着时间的推移，这个问题已经趋于“更好”，尽管道路上充满了坎坷。
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.
我个人的经验是，您拥有的依赖项越多，您必须跟踪的版本控制就越多，这可能会导致噩梦般的情况。 特别是，更新一个依赖项（例如，由于您想要修复的错误）可能会给您带来与其他依赖项的兼容性问题。 举个例子，我个人遇到过这样的情况：gcc 4.0.3 可以与 foo 一起使用，但不能与 bar 一起使用（foo 的依赖项），而 gcc 4.0.5 可以与 bar 一起使用，但不能与 foo 一起使用。 幸运的是，4.0.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.