Vision for the first semester of 2016
Ola Fosheim Grøstad via Digitalmars-d-announce
digitalmars-d-announce at puremagic.com
Thu Jan 28 01:16:50 PST 2016
On Wednesday, 27 January 2016 at 21:00:41 UTC, Martin Nowak wrote:
> A good criteria is whether some area has an established and
> hard to debate solution, then it can go into the standard
> library. But if there are many different ways around the same
> topic you should leave the decision to the users.
I don't think this is the right criteria. Take a good hard look
at the C++ standard library.
Plenty of things in there that nobody use, but which one would
hope that almost everyone would use. Like for numerics.
When a good external numerics library emerge it will displace
whatever numerics functionality the standard library provides.
D has too few users to see high quality external libraries, but
that is not a good reason to bloat the standard library.
The argument that some functionality is needed on a daily basis
is also misguided. Different applications have different needs.
What the standard library should support is essential interfacing
with the system and what you need to interface with libraries,
like basic types/iterators.
Once you have something in the standard library you have to
maintain it forever. If something is in the standard library and
it turns out to be impossible to implement it efficiently on a
specific hardware platform then all libraries using that
functionality will be dog slow on that platform.
> So for example there are 3 established ways to parse something,
> dom, stax and event based parsers. So you can add those parsers
> as sth. like std.xml or std.json.
There is no reason for xml or json to be in the standard library.
You can have a set of recommended libraries, allowing for more
efficient APIs to emerge over time.
Only functionality where you get unbreakable interdependencies
between standard modules need to be in standard library.
Parsers and compressors have low levels of inter-library
dependencies. DSP functionality has only internal dependencies.
No need for such things in the standard library.
Scripting languages like Python is a horrible example to follow.
Scripting languages require all C-implemented functionality to be
in the standard library for the sake of being able to deploy pure
python code on machines where you don't get to install binaries.
More information about the Digitalmars-d-announce
mailing list