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