On 2013-02-02 14:42, Joseph Rushton Wakeling wrote:
Speaking as a researcher, I've on occasion had cause to call on stuff
from such "2nd party" libraries, and it's not necessarily a happy
experience.
A while ago I had cause to call on a package in CRAN, the contributed
package archive for the R statistical programming language. It wasn't
one of the modules that's packaged for Debian et al., so I had to pull
things in directly from R's own package management and build and install
locally.
In and of itself, R makes this very easy, but what I wasn't prepared for
was that in installing the one package I was interested in, it would
pull in and install dozens of other CRAN packages. And then, when I
looked inside the code, actually finding out what it was doing was
nightmarish, because the module of interest was built on top of several
other contributions by the same authors. Understanding the code involved
a massive wild goose chase through all those other contributed modules
to find what functions were being called and what they did.
I don't know if this is typical of CRAN packages, because I tend to use
R infrequently, but my strong impression was of code that had been
built, thrown over the wall and then built on top of without any
attention to design, integration or performance (when I re-implemented
the algorithms using Octave/MATLAB they were much faster, and I doubt
this was down to the superiority of the language or interpreter).
And this code wasn't built by stupid people -- they were very good
statisticians. In their defence, I suspect the reason they built
higgledy-piggledy as they did was because they knew their earlier
modules _worked_ and reliability was the most important thing for them.
That's the cost of 2nd-party libraries -- they are very hit-and-miss in
terms of design, sustainability and hence, reliability.
Now, that said, I think a "2nd-party" repository for D could be a great
project, but what I _wouldn't_ like to see was that repository being
considered an adequate replacement for carefully designed standard
library functionality. One of the things I love about D is precisely
the breadth of Phobos' support, and it feels like the solution to
Phobos' problems is a better design and review process rather than
ringfencing a too-small set of core functionality.
Of course, a 2nd-party repository could be part of the prototyping and
experimentation behind new standard-library work, just as Boost is for C++.
I can tell you this about Ruby. Its package manager, RubyGems, is one
its greatest assets.
Just because a library has many dependencies doesn't mean it's badly
designed. It could just mean that it's flexible and modular.
When Ruby on Rails 3.0 (a web framework for Ruby) was released it had a
lot more dependencies than Rails 2.0. One reason was it was more modular
designed. They extracted package that could be used without the rest of
Rails, like ActiveRecord (database access), ActiveSupport (a general
utility package) and so on.
Do you rather prefer how most C and C++ library works. They all
implement everything from scratch. String classes, containers,
algorithms and so on. Or they bundle a third party library within their
own library forcing me to use it even though I already have it installed
out of the box.
--
/Jacob Carlborg
