std.fileformats?

[Steven Schveighoffer]

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.
>>>
>>> [1] 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 
using std.xml?

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 
on code.dlang.org.

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 
https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/

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.

-Steve