February 02, 2013
On 02/02/2013 02:42 PM, Joseph Rushton Wakeling wrote:
> I've on occasion had cause to call on ....
>
> A while ago I had cause to call on ....

Oh bugger.  Overly verbose _and_ repetitive. :-P

February 02, 2013
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
February 02, 2013
On 2/2/13 11:50 AM, Jacob Carlborg wrote:
> 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.

I agree with all of the above. While knowing very little about design of package managers, I really appreciate using such (either at Facebook or for other languages).

It would be really meaningful to the future of D if a strongly motivated expert in package management would want to propose what it takes to get us where we should be in that regard.

As a simple question - what would be an existing design that would be most appropriate for us to take inspiration from?


Andrei
February 02, 2013
On 02/02/2013 05:50 PM, Jacob Carlborg wrote:
> I can tell you this about Ruby. Its package manager, RubyGems, is one its
> greatest assets.

Don't get me wrong.  I'm not speaking out against a package library per se, I think that would be an excellent idea.  I'm just against the idea of narrowing Phobos' scope too strongly in favour of various things being provided by contributed libraries.

> Just because a library has many dependencies doesn't mean it's badly designed.
> It could just mean that it's flexible and modular.

I agree, but the example I was talking about really was just frustrating and opaque.

> 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.

No, I don't like the typical C/C++ library situation -- that's why I'd like to see as much functionality as possible in a well-designed and supported standard library implementation.
February 02, 2013
Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:

> No, I don't like the typical C/C++ library situation -- that's
> why I'd like to see as much functionality as possible in a well-designed and supported standard library implementation.

As d-newcomer I want to support this! A large standard library
is an  attractive  argument for the language because it makes
sure that its features will be supported as the language evolves.

Its organization is currently rather confusing and I suggest
to seriously think about a deeper nested structure like it has
been suggested for std.numeric: std.numeric.~, std.concurrent.~,
std.io.~ etc. The pain of transformation is once, to keep it,
it is recurring.

Peter
February 03, 2013
On Thursday, 31 January 2013 at 15:38:04 UTC, Don wrote:
> The current approach of putting everything directly into a single level in std doesn't scale very far -- it will look very clumsy once it gets more than (say) three times larger. This argues for SmallPhobos.
>
> But if it doesn't get to be at least ten times larger, some of this niche stuff shouldn't be in there, they are functions from LargePhobos. If we go with SmallPhobos then we need to move the niche stuff somewhere else.

I am all for a "small" Phobos. And specialized libraries in Deimos, which should get the same level of attention as Phobos.
February 03, 2013
On Sunday, 3 February 2013 at 07:43:57 UTC, SomeDude wrote:
> I am all for a "small" Phobos. And specialized libraries in Deimos, which should get the same level of attention as Phobos.

Huh? Deimos is specifically for C headers translated to D.

David
1 2 3 4 5 6
Next ›   Last »