• Brian (8/8) Sep 06 2016 Standard library thin! The lack of a lot of commonly used
• Daniel Kozak via Digitalmars-d (5/13) Sep 06 2016 No, I do not agree that we need HTTP client, database abstraction layer
• eugene (4/6) Sep 07 2016 hello, we can write it as a separate lib as there are no things
• Brian (7/24) Sep 07 2016 Fully rely on third party to promote the D language ecology? Why
• Basile B. (4/12) Sep 07 2016 See
• Guillaume Piolat (4/7) Sep 07 2016 Your opinion is largely shared with the leadership about the size
• Piotrek (6/14) Sep 07 2016 The only problem is lack of resources. IMO, there is no valid
• Jack Stouffer (9/17) Sep 07 2016 1. When you say "We need to", I assume that means you have some
• Jonathan M Davis via Digitalmars-d (16/35) Sep 07 2016 There are definitely things that function better as 3rd party libraries ...
• Piotrek (8/14) Sep 07 2016 Almost every "standard" evolves (e.g. USB, 3GPP, etc) and are
• Jack Stouffer (13/16) Sep 08 2016 When I say "a good candidate for standardization", what I mean is
• cym13 (11/27) Sep 08 2016 Requests is a good example, but not for that reason. There were
• Chris Wright (15/32) Sep 08 2016 Your example shows that hasty API design can be undesirable. Nobody's
• Brian (7/23) Sep 08 2016 What's important is that no one goes to plan or organize what is
• jmh530 (3/5) Sep 08 2016 I'm honestly not sure how you can say that. The Vision documents
• Chris Wright (21/31) Sep 07 2016 http://www.rfc-base.org/rfc-5321.html

Brian <zoujiaqing gmail.com> writes:

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.

We can refer to the implementation of some of the standard 
library golang/java/rust, so that the whole language active up:

Https://golang.org/pkg/
Https://docs.oracle.com/javase/8/docs/api/
Https://doc.rust-lang.org/std/

Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:

Dne 7.9.2016 v 07:58 Brian via Digitalmars-d napsal(a):

 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.

 We can refer to the implementation of some of the standard library 
 golang/java/rust, so that the whole language active up:

 Https://golang.org/pkg/
 Https://docs.oracle.com/javase/8/docs/api/
 Https://doc.rust-lang.org/std/

No, I do not agree that we need HTTP client, database abstraction layer 
and mail delivery in standard library, those shoud be just packages 
idealy available from code.dlang.org, but what I think should be part of 
standard library is some form of async IO

eugene <egordeev18 gmail.com> writes:

On Wednesday, 7 September 2016 at 06:51:40 UTC, Daniel Kozak 
wrote:
 ... I think should be part of standard library is some form of 
 async IO

hello, we can write it as a separate lib as there are no things 
like JCP and JSR, standartization committee

Brian <zoujiaqing gmail.com> writes:

On Wednesday, 7 September 2016 at 06:51:40 UTC, Daniel Kozak 
wrote:
 Dne 7.9.2016 v 07:58 Brian via Digitalmars-d napsal(a):

 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.

 We can refer to the implementation of some of the standard 
 library golang/java/rust, so that the whole language active up:

 Https://golang.org/pkg/
 Https://docs.oracle.com/javase/8/docs/api/
 Https://doc.rust-lang.org/std/

 No, I do not agree that we need HTTP client, database 
 abstraction layer and mail delivery in standard library, those 
 shoud be just packages idealy available from code.dlang.org, 
 but what I think should be part of standard library is some 
 form of async IO

Fully rely on third party to promote the D language ecology? Why 
Java popular, why golang hot? Don't understand reflection!

My studio have collie( https://github.com/putaolabs/collie ) & 
hunt framework ( https://github.com/putaolabs/hunt ), but I think 
it's far from enough!

Basile B. <b2.temp gmx.com> writes:

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.

 We can refer to the implementation of some of the standard 
 library golang/java/rust, so that the whole language active up:

 Https://golang.org/pkg/
 Https://docs.oracle.com/javase/8/docs/api/
 Https://doc.rust-lang.org/std/

See

https://wiki.dlang.org/Wish_list#std.database.
https://wiki.dlang.org/Wish_list#Native_curl_replacement

Guillaume Piolat <first.last gmail.com> writes:

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.

Your opinion is largely shared with the leadership about the size 
of the standard library. It's just that Phobos reviews are really 
strict, and things go a bit slowly to enter it.

Piotrek <piotrek unknownuniverse.net> writes:

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.

 We can refer to the implementation of some of the standard 
 library golang/java/rust, so that the whole language active up:

 Https://golang.org/pkg/
 Https://docs.oracle.com/javase/8/docs/api/
 Https://doc.rust-lang.org/std/

The only problem is lack of resources. IMO, there is no valid 
argument to limit the Phobos functionality used by most of 
programmers (like database, gui, multimedia, network, dsp, 
numeric, etc)

Piotrek

Jack Stouffer <jack jackstouffer.com> writes:

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.

 We can refer to the implementation of some of the standard 
 library golang/java/rust, so that the whole language active up:

 Https://golang.org/pkg/
 Https://docs.oracle.com/javase/8/docs/api/
 Https://doc.rust-lang.org/std/

1. When you say "We need to", I assume that means you have some 
open pull requests or are working on some, right?

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

Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Wednesday, September 07, 2016 15:22:01 Jack Stouffer via Digitalmars-d 
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.

 We can refer to the implementation of some of the standard
 library golang/java/rust, so that the whole language active up:

 Https://golang.org/pkg/
 Https://docs.oracle.com/javase/8/docs/api/
 Https://doc.rust-lang.org/std/

 1. When you say "We need to", I assume that means you have some
 open pull requests or are working on some, right?

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

There are definitely things that function better as 3rd party libraries than
as part of the standard library, but the big thing here - regardless of the
exact functionality in question - is that someone needs to actually do the
work. And that's where we generally fall flat.  Once someone has actually
implemented something, _then_ we can discuss whether it makes sense to put
it in Phobos, but there isn't necessarily much point in debating that point
when there isn't even software to debate over. Regardless of whether the
functionality should be in Phobos, it still needs to be implemented, and it
can start on code.dlang.org. Whether it gets into the standard library or
not is very much a secondary issue to whether it's available in the first
place. So, as usual, the question comes down to manpower. We don't have as
many appropriately skilled programmers involved as we'd like, and many of
the ones that we do have are short on time.

- Jonathan M Davis

Piotrek <piotrek unknownuniverse.net> writes:

On Wednesday, 7 September 2016 at 15:22:01 UTC, Jack Stouffer 
wrote:

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

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.

As for PHP, it did most things wrong. What I mean is if one of 
car manufactures makes bad cars shouldn't we use all of them.

Piotrek

Jack Stouffer <jack jackstouffer.com> writes:

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.

cym13 <cpicard openmailbox.org> writes:

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.

Chris Wright <dhasenan gmail.com> writes:

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?

Brian <zoujiaqing gmail.com> writes:

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?

jmh530 <john.michael.hall gmail.com> writes:

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.

Chris Wright <dhasenan gmail.com> writes:

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.