schveiguy at gmail.com
Tue Jan 7 01:45:21 UTC 2020
On 1/6/20 6:38 PM, Laeeth Isharc wrote:
> On Monday, 6 January 2020 at 21:05:37 UTC, JN wrote:
>> On Monday, 6 January 2020 at 19:40:10 UTC, berni44 wrote:
>>> b) Should we instead remove some of these? Probably std.zip is here
>>> the first candidate. (I put some work in it in the last few weeks,
>>> but it would be fine for me throwing this away.)
>>> It's on a gut level - just wondering, what you think about this.
>>>  https://code.dlang.org/packages/std-experimental-xml
>> IMO all except base64 could be removed. Putting everything into the
>> standard library made a lot of sense in the times before we got a
>> package manager. Nowadays it might be better to simplify the standard
>> library and just have XML, JSON, ZIP, CSV as "blessed" packages.
> Dependencies will be our doom. Whereas if you use something in Phobos
> then you have some confidence it will still build across platforms in a
> couple of years.
> It also seems to make sense to work on making code.dlang.org
> ultra-reliable before making it necessary to use libraries before doing
> even basic things.
Except you do need to depend on it to do basic things. Have you tried
Because something lives on code.dlang.org does not mean it is
unreliable. The reliability depends on the developer, not the platform.
I imagine vibe.d is going to be super-reliable for years, and it lives
H.S. Teoh also talks about arsd. This is also available on
code.dlang.org (though not exactly built for it), but the mechanism of
copying license compatible code into your project so you can maintain it
doesn't depend on it being outside of code.dlang.org. You can do that
with anything! D modules are pretty movable.
One thing that is common between these two projects (and Phobos as well)
-- They are both major projects with almost all their dependencies
included in the project. That is, the project moves together, so you
always have a cohesive "mini-standard" library.
The dependency problem really shows up when your dependencies depend on
dependencies that depend on dependencies that are all written and
maintained by various people. A great example of how this can be a
problem was the story of npm left-pad
There's something to be said about having things outside the standard
library not for the reasons of stability but for maneuverability. One
can easily add/improve/change projects that are outside the standard
library, but poor decisions in the standard library are sometimes stuck
there (see std.xml).
For file formats, or parsers, or really any kind of system that has
innumerable ways of solving the problem, I really think the standard
library is not where they should be. The benefits are cohesion with the
library, and usage by the library. But there are many ways to skin the
JSON cat. Especially when there's little reason for JSON to be included
in Phobos other than a place for it to be.
Oh, and I agree that reliability of code.dlang.org (or having dub more
immune to the web site going down) should be a high priority.
More information about the Digitalmars-d