On Wed, 07 Sep 2016 15:22:01 +0000, Jack Stouffer wrote:

> On Wednesday, 7 September 2016 at 05:58:37 UTC, Brian wrote:
>> Standard library thin! The lack of a lot of commonly used functions! For example, HTTP client, database abstraction layer, mail delivery, Mathematical calculation standard library.
>
> 2. Everything but the math library is extremely prone to change within a couple of years and is therefore not really a good candidate for standardization.

http://www.rfc-base.org/rfc-5321.html
https://tools.ietf.org/html/rfc7230
https://tools.ietf.org/html/rfc7540
http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?
csnumber=53681

JDBC and ADO.NET do a good job of abstracting away specific SQL database libraries to a greater degree than ISO 9075 alone would allow.

Perhaps you could explain what you mean when you say that these protocols and systems are poor candidates for standardization and how .NET and Java have suffered for including them in their standard libraries?

> There's a reason that there are three different ways to connect to a MySQL database within the PHP standard library: they tried to standardize something that shouldn't really be standardized.

The reason there are three ways to connect to MySQL in PHP are:

* In the early days, they wanted to ship something that worked with
minimal effort, and wrapping the C API directly gave them that. This
wrapper was deprecated in PHP5.5 and removed in PHP7.
* They later needed to provide a sensible API exposing all of MySQL's
features, so they implemented MySQLi.
* They also wanted to provide a consistent API for multiple SQL
databases, so they implemented PDO and a driver for MySQL.

I don't see how standardization has anything to do with it. Or putting too much in the standard distribution.

On Wednesday, 7 September 2016 at 19:01:23 UTC, Piotrek wrote:
> Almost every "standard" evolves (e.g. USB, 3GPP, etc) and are subject to change in subsequent releases. Stopping the progress is not a case in good standardization process.

When I say "a good candidate for standardization", what I mean is a standardization of an API and module design, not a standardization in the traditional sense.

It doesn't matter that a standard like HTTP2 will have a new version (e.g. 2.1), what matters is the way in which the programmer interacts with it and how that API is designed. If there's no clear answer, e.g. urllib2 vs. requests, then that probably shouldn't be included in the standard library. Continuing with the urllib2 example, how many people do you suppose use urllib2 over requests, which is the most popular Python library by far? Despite this, the Python team is stuck maintaining urllib2.

On Thursday, 8 September 2016 at 07:43:02 UTC, Jack Stouffer wrote:
> On Wednesday, 7 September 2016 at 19:01:23 UTC, Piotrek wrote:
>> Almost every "standard" evolves (e.g. USB, 3GPP, etc) and are subject to change in subsequent releases. Stopping the progress is not a case in good standardization process.
>
> When I say "a good candidate for standardization", what I mean is a standardization of an API and module design, not a standardization in the traditional sense.
>
> It doesn't matter that a standard like HTTP2 will have a new version (e.g. 2.1), what matters is the way in which the programmer interacts with it and how that API is designed. If there's no clear answer, e.g. urllib2 vs. requests, then that probably shouldn't be included in the standard library. Continuing with the urllib2 example, how many people do you suppose use urllib2 over requests, which is the most popular Python library by far? Despite this, the Python team is stuck maintaining urllib2.

Requests is a good example, but not for that reason. There were discussions to embed requests in Python's stdlib but the lead developer decided that it would slow down the process too much and decided to continue with it being a third-party library.

The thing is, even with Request maintaining urllib2 has hardly ever been considered an issue for Python. It is necessary as a foundation of other libraries including Request and that's what a standard library is for: providing tools fit for a large set of problems usable as building blocks.

On Thu, 08 Sep 2016 07:43:02 +0000, Jack Stouffer wrote:

> On Wednesday, 7 September 2016 at 19:01:23 UTC, Piotrek wrote:
>> Almost every "standard" evolves (e.g. USB, 3GPP, etc) and are subject to change in subsequent releases. Stopping the progress is not a case in good standardization process.
> 
> When I say "a good candidate for standardization", what I mean is a standardization of an API and module design, not a standardization in the traditional sense.
> 
> It doesn't matter that a standard like HTTP2 will have a new version (e.g. 2.1), what matters is the way in which the programmer interacts with it and how that API is designed. If there's no clear answer, e.g. urllib2 vs. requests, then that probably shouldn't be included in the standard library. Continuing with the urllib2 example, how many people do you suppose use urllib2 over requests, which is the most popular Python library by far? Despite this, the Python team is stuck maintaining urllib2.

Your example shows that hasty API design can be undesirable. Nobody's objecting to that.

The current pattern in D is:

* propose a module
* get feedback on the newsgroup
* implement it and put it on dub in a std.experimental namespace
* get feedback from people actually using your work
* make PR
* get feedback from people who already maintain Phobos
* it's now in Phobos

This pattern was/is being followed for, if I recall, ndslice, checkedint, xml2, and logging. Possibly a couple others.

Do you think that process is insufficient? Or do you think that it's not useful to push these libraries into Phobos?

On Thursday, 8 September 2016 at 07:43:02 UTC, Jack Stouffer wrote:
> On Wednesday, 7 September 2016 at 19:01:23 UTC, Piotrek wrote:
>> Almost every "standard" evolves (e.g. USB, 3GPP, etc) and are subject to change in subsequent releases. Stopping the progress is not a case in good standardization process.
>
> When I say "a good candidate for standardization", what I mean is a standardization of an API and module design, not a standardization in the traditional sense.
>
> It doesn't matter that a standard like HTTP2 will have a new version (e.g. 2.1), what matters is the way in which the programmer interacts with it and how that API is designed. If there's no clear answer, e.g. urllib2 vs. requests, then that probably shouldn't be included in the standard library. Continuing with the urllib2 example, how many people do you suppose use urllib2 over requests, which is the most popular Python library by far? Despite this, the Python team is stuck maintaining urllib2.

What's important is that no one goes to plan or organize what is needed.

Don't want a lot of D language users to help? Java/rust/golang has its own standard library, are users want to come out? D language developers where?

On Thursday, 8 September 2016 at 16:43:09 UTC, Brian wrote:
>
> What's important is that no one goes to plan or organize what is needed.
>

I'm honestly not sure how you can say that. The Vision documents are pretty clear about priorities and plans.