Re: We need to enhance the standard library!
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.
Re: We need to enhance the standard library!
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?
Re: We need to enhance the standard library!
On Thu, 08 Sep 2016 07:43:02 +, 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?
Re: We need to enhance the standard library!
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.
Re: We need to enhance the standard library!
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.
Re: We need to enhance the standard library!
On Wed, 07 Sep 2016 15:22:01 +, 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.
Re: We need to enhance the standard library!
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
Re: We need to enhance the standard library!
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
Re: We need to enhance the standard library!
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.
Re: We need to enhance the standard library!
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
Re: We need to enhance the standard library!
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.
Re: We need to enhance the standard library!
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
Re: We need to enhance the standard library!
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!
Re: We need to enhance the standard library!
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
Re: We need to enhance the standard library!
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
We need to enhance the standard library!
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/
