www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.experimental =?UTF-8?B?4oCT?= DConf?

reply "David Nadlinger" <code klickverbot.at> writes:
Hi all,

There seems to have been some discussion regarding 
std.experimental at DConf, as several proposals to add modules to 
it have popped up over the last few days. Maybe Andrei's keynote 
had something on it (I unfortunately missed it)?

In any case, could somebody please outline the discussion here? 
To me, directly proposing modules for std.experimental that 
haven't gone through being a (popular) code.dlang.org package 
first seems to be at odds with promoting the latter as an 
incubator for library development.

Best,
David
May 29 2014
next sibling parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 29/05/14 09:55, David Nadlinger via Digitalmars-d wrote:
 In any case, could somebody please outline the discussion here? To me, directly
 proposing modules for std.experimental that haven't gone through being a
 (popular) code.dlang.org package first seems to be at odds with promoting the
 latter as an incubator for library development.
Can't speak for the DConf discussion, but to my mind, the criterion shouldn't be "Have they proven popular on code.dlang.org?" but, "Does the design look promising and is it likely to be of broad interest?" Requiring people to prove themselves in a popularity contest first seems to me to get in the way of the aim to have a fast-moving, able-to-quickly-get-user-feedback-and-make-breaking-changes part of the standard D toolchain.
May 29 2014
parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Thursday, 29 May 2014 at 12:10:23 UTC, Joseph Rushton Wakeling 
via Digitalmars-d wrote:
 Requiring people to prove themselves in a popularity contest 
 first seems to me to get in the way of the aim to have a 
 fast-moving, 
 able-to-quickly-get-user-feedback-and-make-breaking-changes 
 part of the standard D toolchain.
On the other hand, if this is really fast moving and with breaking changes, one might as well keep it in the DUB registry so that people: - are able to rely on a particular version and have their code breaking only when they want. - get faster updates instead of waiting for Phobos releases. Is it really fast moving when you have to wait for compiler releases? I don't think so. I also believe there is a positive correlation between "being popular on code.dlang.org" and "being useful and with a promising design".
May 29 2014
parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 29/05/14 18:22, ponce via Digitalmars-d wrote:
 Is it really fast moving when you have to wait for compiler releases? I don't
 think so.
Fair point. What I was really trying to say is, that if something looks good from a design point of view, that getting it straight into std.experimental is probably a much more effective way of getting it out there and battle tested than having it on code.dlang.org, because there will most likely be orders of magnitude difference in user takeup between modules in each.
 I also believe there is a positive correlation between "being popular on
 code.dlang.org" and "being useful and with a promising design".
Indeed. I'm not arguing against popularity on code.dlang.org being a consideration for potential std.experimental modules, I'm just arguing against it being a requirement.
May 29 2014
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 29 May 2014 12:44:10 -0400, Joseph Rushton Wakeling via  
Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 29/05/14 18:22, ponce via Digitalmars-d wrote:
 Is it really fast moving when you have to wait for compiler releases? I  
 don't
 think so.
Fair point. What I was really trying to say is, that if something looks good from a design point of view, that getting it straight into std.experimental is probably a much more effective way of getting it out there and battle tested than having it on code.dlang.org, because there will most likely be orders of magnitude difference in user takeup between modules in each.
Yes, most definitely. e.g., there may be several serialization libraries in code.dlang.org. But there would only ever be one in std.experimental. It says "this is the one we are considering for inclusion." By definition, more people would use it, and consider it semi-official.
 I also believe there is a positive correlation between "being popular on
 code.dlang.org" and "being useful and with a promising design".
Indeed. I'm not arguing against popularity on code.dlang.org being a consideration for potential std.experimental modules, I'm just arguing against it being a requirement.
Agree completely. -Steve
May 29 2014
parent "Dragos Carp" <dragoscarp gmail.com> writes:
 Yes, most definitely. e.g., there may be several serialization 
 libraries in code.dlang.org. But there would only ever be one 
 in std.experimental. It says "this is the one we are 
 considering for inclusion." By definition, more people would 
 use it, and consider it semi-official.
So this will be not an experiment anymore. For unfinished modules the linux kernel uses the term "staging". Imho std.staging sounds much better. Dragos
May 29 2014
prev sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Thursday, 29 May 2014 at 16:53:53 UTC, Joseph Rushton Wakeling 
via Digitalmars-d wrote:
 On 29/05/14 18:22, ponce via Digitalmars-d wrote:
 Is it really fast moving when you have to wait for compiler 
 releases? I don't
 think so.
Fair point. What I was really trying to say is, that if something looks good from a design point of view, that getting it straight into std.experimental is probably a much more effective way of getting it out there and battle tested than having it on code.dlang.org, because there will most likely be orders of magnitude difference in user takeup between modules in each.
Now you have another problem, how do you know that something "looks good" from a design point of view for inclusion in std.experimental? Reviews like for Phobos inclusion? Especially with no users at this point.
 I also believe there is a positive correlation between "being 
 popular on
 code.dlang.org" and "being useful and with a promising design".
Indeed. I'm not arguing against popularity on code.dlang.org being a consideration for potential std.experimental modules, I'm just arguing against it being a requirement.
On what criterion do you filter applicants for std.experimental then?
May 29 2014
next sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 29 May 2014 at 19:15:29 UTC, ponce wrote:
 Now you have another problem, how do you know that something 
 "looks good" from a design point of view for inclusion in 
 std.experimental? Reviews like for Phobos inclusion? Especially 
 with no users at this point.
It's an experiment; simple consensus (if that!) should be sufficient to try it out. Get it out there, let people kick it around a little, find the use cases that make it turn out to actually suck. If it feels as nice in practice as it looks like it will, great! If not, it gets changed until it does or it goes back to the drawing board.
 On what criterion do you filter applicants for std.experimental 
 then?
"Some people think this looks pretty good and is fit for inclusion in Phobos; but others are on the fence and we don't know for sure, so we need to run an experiment to find out." -Wyatt
May 29 2014
parent "ponce" <contact gam3sfrommars.fr> writes:
On Thursday, 29 May 2014 at 19:41:48 UTC, Wyatt wrote:
 On Thursday, 29 May 2014 at 19:15:29 UTC, ponce wrote:
 Now you have another problem, how do you know that something 
 "looks good" from a design point of view for inclusion in 
 std.experimental? Reviews like for Phobos inclusion? 
 Especially with no users at this point.
It's an experiment; simple consensus (if that!) should be sufficient to try it out. Get it out there, let people kick it around a little, find the use cases that make it turn out to actually suck. If it feels as nice in practice as it looks like it will, great! If not, it gets changed until it does or it goes back to the drawing board.
 On what criterion do you filter applicants for 
 std.experimental then?
"Some people think this looks pretty good and is fit for inclusion in Phobos; but others are on the fence and we don't know for sure, so we need to run an experiment to find out." -Wyatt
OK I understand the intent, good intentions for sure, now at a practical level: - if relying on a DUB package, you do not depend on the compiler release. - by using an std.experimental you now require a particular compiler for your users (that means library writers won't use it to avoid breakind their users code).
May 30 2014
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 29 May 2014 15:15:27 -0400, ponce <contact gam3sfrommars.fr> wrote:

 On what criterion do you filter applicants for std.experimental then?
Same way we do it for std. I think there is a confusion here. std.experimental should be for code that hasn't been proven, but generally acceptable to the community as a good phobos inclusion. The central issues are: 1. We have code that is in phobos that sucks, but we can't get rid of it because now it's in phobos and people depend on it staying there or at least keeping the same API (e.g. std.xml). 2. We are super-paranoid to add code to phobos out of fear that it may turn out to suck, and then we can't get rid of it (e.g. std.log or std.benchmark). This is like a test drive before buying a car. By giving access on std.experimental, we are saying "We think we want this library, test drive it for a while, see what you think," and if we all like it, it will move to std. Yes, we could just say that about some code.dlang.org project, but it doesn't have the same exposure, no matter how much we want people to use dub. It's like the difference between the dealer bringing out the car for you to test drive, and telling you to go find it yourself in the lot. -Steve
May 29 2014
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 29 May 2014 03:55:24 -0400, David Nadlinger <code klickverbot.at>  
wrote:

 Hi all,

 There seems to have been some discussion regarding std.experimental at  
 DConf, as several proposals to add modules to it have popped up over the  
 last few days. Maybe Andrei's keynote had something on it (I  
 unfortunately missed it)?

 In any case, could somebody please outline the discussion here? To me,  
 directly proposing modules for std.experimental that haven't gone  
 through being a (popular) code.dlang.org package first seems to be at  
 odds with promoting the latter as an incubator for library development.
In andrei's talk he said we should add std.experimental. I don't think there was much discussion, people liked the idea. There was no discussion on how things would be placed in there (i.e. up for debate), but it definitely is going to be there. I actually did not know about code.dlang.org until Andrei brought it up in his talk, so there may be quite a few people who aren't aware of it. Best I can do from memory ;) As for my opinion, I think std.experimental is good for modules that are definitely going in phobos but have not been fully design-tested. It's a place to add standard library items that the API is unstable for. It sucks to have stuff like std.stream and std.xml in there which people now depend on, so we can't change the API, but are no longer favored implementations. I think it would be fine to be able to promote things from code.dlang.org to std.experimental (or std for that matter), but I don't think it should be a prerequisite. -Steve
May 29 2014
parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 29/05/14 14:52, Steven Schveighoffer via Digitalmars-d wrote:
 In andrei's talk he said we should add std.experimental. I don't think there
was
 much discussion, people liked the idea. There was no discussion on how things
 would be placed in there (i.e. up for debate), but it definitely is going to be
 there. I actually did not know about code.dlang.org until Andrei brought it up
 in his talk, so there may be quite a few people who aren't aware of it.
Minor point -- is it really going to be the clunky std.experimental, or is it going to be something elegant like exp.* ... ? I would prefer the latter. :-)
May 29 2014
next sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 29 May 2014 at 13:34:26 UTC, Joseph Rushton Wakeling 
via Digitalmars-d wrote:
 Minor point -- is it really going to be the clunky 
 std.experimental, or is it going to be something elegant like 
 exp.* ... ?

 I would prefer the latter. :-)
I think I would too. But failing that, since we have packages now, would std.experimental.* be an acceptable compromise? -Wyatt
May 29 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/29/14, 6:50 AM, Wyatt wrote:
 On Thursday, 29 May 2014 at 13:34:26 UTC, Joseph Rushton Wakeling via
 Digitalmars-d wrote:
 Minor point -- is it really going to be the clunky std.experimental,
 or is it going to be something elegant like exp.* ... ?

 I would prefer the latter. :-)
I think I would too. But failing that, since we have packages now, would std.experimental.* be an acceptable compromise? -Wyatt
Last thing we want is a terse nice name for something that's very likely to change. Also please don't analyze this to death. It's meant to reduce friction, not increase this. Andrei
May 29 2014
next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Friday, 30 May 2014 at 05:20:57 UTC, Andrei Alexandrescu wrote:
 Also please don't analyze this to death. It's meant to reduce 
 friction, not increase this.
I'm not sure whether your comment was just targeted at the naming discussions, but in general, I find it very valid to discuss the details of the proposal, especially the interaction with package management. The benefits of having std.experimental over just bundling dub with DMD must be clear and the separation well-defined. Otherwise, this change will only increase friction instead. Personally, I rather like the idea of std.experimental being a staging area for libraries that already passed some initial round of review (be it in the form of a dub package or otherwise) to get more widespread attention before being "set in stone". We desperately need something like this, as the review process has turned out to be to rigid for fear of including suboptimal APIs, yet at the same time has failed to catch several design problems as only few reviewers typically made an effort to actually use the code. I, however, don't think that std.experimental is a good way to gather initial feedback for a module, as the compiler release cycle is just too inflexible for that. David
May 30 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/30/14, 3:35 AM, David Nadlinger wrote:
 Personally, I rather like the idea of std.experimental being a staging
 area for libraries that already passed some initial round of review (be
 it in the form of a dub package or otherwise) to get more widespread
 attention before being "set in stone".
Affirmative. -- Andrei
May 30 2014
prev sibling parent reply "w0rp" <devw0rp gmail.com> writes:
On Friday, 30 May 2014 at 10:35:57 UTC, David Nadlinger wrote:
 On Friday, 30 May 2014 at 05:20:57 UTC, Andrei Alexandrescu 
 wrote:
 Also please don't analyze this to death. It's meant to reduce 
 friction, not increase this.
I'm not sure whether your comment was just targeted at the naming discussions, but in general, I find it very valid to discuss the details of the proposal, especially the interaction with package management. The benefits of having std.experimental over just bundling dub with DMD must be clear and the separation well-defined. Otherwise, this change will only increase friction instead. Personally, I rather like the idea of std.experimental being a staging area for libraries that already passed some initial round of review (be it in the form of a dub package or otherwise) to get more widespread attention before being "set in stone". We desperately need something like this, as the review process has turned out to be to rigid for fear of including suboptimal APIs, yet at the same time has failed to catch several design problems as only few reviewers typically made an effort to actually use the code. I, however, don't think that std.experimental is a good way to gather initial feedback for a module, as the compiler release cycle is just too inflexible for that. David
It's always, always easier to experiment by releasing a dub package. Including a module in the standard library requires the approval of a commity. You can always release a dub package, no one is going to stop you. std.experimental is probably best used for things that are 90% of the way into being included in std. We could find out how to address the remaining 10% then by seeing how people actually use the modules.
May 30 2014
parent Jacob Carlborg <doob me.com> writes:
On 30/05/14 12:53, w0rp wrote:

 It's always, always easier to experiment by releasing a dub package.
 Including a module in the standard library requires the approval of a
 commity. You can always release a dub package, no one is going to stop you.

 std.experimental is probably best used for things that are 90% of the
 way into being included in std. We could find out how to address the
 remaining 10% then by seeing how people actually use the modules.
I agree. In my opinion std.experimental would be for modules that have already passed the standard review process and are put in std.experimental for a couple of releases to battle test the API's. -- /Jacob Carlborg
Jun 01 2014
prev sibling parent Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 30/05/14 07:21, Andrei Alexandrescu via Digitalmars-d wrote:
 Also please don't analyze this to death. It's meant to reduce friction, not
 increase this.
Yea, sorry if I've been overly-obsessing on the details. Bottom line, I have some code in mind for it, which is not currently on code.dlang.org ;-)
May 30 2014
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 29 May 2014 09:33:59 -0400, Joseph Rushton Wakeling via  
Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 29/05/14 14:52, Steven Schveighoffer via Digitalmars-d wrote:
 In andrei's talk he said we should add std.experimental. I don't think  
 there was
 much discussion, people liked the idea. There was no discussion on how  
 things
 would be placed in there (i.e. up for debate), but it definitely is  
 going to be
 there. I actually did not know about code.dlang.org until Andrei  
 brought it up
 in his talk, so there may be quite a few people who aren't aware of it.
Minor point -- is it really going to be the clunky std.experimental, or is it going to be something elegant like exp.* ... ? I would prefer the latter. :-)
javax was the experimental branch for Java's experimental code. Now javax.xml is PERMANENT. I think "experimental" spells out "This is subject to immediate and frequent change. IT MAY BREAK YOUR CODE" std.experimental looks great to me ;) -Steve
May 29 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, May 29, 2014 at 10:47:26AM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
[...]
 javax was the experimental branch for Java's experimental code. Now
 javax.xml is PERMANENT.
 
 I think "experimental" spells out "This is subject to immediate and
 frequent change. IT MAY BREAK YOUR CODE"
No, change that last sentence to: IT *WILL* BREAK YOUR CODE. USE AT YOUR OWN RISK.
 std.experimental looks great to me ;)
[...] +1. T -- What are you when you run out of Monet? Baroque.
May 29 2014
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 29 May 2014 11:12:00 -0400, H. S. Teoh via Digitalmars-d  
<digitalmars-d puremagic.com> wrote:

 On Thu, May 29, 2014 at 10:47:26AM -0400, Steven Schveighoffer via  
 Digitalmars-d wrote:
 [...]
 javax was the experimental branch for Java's experimental code. Now
 javax.xml is PERMANENT.

 I think "experimental" spells out "This is subject to immediate and
 frequent change. IT MAY BREAK YOUR CODE"
No, change that last sentence to: IT *WILL* BREAK YOUR CODE. USE AT YOUR OWN RISK.
I suppose that is ultimately true if/when std.experimental.blah turns into std.blah. But for the most part, breaking code for fun or spite isn't the idea :) -Steve
May 29 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, May 29, 2014 at 12:03:43PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
 On Thu, 29 May 2014 11:12:00 -0400, H. S. Teoh via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 
On Thu, May 29, 2014 at 10:47:26AM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
[...]
I think "experimental" spells out "This is subject to immediate and
frequent change. IT MAY BREAK YOUR CODE"
No, change that last sentence to: IT *WILL* BREAK YOUR CODE. USE AT YOUR OWN RISK.
I suppose that is ultimately true if/when std.experimental.blah turns into std.blah. But for the most part, breaking code for fun or spite isn't the idea :)
[...] Well, I know that. :) The intention is to dispel all notion of API reliability and hold no qualms about breaking existing code in the future, that's all. T -- Talk is cheap. Whining is actually free. -- Lars Wirzenius
May 29 2014
prev sibling parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 29/05/14 16:47, Steven Schveighoffer via Digitalmars-d wrote:
 javax was the experimental branch for Java's experimental code. Now javax.xml
is
 PERMANENT.
Point taken. That said, I fear that _any_ module or package that gets widely used carries such a risk.
May 29 2014
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 29 May 2014 18:35:49 +0200
schrieb Joseph Rushton Wakeling via Digitalmars-d
<digitalmars-d puremagic.com>:

 On 29/05/14 16:47, Steven Schveighoffer via Digitalmars-d wrote:
 javax was the experimental branch for Java's experimental code. Now javax.xml
is
 PERMANENT.
Point taken. That said, I fear that _any_ module or package that gets widely used carries such a risk.
But why didn't they change it? o Didn't they make it clear enough that a rename is coming? o Was it known, but impractical to change all Java code? (I.e. closed source byte code files would break) o Were both the original xml implementation and javax.xml used too much to replace one with the other? (Assuming the APIs were different.) I remember javax being mentioned here a few times as to why "version 2" packages are proven bad, but noone ever mentioned what ultimately stopped Sun from moving javax.* packages. It is possible that in D we might have a different view on it. E.g. versioned Phobos shared libraries or better communication of what to expect from the experimental package. -- Marco
May 29 2014
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 29 May 2014 20:27:00 -0400, Marco Leise <Marco.Leise gmx.de> wrote:

 Am Thu, 29 May 2014 18:35:49 +0200
 schrieb Joseph Rushton Wakeling via Digitalmars-d
 <digitalmars-d puremagic.com>:

 On 29/05/14 16:47, Steven Schveighoffer via Digitalmars-d wrote:
 javax was the experimental branch for Java's experimental code. Now  
javax.xml is
 PERMANENT.
Point taken. That said, I fear that _any_ module or package that gets widely used carries such a risk.
But why didn't they change it? o Didn't they make it clear enough that a rename is coming? o Was it known, but impractical to change all Java code? (I.e. closed source byte code files would break) o Were both the original xml implementation and javax.xml used too much to replace one with the other? (Assuming the APIs were different.)
Too much customer code would break I think. By saying up front "this is experimental, expect breakage," the policy is clear, and complaints are shrugged off, nobody has anyone to blame but themselves. You may argue "Yeah, but javax was supposed to mean experimental," true, but it's not as nicely spelled out. Note that D is pretty much a static-library only system (there are some tinkerings with shared libraries, but nothing official). New code means recompile, so the USER of your app cannot break things by installing a new druntime. Java is different, so I don't know if they even could have done that. -Steve
May 30 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, May 30, 2014 at 12:06:34PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
[...]
 By saying up front "this is experimental, expect breakage," the policy
 is clear, and complaints are shrugged off, nobody has anyone to blame
 but themselves.
 
 You may argue "Yeah, but javax was supposed to mean experimental,"
 true, but it's not as nicely spelled out.
[...] Maybe we should call it std.broken_in_next_release. ;-) T -- I've been around long enough to have seen an endless parade of magic new techniques du jour, most of which purport to remove the necessity of thought about your programming problem. In the end they wind up contributing one or two pieces to the collective wisdom, and fade away in the rearview mirror. -- Walter Bright
May 30 2014
parent "Chris Williams" <yoreanon-chrisw yahoo.co.jp> writes:
On Friday, 30 May 2014 at 16:33:06 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 Maybe we should call it std.broken_in_next_release. ;-)


 T
import std.heretherebedragons.all;
May 30 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Joseph Rushton Wakeling:

 Minor point -- is it really going to be the clunky 
 std.experimental,
Clunky is good for something that you only use for experiments. Short names should be left for good reliable functionality. Bye, bearophile
May 29 2014
parent reply "Meta" <jared771 gmail.com> writes:
On Thursday, 29 May 2014 at 14:50:40 UTC, bearophile wrote:
 Joseph Rushton Wakeling:

 Minor point -- is it really going to be the clunky 
 std.experimental,
Clunky is good for something that you only use for experiments. Short names should be left for good reliable functionality. Bye, bearophile
Yes, I think this is a good case where making things slightly harder for users is good. If someone has to think twice about using std.experimental because of the long name, then they'll probably also think twice about how their code might break.
May 29 2014
parent "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 29 May 2014 at 15:44:11 UTC, Meta wrote:
 Yes, I think this is a good case where making things slightly 
 harder for users is good. If someone has to think twice about 
 using std.experimental because of the long name, then they'll 
 probably also think twice about how their code might break.
In keeping with this point, maybe also emit a warning when building? Something to the effect of: "WOAAAAH, hey there, you're using a module from std.experimental; don't expect it to work next week. Or ever." On a more serious note, what's the vision for bug reporting on this? If we just use the current Bugzilla, I'd imagine it should at least have its own keyword, but I wonder if it shouldn't just be its own component so it provides a clear separation from Phobos. (As a value-add, then the hypothetical warning can also tell them to report errors against it specifically rather than generating noise.) -Wyatt
May 29 2014
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
29-May-2014 11:55, David Nadlinger пишет:
 Hi all,

 There seems to have been some discussion regarding std.experimental at
 DConf, as several proposals to add modules to it have popped up over the
 last few days. Maybe Andrei's keynote had something on it (I
 unfortunately missed it)?
It was in the keynote and then it popped up in the git.
 In any case, could somebody please outline the discussion here? To me,
 directly proposing modules for std.experimental that haven't gone
 through being a (popular) code.dlang.org package first seems to be at
 odds with promoting the latter as an incubator for library development.
Personally I believe that anything not stable enough simply wouldn't work sitting in Phobos. The release cycle is like 4? months, patches need review (by whom? if its just smb's experiment). And there is the question of keeping 2 forks of the project - one for code.dlang.org and the other for std.experimental. Just putting dub in the distribution and making some featured libraries list is far better idea IMO.
 Best,
 David
-- Dmitry Olshansky
May 29 2014
parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 29/05/14 20:46, Dmitry Olshansky via Digitalmars-d wrote:
 Personally I believe that anything not stable enough simply wouldn't work
 sitting in Phobos. The release cycle is like 4? months, patches need review (by
 whom? if its just smb's experiment).
 And there is the question of keeping 2 forks of the project - one for
 code.dlang.org and the other for std.experimental.
If something's made it to std.experimental, is there any reason why there needs to be a maintained version in code.dlang.org ... ? As for cycle -- surely an option here is to have a faster Phobos-only release cycle that brings in updates _only_ of experimental modules.
May 29 2014
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
30-May-2014 02:15, Joseph Rushton Wakeling via Digitalmars-d пишет:
 On 29/05/14 20:46, Dmitry Olshansky via Digitalmars-d wrote:
 Personally I believe that anything not stable enough simply wouldn't work
 sitting in Phobos. The release cycle is like 4? months, patches need
 review (by
 whom? if its just smb's experiment).
 And there is the question of keeping 2 forks of the project - one for
 code.dlang.org and the other for std.experimental.
If something's made it to std.experimental, is there any reason why there needs to be a maintained version in code.dlang.org ... ? As for cycle -- surely an option here is to have a faster Phobos-only release cycle that brings in updates _only_ of experimental modules.
It's still syncing N project releases to 1 deadline. Not sensible to me. -- Dmitry Olshansky
May 29 2014
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 29 May 2014 at 22:16:09 UTC, Joseph Rushton Wakeling 
via Digitalmars-d wrote:
 On 29/05/14 20:46, Dmitry Olshansky via Digitalmars-d wrote:
 Personally I believe that anything not stable enough simply 
 wouldn't work
 sitting in Phobos. The release cycle is like 4? months, 
 patches need review (by
 whom? if its just smb's experiment).
 And there is the question of keeping 2 forks of the project - 
 one for
 code.dlang.org and the other for std.experimental.
If something's made it to std.experimental, is there any reason why there needs to be a maintained version in code.dlang.org ... ?
Because author of the module does not control Phobos and experimental stuff means, well, experiments.
 As for cycle -- surely an option here is to have a faster 
 Phobos-only release cycle that brings in updates _only_ of 
 experimental modules.
Lot of extra work for already solved problem. Not going to fly. Really, concept of experimental packages in standard libraries is one of those ideas that always seem good initially but has never worked good out there not for a single language. It is simply an incompatible concept.
May 29 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 29 May 2014 at 07:55:26 UTC, David Nadlinger wrote:
 Hi all,

 There seems to have been some discussion regarding 
 std.experimental at DConf, as several proposals to add modules 
 to it have popped up over the last few days. Maybe Andrei's 
 keynote had something on it (I unfortunately missed it)?

 In any case, could somebody please outline the discussion here? 
 To me, directly proposing modules for std.experimental that 
 haven't gone through being a (popular) code.dlang.org package 
 first seems to be at odds with promoting the latter as an 
 incubator for library development.

 Best,
 David
I have discussed this with Andrei shortly after he has merged PR that adds `std.experimental` to Phobos. Looks like he actually thinks about it as `std.staging` - place for almost complete Phobos modules to bring more attention to them while still being able to make breaking API changes. Choice of name is somewhat misleading. For actual experimental modules dub / code.dlang.org is absolutely superior solution, bleeding edge code does not fit into formal release cycle tied to compiler / Phobos. I hope we will be able to abandon std.experimental eventually when dub becomes more mature and easily recognized.
May 29 2014
prev sibling next sibling parent "HaraldZealot" <harald_zealot tut.by> writes:
std.experimintal is helpfull and I rejoy about.

But I think, we can have better place as subpackage.

I wrote some ideas about, but they have sunk in other topic.
http://forum.dlang.org/thread/ljrm0d$28vf$1 digitalmars.com?page=16#post-mdhlmsxfzaelpdgwfbfh:40forum.dlang.org
May 29 2014
prev sibling next sibling parent "Martin Nowak" <code dawg.eu> writes:
On Thursday, 29 May 2014 at 07:55:26 UTC, David Nadlinger wrote:
 Hi all,

 There seems to have been some discussion regarding 
 std.experimental at DConf, as several proposals to add modules 
 to it have popped up over the last few days. Maybe Andrei's 
 keynote had something on it (I unfortunately missed it)?

 In any case, could somebody please outline the discussion here? 
 To me, directly proposing modules for std.experimental that 
 haven't gone through being a (popular) code.dlang.org package 
 first seems to be at odds with promoting the latter as an 
 incubator for library development.
It supposed to have a higher visibility than code.dlang.org, but I agree that there is a certain overlap. From my point of view std.experimental should be used for modules where the API needs a bit more tweaking and some field tests. So if we already had that earlier, we'd probably have std.exp.d.lexer, std.exp.log and std.exp.benchmark by now. So I see it more as a staging area for new Phobos modules rather than as a free experimental space.
May 29 2014
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
David Nadlinger:

 There seems to have been some discussion regarding 
 std.experimental at DConf,
In the discussions of yesterday has emerged a feature of Rust I didn't know about: http://doc.rust-lang.org/rust.html#stability several levels of stability of functions and other parts of an API. And then you can receive warnings according to the kind of compilation you are using. All those levels (deprecated, experimental, unstable, stable, frozen, locked) seem a little overkill to me. In D we have "deprecated", that is a keyword. I think a level like "experimental" could be useful in D too. So beside having experimental modules in std.experimental we can also have experimental functions in non experimental modules. Bye, bearophile
Jun 11 2014