12 Apr
2011
12 Apr
'11
3:39 p.m.
On 4/12/11 6:18 PM, Richard wrote:
And people wonder why I tend to reinvent the wheel for most of my projects --
it's because I want to avoid such dependencies. This actually wins me users,
because it's less things for them to muck around with or maintain.
Dependencies are neither good nor bad, its how you use them that makes
it hell or heaven.
Oh Dear God. (dave's head explodes)
Nothing could be further from the truth. Dependencies constitute
overhead in the installation process, and each one, no matter how
"handy" it was for the programmer or how benign it was on the
programmer's system, is a potential problem source on the user's system.
They are to be avoided.
Code reuse, of course, is a good thing, if that doctrine is to be
believed. But raising the conceptual level of programming against a
specific platform by adding layers and layers of libraries to implement
higher and higher levels of black-box functionality is a very dangerous
path. It becomes a problem when those libraries aren't specifically
standardized by the definition of the platform.
This can be solved administratively, by deciding that, for example,
"WeenieDist Linux v8.62" will always include GTK+ v2.2.5 and never any
other release, and then a dependency is declared for that specific OS
release, becoming a "meta"-dependency (if I may coin the term) of sorts.
But no, the way dependency hierarchies happen in the Linux world (in
particular) these days is absolutely terrible, no good can come of it in
any way, shape, or form.
-Dave
--
Dave McGuire
Port Charlotte, FL
My pet peeve
are projects that drag in dozens of libraries, which then
drag in dozens more. Of course, these then conflict with other projects'
expectations, or screw up other already running builds.
"Dependency hell", the hallmark of software developed by clueless
and/or inexperienced people. Unfortunately it has become common.