Laeeth at laeeth.com
Tue Jan 7 03:48:04 UTC 2020
On Tuesday, 7 January 2020 at 01:45:21 UTC, 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
>>>> It's on a gut level - just wondering, what you think about
>>>>  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
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
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
> 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
I wonder what we could do about that. I could support if
resources would help.
More information about the Digitalmars-d