www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Case for std.experimental

reply "Dicebot" <public dicebot.lv> writes:
Forking from 
http://forum.dlang.org/post/qsqfcayisriatreqtvcm forum.dlang.org

Most relevant quote:

On Tuesday, 29 July 2014 at 17:15:22 UTC, Andrei Alexandrescu 
wrote:

 We put something in std.experimental when we can't imagine what 
 other work is to be done on the module. (Inevitably a little 
 more work is prompted by usage, which is the point of it all.) 
 We don't put in std.experimental stuff that has already a known 
 backlog of work to do.


This surprises me because during talks about std.experimental 
before it was discussed as possible place to advertise Phobos 
candidates without risking any API breakage. And now Andrei 
(Davis also supports this point) speaks about it as pure 
"staging" concept which should have same inclusion criteria as 
Phobos mainstream.

Reason why I find this strange is because it invalidates main 
argument in favor of std.experimental over something like dub 
package - making it easier to wider user case to try the proposal 
and provide API feedback. All it does with such restrictions is 
delaying stabilization point for one release in case something 
totally unforeseen comes out.

I wonder what are other opinions.
Jul 29 2014
next sibling parent reply "safety0ff" <safety0ff.dev gmail.com> writes:
On Tuesday, 29 July 2014 at 17:22:38 UTC, Dicebot wrote:

 Forking from 
 http://forum.dlang.org/post/qsqfcayisriatreqtvcm forum.dlang.org

 Most relevant quote:


Personally, I think this following quote is the more compelling 
argument for that particular case:

On Tuesday, 29 July 2014 at 17:15:22 UTC, Andrei Alexandrescu 
wrote:

 We put something in std.experimental when we can't imagine what 
 other work is to be done on the module. (Inevitably a little 
 more work is prompted by usage, which is the point of it all.) 
 We don't put in std.experimental stuff that has already a known 
 backlog of work to do.
Jul 29 2014
next sibling parent "safety0ff" <safety0ff.dev gmail.com> writes:
On Tuesday, 29 July 2014 at 17:27:15 UTC, safety0ff wrote:

Derp, nevermind that post.
Jul 29 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/29/14, 10:27 AM, safety0ff wrote:

 On Tuesday, 29 July 2014 at 17:22:38 UTC, Dicebot wrote:

 Forking from
 http://forum.dlang.org/post/qsqfcayisriatreqtvcm forum.dlang.org

 Most relevant quote:


 Personally, I think this following quote is the more compelling argument
 for that particular case:

 On Tuesday, 29 July 2014 at 17:15:22 UTC, Andrei Alexandrescu wrote:

 We put something in std.experimental when we can't imagine what other
 work is to be done on the module. (Inevitably a little more work is
 prompted by usage, which is the point of it all.) We don't put in
 std.experimental stuff that has already a known backlog of work to do.




I'd just want to have a simple litmus test that prevents 
std.experimental from becoming a dumping ground of unfinished work. 
Consider:

"Folks, here's std.experimental.acme. I think it's usable and fairly 
stable but I'm sure I didn't think of all possible issues and use cases. 
Documentation could be also improved."

vs

"Folks, here's std.experimental.acme. The entire user-facing API is sure 
to change and it doesn't pass what some deem to be basic acceptance 
terms. Try it, but you can be sure you'll need to overhaul all use of it 
when it's done."


Andrei
Jul 29 2014
next sibling parent "safety0ff" <safety0ff.dev gmail.com> writes:
On Tuesday, 29 July 2014 at 17:35:34 UTC, Andrei Alexandrescu 
wrote:

 I'd just want to have a simple litmus test that prevents 
 std.experimental from becoming a dumping ground of unfinished 
 work.


I screwed up that post, but in brief I meant to agree with your 
quote for the case of std.logger.
Jul 29 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 29 July 2014 at 17:35:34 UTC, Andrei Alexandrescu 
wrote:

 I'd just want to have a simple litmus test that prevents 
 std.experimental from becoming a dumping ground of unfinished 
 work. Consider:

 "Folks, here's std.experimental.acme. I think it's usable and 
 fairly stable but I'm sure I didn't think of all possible 
 issues and use cases. Documentation could be also improved."

 vs

 "Folks, here's std.experimental.acme. The entire user-facing 
 API is sure to change and it doesn't pass what some deem to be 
 basic acceptance terms. Try it, but you can be sure you'll need 
 to overhaul all use of it when it's done."


What keeps bothering me is this: imagine something has not passed 
vote for std.experimental inclusion. That means that some changes 
will happen, one more voting and it will eventually get there one 
release later.

And if has passed the vote, effectively the same stuff happens - 
changes are done, staging period prolonged and we get to the very 
same point. Only difference is that earlier versions of the 
module don't get wider user exposure.

Now that I see several comments here seeking for certain 
stability even in std.experimental and can understand why later 
exposure can be a good thing. That, however, makes me even more 
convinced that "experimental" is a terrible name for that package 
and we are using it purely as staging are instead.
Jul 30 2014
next sibling parent reply "Dragos Carp" <dragoscarp gmail.com> writes:
 Now that I see several comments here seeking for certain 
 stability even in std.experimental and can understand why later 
 exposure can be a good thing. That, however, makes me even more 
 convinced that "experimental" is a terrible name for that 
 package and we are using it purely as staging are instead.


I think that if we rename std.experimental as std.stagging, we 
can consider that  it has absolved from its own 
expe\b\b\b\bstaging phase.

Just now this will cause no code breakage, and hopefully it will 
also avoid some confusions and discussions in the future.
Jul 30 2014
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Wednesday, 30 July 2014 at 15:21:12 UTC, Dragos Carp wrote:

 Now that I see several comments here seeking for certain 
 stability even in std.experimental and can understand why 
 later exposure can be a good thing. That, however, makes me 
 even more convinced that "experimental" is a terrible name for 
 that package and we are using it purely as staging are instead.


 I think that if we rename std.experimental as std.stagging, we 
 can consider that  it has absolved from its own 
 expe\b\b\b\bstaging phase.

 Just now this will cause no code breakage, and hopefully it 
 will also avoid some confusions and discussions in the future.


As far as I recall, there was extensive bike-shedding about this 
a while back. The decision (which I support) was to go with 
std.experimental, as it makes it clear that there are no API 
stability guarantees and the module will eventually go away. 
Making it sound unstable was the entire point of going with that 
name over the alternatives.

Cheers,
David
Jul 30 2014
next sibling parent "Dragos Carp" <dragoscarp gmail.com> writes:
On Wednesday, 30 July 2014 at 15:24:22 UTC, David Nadlinger wrote:

 On Wednesday, 30 July 2014 at 15:21:12 UTC, Dragos Carp wrote:

 As far as I recall, there was extensive bike-shedding about 
 this a while back. The decision (which I support) was to go 
 with std.experimental,


Sorry, probably this was before I started following the forum 
discussions.


 as it makes it clear that there are no API stability guarantees


Andrei made the point that API should be stable with unforeseen 
exceptions and I support this.


 and the module will eventually go away.


Hopefully the module will get one level upper in std. and not go 
away.


 Making it sound unstable was the entire point of going with 
 that name over the alternatives.


As in this thread, we see that "empty" std.experimental already 
generates unnecessary discussions.

In my opinion, DUB is the right place (playground) for 
experiments.
Jul 30 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 30 July 2014 at 15:24:22 UTC, David Nadlinger wrote:

 The decision (which I support) was to go with std.experimental, 
 as it makes it clear that there are no API stability guarantees


..and at the same time you do want to require the very same 
stability guarantees :)
Jul 30 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/30/14, 8:56 AM, Dicebot wrote:

 On Wednesday, 30 July 2014 at 15:24:22 UTC, David Nadlinger wrote:

 The decision (which I support) was to go with std.experimental, as it
 makes it clear that there are no API stability guarantees


 ..and at the same time you do want to require the very same stability
 guarantees :)


No! The point here is we don't offer the guarantees. We just don't want 
std.experimental to devolve into "anything goes" territory. If a library 
has known significant work ahead of it, we shouldn't put it in 
std.experimental. -- Andrei
Jul 30 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 30 July 2014 at 17:44:06 UTC, Andrei Alexandrescu 
wrote:

 No! The point here is we don't offer the guarantees. We just 
 don't want std.experimental to devolve into "anything goes" 
 territory. If a library has known significant work ahead of it, 
 we shouldn't put it in std.experimental. -- Andrei


Ok, I will keep those rules in mind for future reviews / voting 
even if I don't understand their merit :)
Jul 30 2014
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Wednesday, 30 July 2014 at 18:00:59 UTC, Dicebot wrote:

 On Wednesday, 30 July 2014 at 17:44:06 UTC, Andrei Alexandrescu 
 wrote:

 No! The point here is we don't offer the guarantees. We just 
 don't want std.experimental to devolve into "anything goes" 
 territory. If a library has known significant work ahead of 
 it, we shouldn't put it in std.experimental. -- Andrei


 Ok, I will keep those rules in mind for future reviews / voting 
 even if I don't understand their merit :)


My view on the purpose of std.experimental notwithstanding, maybe 
we should discuss the meaning of the _vote_: What about making 
the vote simply about whether the module is believed to be a) of 
enough importance to be in Phobos by the wider community, and b) 
close enough to the mark in terms of design and implementation 
that a solid result is reachable in the near future? A positive 
vote would then be a mandate for the contributor and the Phobos 
committers/reviewers to work on ironing out the remaining kinks 
to make the package suitable for shipping with the standard 
library. In other words, the vote would effectively put the pull 
request for the addition on a level with all the others that 
contain no or only minor changes to the public API.

Cheers,
David
Jul 30 2014
parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 30 July 2014 at 22:44:38 UTC, David Nadlinger wrote:

 Ok, I will keep those rules in mind for future reviews / 
 voting even if I don't understand their merit :)


 My view on the purpose of std.experimental notwithstanding, 
 maybe we should discuss the meaning of the _vote_: What about 
 making the vote simply about whether the module is believed to 
 be a) of enough importance to be in Phobos by the wider 
 community, and b) close enough to the mark in terms of design 
 and implementation that a solid result is reachable in the near 
 future?


(b) is a bit too vague. With something like std.logger full 
rewrite of API can be done in quite a small time being thus 
"reachable in the near future" :) Effectively it implies that 
Phobos reviewers "know better" when it comes to exposed API and 
this is something I disagree with (I am one of those reviewers 
after all and I won't trust myself). Voting is an opportunity to 
a future users to tell "this API looks so bad I'd better write 
one of my own than go with it".

At the same time minor glitches and overall Phobos style 
compatibility has not been traditionally considered a voting 
blocker so far so it already partially works that way - going 
through normal PR review process is still expected.
Jul 30 2014
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/30/14, 5:41 AM, Dicebot wrote:

 On Tuesday, 29 July 2014 at 17:35:34 UTC, Andrei Alexandrescu wrote:

 I'd just want to have a simple litmus test that prevents
 std.experimental from becoming a dumping ground of unfinished work.
 Consider:

 "Folks, here's std.experimental.acme. I think it's usable and fairly
 stable but I'm sure I didn't think of all possible issues and use
 cases. Documentation could be also improved."

 vs

 "Folks, here's std.experimental.acme. The entire user-facing API is
 sure to change and it doesn't pass what some deem to be basic
 acceptance terms. Try it, but you can be sure you'll need to overhaul
 all use of it when it's done."


 What keeps bothering me is this: imagine something has not passed vote
 for std.experimental inclusion. That means that some changes will
 happen, one more voting and it will eventually get there one release later.

 And if has passed the vote, effectively the same stuff happens - changes
 are done, staging period prolonged and we get to the very same point.
 Only difference is that earlier versions of the module don't get wider
 user exposure.

 Now that I see several comments here seeking for certain stability even
 in std.experimental and can understand why later exposure can be a good
 thing. That, however, makes me even more convinced that "experimental"
 is a terrible name for that package and we are using it purely as
 staging are instead.


Let it be more conservatively named. -- Andrei
Jul 30 2014
prev sibling next sibling parent jollie <jollie home.net> writes:
"Dicebot" <public dicebot.lv> Wrote in message:

 On Tuesday, 29 July 2014 at 17:35:34 UTC, Andrei Alexandrescu 
 wrote:

 I'd just want to have a simple litmus test that prevents 
 std.experimental from becoming a dumping ground of unfinished 
 work. Consider:

 "Folks, here's std.experimental.acme. I think it's usable and 
 fairly stable but I'm sure I didn't think of all possible 
 issues and use cases. Documentation could be also improved."

 vs

 "Folks, here's std.experimental.acme. The entire user-facing 
 API is sure to change and it doesn't pass what some deem to be 
 basic acceptance terms. Try it, but you can be sure you'll need 
 to overhaul all use of it when it's done."


 
 What keeps bothering me is this: imagine something has not passed 
 vote for std.experimental inclusion. That means that some changes 
 will happen, one more voting and it will eventually get there one 
 release later.
 
 And if has passed the vote, effectively the same stuff happens - 
 changes are done, staging period prolonged and we get to the very 
 same point. Only difference is that earlier versions of the 
 module don't get wider user exposure.
 
 Now that I see several comments here seeking for certain 
 stability even in std.experimental and can understand why later 
 exposure can be a good thing. That, however, makes me even more 
 convinced that "experimental" is a terrible name for that package 
 and we are using it purely as staging are instead.
 



--
Jul 30 2014
prev sibling parent jollie <jollie home.net> writes:
"Dicebot" <public dicebot.lv> Wrote in message:


 What keeps bothering me is this: imagine something has not passed 
 vote for std.experimental inclusion. That means that some changes 
 will happen, one more voting and it will eventually get there one 
 release later.
 
 And if has passed the vote, effectively the same stuff happens - 
 changes are done, staging period prolonged and we get to the very 
 same point. Only difference is that earlier versions of the 
 module don't get wider user exposure.
 
 Now that I see several comments here seeking for certain 
 stability even in std.experimental and can understand why later 
 exposure can be a good thing. That, however, makes me even more 
 convinced that "experimental" is a terrible name for that package 
 and we are using it purely as staging are instead.
 


std.purgatory
Jul 30 2014
prev sibling next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 29 July 2014 at 17:22:38 UTC, Dicebot wrote:

 (Davis also supports this point)


To avoid confusion, let me point out that this was me (i.e., 
"David"), not Jonathan M. Davis.


 Reason why I find this strange is because it invalidates main 
 argument in favor of std.experimental over something like dub 
 package - making it easier to wider user case to try the 
 proposal and provide API feedback.


I think you got this precisely the wrong way round: Having 
something in Phobos makes it infinitely harder to meaningfully 
improve on a design, as the DMD release cycle takes the "rapid" 
out of "rapid iteration". Almost nobody builds 
DMD/druntime/Phobos from source in the grand scheme of things – 
pretty much only the core team and some of the forum regulars do.

Cheers,
David
Jul 29 2014
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, 29 July 2014 at 17:34:39 UTC, David Nadlinger wrote:

 On Tuesday, 29 July 2014 at 17:22:38 UTC, Dicebot wrote:

 (Davis also supports this point)


 To avoid confusion, let me point out that this was me (i.e., 
 "David"), not Jonathan M. Davis.


LOL. Yeah. I haven't said anything in that thread. However, I 
agree with both David and Andrei. std.experimental should be for 
the place to put stuff that's passed the Phobos review process 
and is considered ready for inclusion. But we put it in 
std.experimental rather than directly into std like we've done in 
the past in order to give it some time to be battle tested prior 
to actually being included into Phobos proper, since it becomes 
_very_ difficult to fix the API once it's in std.

We can use dub for the stuff that hasn't passed the review 
process yet and std.experimental as a staging ground for std.

- Jonathan M Davis
Jul 29 2014
parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 29 July 2014 at 21:01:07 UTC, Jonathan M Davis wrote:

 On Tuesday, 29 July 2014 at 17:34:39 UTC, David Nadlinger wrote:

 On Tuesday, 29 July 2014 at 17:22:38 UTC, Dicebot wrote:

 (Davis also supports this point)


 To avoid confusion, let me point out that this was me (i.e., 
 "David"), not Jonathan M. Davis.


 LOL. Yeah. I haven't said anything in that thread.


Sorry, stupid typo, 's' and 'd' are too close on the keyboard :(
Jul 30 2014
prev sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 29 July 2014 18:34, David Nadlinger via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 the DMD release cycle takes the "rapid" out of "rapid iteration".


Sad but true.
Jul 30 2014
prev sibling next sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
Frankly, if Dub is bundled with D, I don't see any reason for
std.experimental to exist.  Those two ideas just seemed to
develop in parallel.
Jul 29 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/29/14, 12:01 PM, Sean Kelly wrote:

 Frankly, if Dub is bundled with D, I don't see any reason for
 std.experimental to exist.  Those two ideas just seemed to
 develop in parallel.


The way I see it:

* dub: a loose federation of libraries with no implied promise.

* std.experimental: 99% sure to make it in std, use at your risk but 
there's a high likelihood you'll just remove ".experimental" next 
release, fix whatever doesn't compile, and you're good to go.


Andrei
Jul 29 2014
parent "Mike James" <foo bar.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:lr8r7a$j7v$1 digitalmars.com...

 On 7/29/14, 12:01 PM, Sean Kelly wrote:

 Frankly, if Dub is bundled with D, I don't see any reason for
 std.experimental to exist.  Those two ideas just seemed to
 develop in parallel.


 The way I see it:

 * dub: a loose federation of libraries with no implied promise.

 * std.experimental: 99% sure to make it in std, use at your risk but 
 there's a high likelihood you'll just remove ".experimental" next release, 
 fix whatever doesn't compile, and you're good to go.


 Andrei


+1

-=mike=-
Jul 30 2014
prev sibling next sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Tuesday, 29 July 2014 at 17:22:38 UTC, Dicebot wrote:

 Forking from 
 http://forum.dlang.org/post/qsqfcayisriatreqtvcm forum.dlang.org

 Most relevant quote:

 On Tuesday, 29 July 2014 at 17:15:22 UTC, Andrei Alexandrescu 
 wrote:

 We put something in std.experimental when we can't imagine 
 what other work is to be done on the module. (Inevitably a 
 little more work is prompted by usage, which is the point of 
 it all.) We don't put in std.experimental stuff that has 
 already a known backlog of work to do.


 This surprises me because during talks about std.experimental 
 before it was discussed as possible place to advertise Phobos 
 candidates without risking any API breakage. And now Andrei 
 (Davis also supports this point) speaks about it as pure 
 "staging" concept which should have same inclusion criteria as 
 Phobos mainstream.


This was also my understanding of how that discussion resolved: 
std.experimental is a place for things we think belong in Phobos 
to incubate and get wide, public exposure.  There are arguments 
that dub obviates this, but I don't think that has nearly the 
visibility needed.

That is, "which of these logging libraries is the candidate for 
Phobos, again?"  Or, more generally, "which libraries are 
candidates for Phobos, again?  How can you tell?  If this is a 
candidate, why isn't it in the autotester?  Do we file bugs on 
dlang.org even though it's in the registry?"  Add a generous 
dollop of silence from people who reinvent the wheel because 
they've never heard of Dub, and serve chilled.  I'd be willing to 
bet anything in the std packages has several orders of magnitude 
more eyes acknowledging its existence.

By the way, when you say "staging" I think of the Linux kernel's 
definition of staging [1] for driver and filesystem development.  
It's just a bit confusing. :)  On the other hand, I still think 
their rules for staging have some merit as an example for Phobos 
to ad{a,o}pt.

-Wyatt

[1] http://lwn.net/Articles/324279/
Jul 29 2014
parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 29 July 2014 at 19:50:15 UTC, Wyatt wrote:

 By the way, when you say "staging" I think of the Linux 
 kernel's definition of staging [1] for driver and filesystem 
 development.  It's just a bit confusing. :)  On the other hand, 
 I still think their rules for staging have some merit as an 
 example for Phobos to ad{a,o}pt.

 -Wyatt

 [1] http://lwn.net/Articles/324279/


I am using this term in a same sense as some Linux distros - 
place for packages that are supposed to get to the main repo but 
are not yet there. Sometimes it takes form of separate repository 
users can optionally enable to have a look at upcoming stuff.

Linux kernel definition is similar but somewhat more specialized 
to their development model.
Jul 30 2014
prev sibling parent "uri" <email ether.com> writes:
On Tuesday, 29 July 2014 at 17:22:38 UTC, Dicebot wrote:
[snip]

 I wonder what are other opinions.


Here's what I'd like to see as a D user with std.experimental...

dub:
     ==> free-for-all libraries of varying quality
     ==> Promoted on official D website.
     ==> Included in the D download

std.experimental:
     ==> Released with Phobos
     ==> Reviewed modules by core D devs, akin to BETA/RC
     ==> Guarantees on API stability but not set in stone.
     ==> [maybe?] Changes require deprecation and another round in 
std.experimental


std:
     ==> High quality with API in stone.
     ==> Modules have been through 2 rounds of review
     ==> Changes require deprecation over a longer period.





Cheers,
uri.
Jul 29 2014