std.fileformats?

[Laeeth Isharc]

On Tuesday, 7 January 2020 at 01:45:21 UTC, Steven Schveighoffer 
wrote:
> 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?

Yes, and I didn't persist for long.

I wonder if sometimes there can be a tendency to let the best be 
the enemy of the considerably better.  I think you made an 
argument for replacing std.xml rather than XML not being in the 
standard library.  Though maybe that's a better argument than for 
getting rid of JSON and CSV.

> Because something lives on code.dlang.org does not mean it is 
> unreliable. The reliability depends on the developer, not the 
> platform.

Yes, I agree, but people are wired different ways and learnt to 
program in different eras and the cognitive cost of figuring out 
if a code.dlang.org library is any good is much greater for some 
people than others.  You don't even know if the project will 
build with the current release of DMD.  That mostly doesn't 
bother me personally, but it definitely does bother others.

"The reliability depends on the developer, not the
> platform."

I don't agree with this.  Phobos will probably work on BSD or 
smartos or whatever.  And quite well-written libraries may 
require tweaking to build even on 32 bit Windows.

And when you have a reasonable number of dependencies there is 
always something breaking with new releases so the cost may not 
be trivial for larger projects.

> I imagine vibe.d is going to be super-reliable for years, and 
> it lives on code.dlang.org.

Maybe.   I am very grateful to Sonke for his contribution but 
vibe is one of the projects that breaks frequently and you can 
get into a mess where you need newer versions of the compiler for 
other reasons and vibe doesn't compile.  Plus dub often can bring 
in dependencies spuriously, though that's a different problem.

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

I like arsd and think we should use it more internally.  It's 
pretty different though from having a module in Phobos, 
particularly if you want to get people who don't know D to use 
it, all the more so if they don't consider themselves programmers 
by trade.  It can be too much to absorb in one go.

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

Yes I agree but isn't that an argument for adopting a better one 
as part of the standard library?

Undead could also be more widely publicised and dub could be 
educated to ask if you want to fix old code by updating 
references.


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

A sensible default doesn't stop you from using something suited 
to your particular needs.  It also saves time and cognitive 
effort to know what to expect when reading code.


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

I wonder what we could do about that.  I could support if 
resources would help.