www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - new DIP41: dmd/rdmd command line overhaul.

reply Timothee Cour <thelastmammoth gmail.com> writes:
Abstract:
This DIP seeks to improve dmd and rdmd's command line flags, to make it
more self-consistent and consistent with other tools (including other D
compilers), more expandable, avoid existing corner cases, and better
interact with other tools such as rdmd. It also proposes new flags and
proposes a simple deprecation path to follow.

Link:
http://wiki.dlang.org/DIP41
May 21 2013
next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 21 May 2013 at 09:45:19 UTC, Timothee Cour wrote:

 Abstract:
 This DIP seeks to improve dmd and rdmd's command line flags, to 
 make it
 more self-consistent and consistent with other tools (including 
 other D
 compilers), more expandable, avoid existing corner cases, and 
 better
 interact with other tools such as rdmd. It also proposes new 
 flags and
 proposes a simple deprecation path to follow.

 Link:
 http://wiki.dlang.org/DIP41


Had only a quick read through but I like proposed changes 
overall. Current situation looks rather inconsistent and archaic. 
Don't know how much trouble proposed migration path will cause 
for large projects with custom build systems though.
May 21 2013
prev sibling next sibling parent reply "Mike Parker" <aldacron gmail.com> writes:
On Tuesday, 21 May 2013 at 09:45:19 UTC, Timothee Cour wrote:

 Abstract:
 This DIP seeks to improve dmd and rdmd's command line flags, to 
 make it
 more self-consistent and consistent with other tools (including 
 other D
 compilers), more expandable, avoid existing corner cases, and 
 better
 interact with other tools such as rdmd. It also proposes new 
 flags and
 proposes a simple deprecation path to follow.

 Link:
 http://wiki.dlang.org/DIP41


Looks good. But I would add one more. I'd like a dmd-specific 
flag for specifying the library path. Of course, on posix systems 
it's '-L-L/some/path', but I never can remember the format for 
OPTLINK (it involves a '+') and don't know offhand what it is for 
VS. In my build scripts, I just keep my libs local to the project 
tree and pass the full path of each library in order to avoid the 
hassle of trying to accommodate each possible linker. I'd love a 
new flag that would allow passing the libpath to DMD and let it 
handle putting it in the appropriate format for the current 
linker.
May 21 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-05-21 15:44, Mike Parker wrote:


 Looks good. But I would add one more. I'd like a dmd-specific flag for
 specifying the library path. Of course, on posix systems it's
 '-L-L/some/path', but I never can remember the format for OPTLINK (it
 involves a '+') and don't know offhand what it is for VS. In my build
 scripts, I just keep my libs local to the project tree and pass the full
 path of each library in order to avoid the hassle of trying to
 accommodate each possible linker. I'd love a new flag that would allow
 passing the libpath to DMD and let it handle putting it in the
 appropriate format for the current linker.


I wouldn't mind having that.

-- 
/Jacob Carlborg
May 21 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-05-21 11:44, Timothee Cour wrote:

 Abstract:
 This DIP seeks to improve dmd and rdmd's command line flags, to make it
 more self-consistent and consistent with other tools (including other D
 compilers), more expandable, avoid existing corner cases, and better
 interact with other tools such as rdmd. It also proposes new flags and
 proposes a simple deprecation path to follow.


Looks good.

-- 
/Jacob Carlborg
May 21 2013
prev sibling next sibling parent "Mr. Anonymous" <mailnew4ster gmail.com> writes:
On Tuesday, 21 May 2013 at 09:45:19 UTC, Timothee Cour wrote:

 Abstract:
 This DIP seeks to improve dmd and rdmd's command line flags, to 
 make it
 more self-consistent and consistent with other tools (including 
 other D
 compilers), more expandable, avoid existing corner cases, and 
 better
 interact with other tools such as rdmd. It also proposes new 
 flags and
 proposes a simple deprecation path to follow.

 Link:
 http://wiki.dlang.org/DIP41


Too many DIPs, none of which is actually implemented.
Looks like your strategy is flawed.
May 21 2013
prev sibling next sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
On Tuesday, 21 May 2013 at 09:45:19 UTC, Timothee Cour wrote:

 Abstract:
 This DIP seeks to improve dmd and rdmd's command line flags, to 
 make it
 more self-consistent and consistent with other tools (including 
 other D
 compilers), more expandable, avoid existing corner cases, and 
 better
 interact with other tools such as rdmd. It also proposes new 
 flags and
 proposes a simple deprecation path to follow.

 Link:
 http://wiki.dlang.org/DIP41


Regarding your suggestion about run arguments for rdmd - the 
convention is to use `--`:

    dmd main.d src1.d -- myfirstprogramarg

Beside being the convention, it's shorter and easier to type than 
`-args`, and it stands out more.
May 21 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/21/13 5:44 AM, Timothee Cour wrote:

 Abstract:
 This DIP seeks to improve dmd and rdmd's command line flags, to make it
 more self-consistent and consistent with other tools (including other D
 compilers), more expandable, avoid existing corner cases, and better
 interact with other tools such as rdmd. It also proposes new flags and
 proposes a simple deprecation path to follow.

 Link:
 http://wiki.dlang.org/DIP41


I think this DIP should be rejected. Even if implemented to perfection 
it would do nothing to make D better.

Overhauling command line syntax would only help if the situation was 
unbearable or if people couldn't do what they wanted to do. As things go 
I find the situation marginally clunkier than it could be, but command 
line syntax can never be beautiful or perfect.


Andrei
May 21 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2013 8:29 AM, Andrei Alexandrescu wrote:

 On 5/21/13 5:44 AM, Timothee Cour wrote:

 Abstract:
 This DIP seeks to improve dmd and rdmd's command line flags, to make it
 more self-consistent and consistent with other tools (including other D
 compilers), more expandable, avoid existing corner cases, and better
 interact with other tools such as rdmd. It also proposes new flags and
 proposes a simple deprecation path to follow.

 Link:
 http://wiki.dlang.org/DIP41


 I think this DIP should be rejected. Even if implemented to perfection it would
 do nothing to make D better.

 Overhauling command line syntax would only help if the situation was unbearable
 or if people couldn't do what they wanted to do. As things go I find the
 situation marginally clunkier than it could be, but command line syntax can
 never be beautiful or perfect.


I generally agree with Andrei here. People hate it when their makefiles break. 
There needs to be an awfully good reason to do it, not just clean up.

Also,

     dmd -man

suffices for "long help". There is no reason to have 3 different help texts.
May 21 2013
next sibling parent reply Timothee Cour <thelastmammoth gmail.com> writes:
On Tue, May 21, 2013 at 9:05 AM, Walter Bright
<newshound2 digitalmars.com>wrote:


 I generally agree with Andrei here. People hate it when their makefiles

 break. There needs to be an awfully good reason to do it, not just clean up.




In that post you seemed to agree:

http://forum.dlang.org/post/kk4ejt$1pnq$1 digitalmars.com

  >> I agree. The way to do it is to support both the old and the new ways
for now. Anyone want to do a pull req? Also, this should be put in bugzilla
as an enhancement request.
May 21 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2013 9:37 AM, Timothee Cour wrote:

 On Tue, May 21, 2013 at 9:05 AM, Walter Bright <newshound2 digitalmars.com
 <mailto:newshound2 digitalmars.com>> wrote:

         I generally agree with Andrei here. People hate it when their makefiles
         break. There needs to be an awfully good reason to do it, not just
clean up.



 In that post you seemed to agree:


I'm conflicted about it!


 http://forum.dlang.org/post/kk4ejt$1pnq$1 digitalmars.com

    >> I agree. The way to do it is to support both the old and the new ways for
 now. Anyone want to do a pull req? Also, this should be put in bugzilla as an
 enhancement request.
May 21 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-21 19:01, Walter Bright wrote:


 I'm conflicted about it!


D will never be good if we're so afraid of breaking changes.

-- 
/Jacob Carlborg
May 21 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/21/13 1:14 PM, Jacob Carlborg wrote:

 On 2013-05-21 19:01, Walter Bright wrote:


 I'm conflicted about it!


 D will never be good if we're so afraid of breaking changes.


Conversely D will never be good if we make too many breaking changes.

Andrei
May 21 2013
parent "Dicebot" <m.strashun gmail.com> writes:
Eternal struggle!
May 21 2013
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, May 21, 2013 19:14:52 Jacob Carlborg wrote:

 On 2013-05-21 19:01, Walter Bright wrote:

 I'm conflicted about it!


 
 D will never be good if we're so afraid of breaking changes.


We need to be willing to make breaking changes when we actually need to make 
them and avoid them when we don't. We're past the point when we can tweak 
everything to improve it. There are too many people using D now and too many 
of them wanting stability for us to continue to make minor tweaks. Breaking 
changes need to provide real value. Unfortunately, in some cases, that means 
being stuck with some things that are less than ideal, but if we're forever 
tweaking everything to improve it, we'll never be stable enough for people to 
be able to depend on us for real work.

I'd _love_ for the command line flags for dmd to be fixed so that they didn't 
use - for multi-character flags and other nonsense like that, but much as I 
think that what we have is sloppy, it still works reasonably well, and dealing 
with compiler flags takes up a very small portion of D development time. So, 
while the situation isn't ideal, I don't think that it's ultimately a big 
deal.

- Jonathan M Davis
May 21 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-21 23:11, Jonathan M Davis wrote:


 We need to be willing to make breaking changes when we actually need to make
 them and avoid them when we don't. We're past the point when we can tweak
 everything to improve it. There are too many people using D now and too many
 of them wanting stability for us to continue to make minor tweaks. Breaking
 changes need to provide real value. Unfortunately, in some cases, that means
 being stuck with some things that are less than ideal, but if we're forever
 tweaking everything to improve it, we'll never be stable enough for people to
 be able to depend on us for real work.


D is far from being called anything near stable. Every single release of 
DMD has broken DWT. I don't know for how many releases but quite many. 
Probably the whole 2.05x and 2.06x series.

-- 
/Jacob Carlborg
May 21 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2013 11:40 PM, Jacob Carlborg wrote:

 D is far from being called anything near stable. Every single release of DMD
has
 broken DWT. I don't know for how many releases but quite many. Probably the
 whole 2.05x and 2.06x series.


The current beta 4 is pretty much it. Please run DWT for it today and post any 
regressions found.
May 22 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-05-22 15:52, Walter Bright wrote:


 The current beta 4 is pretty much it. Please run DWT for it today and
 post any regressions found.


I have already received pull requests for the beta, kudos to kntroh, but 
I have tried the latest one. I can do that.

-- 
/Jacob Carlborg
May 22 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-05-22 15:52, Walter Bright wrote:


 The current beta 4 is pretty much it. Please run DWT for it today and
 post any regressions found.


I posted this to the beta mailing list as well:

I get the following error compiling DWT:

"static_this without 'this' cannot be shared"

This is most likely a correct change (I've already fixed the code) but 
there was no warnings, no depreciation message, it just suddenly stopped 
compiling.

Again, please stop pretending D is stable.

-- 
/Jacob Carlborg
May 23 2013
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, May 22, 2013 08:40:46 Jacob Carlborg wrote:

 D is far from being called anything near stable. Every single release of
 DMD has broken DWT. I don't know for how many releases but quite many.
 Probably the whole 2.05x and 2.06x series.


And continuing to tweak APIs and the like for minor improvements won't help 
with that. Yes, it's still the case that too much breaks from release to 
release, but I believe that that's mostly an issue of compiler regressions at 
this point, and those only get caught if enough people try the beta (which is 
why some have been pushing for Walter to announce the beta in D.announce 
rather than just in the beta list, which he's done this time around). Even if 
the situation isn't yet where we want it to be, it _is_ improving, and we want 
to make sure that the decisions that we make encourage stability so that we 
_will_ be considered stable in the near future.

- Jonathan M Davis
May 22 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-22 20:26, Jonathan M Davis wrote:


 And continuing to tweak APIs and the like for minor improvements won't help
 with that. Yes, it's still the case that too much breaks from release to
 release, but I believe that that's mostly an issue of compiler regressions at
 this point, and those only get caught if enough people try the beta (which is
 why some have been pushing for Walter to announce the beta in D.announce
 rather than just in the beta list, which he's done this time around). Even if
 the situation isn't yet where we want it to be, it _is_ improving, and we want
 to make sure that the decisions that we make encourage stability so that we
 _will_ be considered stable in the near future.


I have not so much problem with the breaking in it self. It's rather 
that there are several people here pretending D is stable.

-- 
/Jacob Carlborg
May 22 2013
parent reply "Zach the Mystic" <reachzach gggggmail.com> writes:
On Wednesday, 22 May 2013 at 18:46:55 UTC, Jacob Carlborg wrote:

 I have not so much problem with the breaking in it self. It's 
 rather that there are several people here pretending D is 
 stable.


I think that on the surface, saying something is "stable" makes 
it sound like that is always good. So it's a public relations win 
if you can say your product is stable. But the truth is that if 
what is "stable" is a really bad design decision or a flat out 
bug, then that kind of "stability" is bad. But since so many 
people think stability is always good (it certainly *sounds* 
good), I can understand why there is a reluctance to admit that 
there is a lack of stability.

If only there were a way to communicate, "Yes, there is a lack of 
stability, but it's for darn good reasons!" Until that way is 
found, there must always be a tension between doing the "right 
thing", and convincing people it's more "stable" than it really 
is.
May 22 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/22/2013 5:07 PM, Zach the Mystic wrote:

 If only there were a way to communicate, "Yes, there is a lack of stability,
but
 it's for darn good reasons!" Until that way is found, there must always be a
 tension between doing the "right thing", and convincing people it's more
 "stable" than it really is.


And then there are those "I don't think we should introduce breaking changes, 
and here's my list of must-have features that break things." :-)
May 22 2013
next sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
On Thursday, 23 May 2013 at 01:24:34 UTC, Walter Bright wrote:

 On 5/22/2013 5:07 PM, Zach the Mystic wrote:

 If only there were a way to communicate, "Yes, there is a lack 
 of stability, but
 it's for darn good reasons!" Until that way is found, there 
 must always be a
 tension between doing the "right thing", and convincing people 
 it's more
 "stable" than it really is.


 And then there are those "I don't think we should introduce 
 breaking changes, and here's my list of must-have features that 
 break things." :-)


I can't help but think that success itself poses a problem for a 
programming language. The smaller the user base, the better it 
can absorb the shock, and the more loyal it is. But once you 
become mainstream, now people are using your language because 
they *have* to - I suspect it's these people who will demand 
stability above all else, because they don't care where the 
language came from or why any of the important decisions were 
made. They just want to get their work done.

Therefore, seize the day! The more people use D, the harder it 
will be to do the right thing - engineering-wise! But D is not 
designed for a small user base. It is designed to last. Be like 
the Tao!
May 22 2013
prev sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 23 May 2013 at 01:24:34 UTC, Walter Bright wrote:

 And then there are those "I don't think we should introduce 
 breaking changes, and here's my list of must-have features that 
 break things." :-)


I can't even remember last time when it was the case.
May 23 2013
prev sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
Except D is nowhere close to stable, it only pretends to. Every 
single release breaks the code. Every. Usual attitude "well, it 
is a breaking change and a lot of users will be screwed, but it 
is a bug fix, so we are all right?". No, you are not. I can't 
imagine where such definition of "breaking" came from, it is 
literally single most disastrous thing in D development process.

And I have proposed various ways to address it properly via 
release process numerous times. Every single topic was ignored 
both by Andrei and Walter. Because, yeah, it isn't real problem, 
is it?

On Tuesday, 21 May 2013 at 21:11:36 UTC, Jonathan M Davis wrote:

 We need to be willing to make breaking changes when we actually 
 need to make
 them and avoid them when we don't. We're past the point when we 
 can tweak
 everything to improve it. There are too many people using D now 
 and too many
 of them wanting stability for us to continue to make minor 
 tweaks. Breaking
 changes need to provide real value. Unfortunately, in some 
 cases, that means
 being stuck with some things that are less than ideal, but if 
 we're forever
 tweaking everything to improve it, we'll never be stable enough 
 for people to
 be able to depend on us for real work.
May 22 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/22/13 4:25 AM, Dicebot wrote:

 Except D is nowhere close to stable, it only pretends to. Every single
 release breaks the code. Every. Usual attitude "well, it is a breaking
 change and a lot of users will be screwed, but it is a bug fix, so we
 are all right?". No, you are not. I can't imagine where such definition
 of "breaking" came from, it is literally single most disastrous thing in
 D development process.


At a level it should be obvious that not all breakages are equal. It's 
better to suffer from few and well-motivated breakages that actually fix 
real problems and improve user code, than from arbitrary breakages 
caused by name churn. To just put them under the same umbrella "this 
release broke my build" would miss important details.


 And I have proposed various ways to address it properly via release
 process numerous times. Every single topic was ignored both by Andrei
 and Walter. Because, yeah, it isn't real problem, is it?


Of course it is a problem. There have been numerous discussions on the 
topic indeed, and we are evidently trying to improve things.

I only count one discussion initiated by you ("Release process and 
backwards compatibility" started on March 8, 2013 at 
http://forum.dlang.org/thread/nchvayzsbrzevvucmmmi forum.dlang.org. That 
discussion has had some 15 responses from 7 people, none of whom seemed 
to quite rally behind your point. I am sorry you feel that particular 
idea has not received the attention you believe it deserves, but it 
would be much to accuse me or Walter of deliberately ignoring it.


Andrei
May 22 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Wednesday, 22 May 2013 at 13:38:54 UTC, Andrei Alexandrescu 
wrote:

 At a level it should be obvious that not all breakages are 
 equal. It's better to suffer from few and well-motivated 
 breakages that actually fix real problems and improve user 
 code, than from arbitrary breakages caused by name churn. To 
 just put them under the same umbrella "this release broke my 
 build" would miss important details.


This is _exactly_ the mindset I am trying to fight with. I have 
had an unpleasant experience of working in typical enterprise 
environment for few years and there is quite a strong attitude 
about this - no one cares about reasons for code breakage. For 
those who care about breakage, it is a boolean flag - either 
breaks, or not.

Contrary to this, there are plenty of people ( I am sure you know 
lot of them at least from this newsgroup ;) ) who can accept any 
breaking change for a greater good if reasonable tool to deal 
with it is provided.

I don't believe it is the case where you can both eat the cookie 
and have it.


 Of course it is a problem. There have been numerous discussions 
 on the topic indeed, and we are evidently trying to improve 
 things.


I don't see those evidences. That is the issue. We keep speaking 
on newsgroup about how important stability is, keep rejecting 
proposal because of this and keep releasing dmd that breaks 
stuff. The very next one will do it again - we both were 
participating in that mail list thread after all.

There are some good improvements in details (like "-transition" 
switch Kenji has implemented), but overall attitude does not seem 
to change.


 I only count one discussion initiated by you ("Release process 
 and backwards compatibility" started on March 8, 2013 at 
 http://forum.dlang.org/thread/nchvayzsbrzevvucmmmi forum.dlang.org. 
 That discussion has had some 15 responses from 7 people, none 
 of whom seemed to quite rally behind your point. I am sorry you 
 feel that particular idea has not received the attention you 
 believe it deserves, but it would be much to accuse me or 
 Walter of deliberately ignoring it.


I am very sorry if it sounds offensively, but not leaving a 
single comment in a thread that essentially is created to ask 
language authors their opinion about development/release process 
is quite the same as ignoring. If you wanted more opinions about 
it, you could have just mentioned it. No one can make this call 
but you.
May 22 2013
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 22 May 2013 at 14:09:57 UTC, Dicebot wrote:

 no one cares about reasons for code breakage. For those who 
 care about breakage, it is a boolean flag - either breaks, or 
 not.


This may well be the case, but you're missing the point:

Breakage is always bad, so we avoid it *unless* the change adds 
some significant value to the language.
Fixing a bug (almost) always adds significant value.
Changing command line syntax, in my opinion (and, it would 
appear, Walter and Andrei's) does not add significant value.

Although each individual person who suffers breakage may not care 
why it happened, this does not in any way constitute an argument 
for allowing less important changes to break stuff.
May 22 2013
next sibling parent reply "timotheecour" <timothee.cour2 gmail.com> writes:
looks like no one read the DIP till the last section :)

I proposed there 2 ways to support both current flags and new 
flags, without possible confusion nor code breakage.

2a): dmd -flagstyle=new -of=blah ... (+ other stuff/deprecations 
taken into account)
2b): dmd2 (reminds of D2, ldc2, ldmd2), which behaves as dmd 
-flagstyle=new.

Either of those 2 options will break nothing, code that uses dmd 
-ofblah (etc) would continue to work. It's all described in DIP. 
Improvements are welcome.
May 22 2013
parent reply =?UTF-8?B?Ikx1w61z?= Marques" <luismarques gmail.com> writes:
On Wednesday, 22 May 2013 at 16:50:45 UTC, timotheecour wrote:

 2a): dmd -flagstyle=new -of=blah ... (+ other 
 stuff/deprecations taken into account)
 2b): dmd2 (reminds of D2, ldc2, ldmd2), which behaves as dmd 
 -flagstyle=new.


I think dmd2 should be the new compiler binary, and dmd should be 
changed into a thin "driver" that converts the old syntax into 
the new and calls dmd2 (or just calls into a common shared 
library).

*No breaking changes*. So, *no strong reason* not to improve the 
command line syntax.

D is great, but the syntax of dmd makes for a bad first 
impression, which is vital in a "new" language.
May 23 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/23/13 12:40 PM, "Luís Marques" <luismarques gmail.com>" wrote:

 D is great, but the syntax of dmd makes for a bad first impression,
 which is vital in a "new" language.


I think this is overblown. First thing people use is rdmd without flags, 
which just works. Then, builds using flags are snuck in a makefile or 
script and forgotten about. It's just the way things get done. Compiler 
flags are not something one messes with all the time (like e.g. git's).

I agree there is a standardized way of dealing with options on modern 
Unixen. I agree dmd does not abide to it. I agree dmd could be made to 
abide to it with the appropriate care. I am not sure whether it's worth 
anyone's time to look into that.


Andrei
May 23 2013
parent reply =?UTF-8?B?Ikx1w61z?= Marques" <luismarques gmail.com> writes:
On Thursday, 23 May 2013 at 17:29:44 UTC, Andrei Alexandrescu 
wrote:

 I think this is overblown. First thing people use is rdmd 
 without flags, which just works. Then, builds using flags are 
 snuck in a makefile or script and forgotten about. It's just 
 the way things get done. Compiler flags are not something one 
 messes with all the time (like e.g. git's).


Maybe you are right and I'm exaggerating the importance of this. 
But isn't the dmd/dmd2 solution I argued for also one with a very 
small downside?
May 23 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, May 23, 2013 20:27:23 =?UTF-8?B?Ikx1w61z?=.Marques 
<luismarques gmail.com> puremagic.com wrote:

 On Thursday, 23 May 2013 at 17:29:44 UTC, Andrei Alexandrescu
 
 wrote:

 I think this is overblown. First thing people use is rdmd
 without flags, which just works. Then, builds using flags are
 snuck in a makefile or script and forgotten about. It's just
 the way things get done. Compiler flags are not something one
 messes with all the time (like e.g. git's).


 
 Maybe you are right and I'm exaggerating the importance of this.
 But isn't the dmd/dmd2 solution I argued for also one with a very
 small downside?


As long as the flags don't conflict, it would probably be better to just 
introduce the new flags and then undocument the old flags (and deprecate them
if 
we want to actually work toward removing them - or just leave them 
undocumented if we don't want to have that breakage). That would work just fine 
save perhaps for a bit of confusion at first if both sets of flags are
available 
and in the docs and --help. So, if we want to make the change, I think that 
it's obvious enough how to go about. It's more a question of whether we want 
to do it.

- Jonathan M Davis
May 23 2013
parent reply =?UTF-8?B?Ikx1w61z?= Marques" <luismarques gmail.com> writes:
On Thursday, 23 May 2013 at 18:35:56 UTC, Jonathan M Davis wrote:

 As long as the flags don't conflict, it would probably be 
 better to just
 introduce the new flags and then undocument the old flags (and 
 deprecate them if
 we want to actually work toward removing them - or just leave 
 them
 undocumented if we don't want to have that breakage). That 
 would work just fine
 save perhaps for a bit of confusion at first if both sets of 
 flags are available
 and in the docs and --help. So, if we want to make the change, 
 I think that
 it's obvious enough how to go about. It's more a question of 
 whether we want
 to do it.


I think two binaries is cleaner, less prone to confusion and 
allows less cluttered help info.
May 23 2013
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, May 23, 2013 20:42:47 =?UTF-8?B?Ikx1w61z?=.Marques 
<luismarques gmail.com> puremagic.com wrote:

 On Thursday, 23 May 2013 at 18:35:56 UTC, Jonathan M Davis wrote:

 As long as the flags don't conflict, it would probably be
 better to just
 introduce the new flags and then undocument the old flags (and
 deprecate them if
 we want to actually work toward removing them - or just leave
 them
 undocumented if we don't want to have that breakage). That
 would work just fine
 save perhaps for a bit of confusion at first if both sets of
 flags are available
 and in the docs and --help. So, if we want to make the change,
 I think that
 it's obvious enough how to go about. It's more a question of
 whether we want
 to do it.


 
 I think two binaries is cleaner, less prone to confusion and
 allows less cluttered help info.


It also permanently creates the confusion of what the difference between the 
two is. If we made the switch, the old flags would be marked as such and 
removed from the docs at some point in the future (possibly even immediately), 
so I think that the only confusion that we'd really have to worry about would 
be people looking at the flags used in current projects and not seeing them in 
the --help or documentation (though even if they aren't in the help, they 
should probably be in a separate section of the documentation, which would 
mitigate that problem).

Creating multiple aliases to the same thing is generally going to create 
confusion, and making one of them slightly different isn't really going to 
help. People would forever be inquiring about the difference between dmd and 
dmd2. I definitely think that it would be cleaner in the long run to just 
transition dmd if we want to change the flags.

- Jonathan M Davis
May 23 2013
prev sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
On Wednesday, 22 May 2013 at 14:37:10 UTC, John Colvin wrote:

 On Wednesday, 22 May 2013 at 14:09:57 UTC, Dicebot wrote:

 no one cares about reasons for code breakage. For those who 
 care about breakage, it is a boolean flag - either breaks, or 
 not.


 This may well be the case, but you're missing the point:

 Breakage is always bad, so we avoid it *unless* the change adds 
 some significant value to the language.
 Fixing a bug (almost) always adds significant value.
 Changing command line syntax, in my opinion (and, it would 
 appear, Walter and Andrei's) does not add significant value.

 Although each individual person who suffers breakage may not 
 care why it happened, this does not in any way constitute an 
 argument for allowing less important changes to break stuff.


You seem to misunderstand what angers me and Jacob here. It is 
not the fact that this specific DIP is rejected (I don't really 
care), it is the fact that D developers keep repeating "D goes 
stable" mantra when it actually does not. Pretending to 
prioritize stability and breaking code even with bug fixes is 
technically lying. Bad for reputation, bad for marketing. And 
good luck using "They have a different understanding of 
stability" line in a dialog with enterprise type manager.

If stability is really a priority - please start doing something 
real about it. At least start with defining what "stability" 
means and what guarantees D team can give for users. Publish it 
at dlang.org and it is at least a start.

Or stop rejecting stuff using "stability" as smoke screen. This 
two options exclude each other.
May 22 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/22/13 3:04 PM, Dicebot wrote:

 On Wednesday, 22 May 2013 at 14:37:10 UTC, John Colvin wrote:

 On Wednesday, 22 May 2013 at 14:09:57 UTC, Dicebot wrote:

 no one cares about reasons for code breakage. For those who care
 about breakage, it is a boolean flag - either breaks, or not.


 This may well be the case, but you're missing the point:

 Breakage is always bad, so we avoid it *unless* the change adds some
 significant value to the language.
 Fixing a bug (almost) always adds significant value.
 Changing command line syntax, in my opinion (and, it would appear,
 Walter and Andrei's) does not add significant value.

 Although each individual person who suffers breakage may not care why
 it happened, this does not in any way constitute an argument for
 allowing less important changes to break stuff.


 You seem to misunderstand what angers me and Jacob here. It is not the
 fact that this specific DIP is rejected (I don't really care), it is the
 fact that D developers keep repeating "D goes stable" mantra when it
 actually does not. Pretending to prioritize stability and breaking code
 even with bug fixes is technically lying. Bad for reputation, bad for
 marketing. And good luck using "They have a different understanding of
 stability" line in a dialog with enterprise type manager.

 If stability is really a priority - please start doing something real
 about it. At least start with defining what "stability" means and what
 guarantees D team can give for users. Publish it at dlang.org and it is
 at least a start.

 Or stop rejecting stuff using "stability" as smoke screen. This two
 options exclude each other.


I don't understand what you're sustaining. We all want D to become more 
stable. It's not a smoke screen or a pretext to reject improvements.

My understanding of your reasoning is:

1. Stability is something binary, if you break some code no matter how 
much code and on what grounds - if you break it stability is zero. If 
you don't break any code at all, then stability is one. There is no 
intermediate state between zero and one.

2. By definition (1), D is not stable.

3. Therefore since it's not stable, let's accept whatever changes 
because they won't make anyone's life worse.

Is my interpretation correct? If so, do you understand reasonable people 
may disagree with the reasoning above?


Andrei
May 22 2013
next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Wednesday, 22 May 2013 at 21:15:24 UTC, Andrei Alexandrescu 
wrote:

 My understanding of your reasoning is:

 1. Stability is something binary, if you break some code no 
 matter how much code and on what grounds - if you break it 
 stability is zero. If you don't break any code at all, then 
 stability is one. There is no intermediate state between zero 
 and one.

 2. By definition (1), D is not stable.

 3. Therefore since it's not stable, let's accept whatever 
 changes because they won't make anyone's life worse.

 Is my interpretation correct? If so, do you understand 
 reasonable people may disagree with the reasoning above?


1 and 2 are correct. But 3 is actually "Since it is not stable, 
stop pretend it is in its current state".

Stability is something much more than just an intention. It is a 
formal promise and well-defined process. I don't want feature 
change anarchy, I want _true_ stability. It just happens that 
true stability often accepts inevitability of change and strictly 
defines what changes can be done and, most importantly, how it 
can be done.

Of course people (and D developers) can disagree. But what about 
at least defining (on dlang.org) _your_ view on stability and 
what guarantees that does provide for users? Isn't this a 
reasonable request? Because currently it is more like buzz word.
May 22 2013
prev sibling next sibling parent Dmitry S <ds.dlang gmail.com> writes:
I recall Andrei's talk about what to do if you want a million users. Do as
you would do if you had a million users.

Certain changes make sense to have if D is to have a million users. Some of
them, unfortunately, would be a pointless hassle to existing users. It's a
difficulty that unlikely to get solved through arguing.

One possible approach would be as with python 2 vs python 3. Have a
"different" D branch that pays far less attention to current users, and far
more to the millions ahead. And build conversion tools alongside, to help
current users convert when (and IF) the new branch succeeds in being
significantly better.

Dmitry

On Wed, May 22, 2013 at 5:15 PM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 On 5/22/13 3:04 PM, Dicebot wrote:


 On Wednesday, 22 May 2013 at 14:37:10 UTC, John Colvin wrote:


 On Wednesday, 22 May 2013 at 14:09:57 UTC, Dicebot wrote:


 no one cares about reasons for code breakage. For those who care
 about breakage, it is a boolean flag - either breaks, or not.


 This may well be the case, but you're missing the point:

 Breakage is always bad, so we avoid it *unless* the change adds some
 significant value to the language.
 Fixing a bug (almost) always adds significant value.
 Changing command line syntax, in my opinion (and, it would appear,
 Walter and Andrei's) does not add significant value.

 Although each individual person who suffers breakage may not care why
 it happened, this does not in any way constitute an argument for
 allowing less important changes to break stuff.


 You seem to misunderstand what angers me and Jacob here. It is not the
 fact that this specific DIP is rejected (I don't really care), it is the
 fact that D developers keep repeating "D goes stable" mantra when it
 actually does not. Pretending to prioritize stability and breaking code
 even with bug fixes is technically lying. Bad for reputation, bad for
 marketing. And good luck using "They have a different understanding of
 stability" line in a dialog with enterprise type manager.

 If stability is really a priority - please start doing something real
 about it. At least start with defining what "stability" means and what
 guarantees D team can give for users. Publish it at dlang.org and it is
 at least a start.

 Or stop rejecting stuff using "stability" as smoke screen. This two
 options exclude each other.


 I don't understand what you're sustaining. We all want D to become more
 stable. It's not a smoke screen or a pretext to reject improvements.

 My understanding of your reasoning is:

 1. Stability is something binary, if you break some code no matter how
 much code and on what grounds - if you break it stability is zero. If you
 don't break any code at all, then stability is one. There is no
 intermediate state between zero and one.

 2. By definition (1), D is not stable.

 3. Therefore since it's not stable, let's accept whatever changes because
 they won't make anyone's life worse.

 Is my interpretation correct? If so, do you understand reasonable people
 may disagree with the reasoning above?


 Andrei
May 22 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-22 23:15, Andrei Alexandrescu wrote:


 I don't understand what you're sustaining. We all want D to become more
 stable. It's not a smoke screen or a pretext to reject improvements.


It's a big difference say we want D to _become_ stable and saying D _is_ 
stable. There are many people here using the latter. I don't agree with 
them.

-- 
/Jacob Carlborg
May 23 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/23/13 3:07 AM, Jacob Carlborg wrote:

 On 2013-05-22 23:15, Andrei Alexandrescu wrote:


 I don't understand what you're sustaining. We all want D to become more
 stable. It's not a smoke screen or a pretext to reject improvements.


 It's a big difference say we want D to _become_ stable and saying D _is_
 stable. There are many people here using the latter. I don't agree with
 them.


I agree with you :o).

Andrei
May 23 2013
prev sibling parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 22 May 2013 at 14:09:57 UTC, Dicebot wrote:

 This is _exactly_ the mindset I am trying to fight with. I have 
 had an unpleasant experience of working in typical enterprise 
 environment for few years and there is quite a strong attitude 
 about this - no one cares about reasons for code breakage. For 
 those who care about breakage, it is a boolean flag - either 
 breaks, or not.


I think this is a mindset that needs to die. Consider why someone 
would choose to use D.

D provides an improved experience over the language being used. 
How did D achieve this? It was by being one big breaking change. 
Everyone using D is reaping benefits from D choosing that it will 
not compile all C code.

So while people claim they don't want breaking change, what they 
really mean is "I only want breaking change when I decide I to 
take it." And each person/situation will have different desire on 
what they wish to have broken. What we want is to select changes 
that people will want, make it easy to make/expect the changes, 
and enough time they will make the choice on their own.

D is stabilizing and is stable enough for many. We want to make 
progress in that direction, we don't want to just halt 
development like was done at D1. We have been making it less 
painful to upgrade and that effort should continue and doesn't 
need to be through a "no breaking changes" mandate.
May 22 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, May 23, 2013 01:35:13 Jesse Phillips wrote:

 D is stabilizing and is stable enough for many. We want to make
 progress in that direction, we don't want to just halt
 development like was done at D1. We have been making it less
 painful to upgrade and that effort should continue and doesn't
 need to be through a "no breaking changes" mandate.


What it comes down to is that breaking changes must provide a sufficiently high 
ROI, or they're unacceptable. The classic example of this from Walter is 
renaming stuff. The ROI on that is generally very small, so he's pretty much 
always completely against it even if he agreed that the proposed name was 
better. An example of where the ROI was very was in making it so that implicit 
fallthrough on switches was illegal. That's not just aesthetic. It catches 
real bugs.

The trick then is figuring out with any proposed change whether the ROI is high 
enough to make the change worth it. And Walter and Andrei (particularly 
Walter) lean heavily towards thinking that the ROI on breaking changes must be 
very high before they're acceptable. So, anyone arguing for a breaking change 
has a very high bar to meet. Maybe that bar is too high sometimes, but if it's 
too low, then we'll never reach the point where you can reasonably expect your 
code to continue to compile with every new release of dmd (or at least for a 
long time).

So, it's not the case that breaking changes are absolutely unacceptable, but 
it _is_ the case that anyone wanting a breaking change has to present a very 
strong case. And I don't think that that's necessarily a bad thing. In fact, 
as the language and its implementation matures, it's pretty much a necessity.

- Jonathan M Davis
May 22 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Wednesday, 22 May 2013 at 23:52:25 UTC, Jonathan M Davis wrote:

 What it comes down to is that breaking changes must provide a 
 sufficiently high
 ROI, or they're unacceptable.


And what was the reason to take this as an axiom? What makes you 
think core D developers can decide for all other D users what is 
sufficiently high ROI and what is not? For _everyone_. And how do 
you define "sufficiently high"?

That is exactly what I call "intention-based stability". Your 
intentions are good and goal is noble but lack of strict rules 
make it essentially useless. Problem is, "stability" is not some 
abstract merit that can be measured. It is a certain expectation 
with pragmatical use cases.

One good way to make compiler/language stable is to ask "Why do 
people need it stable? What problems does it solve? How our 
guarantees help?". And most common answer for first question I 
have encountered so far : "Because people hate to spend time in 
the middle of project to fix unexpected issues from already 
working code base". Note that this has nothing to do with 
features, or ROI, or correctness, or whatever. It is all about 
expectation of a change. And despite all efforts, D falls 
miserably here. See current beta mailing list for several 
examples of what should have never happened in real stable 
development process.
May 23 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/23/2013 2:01 AM, Dicebot wrote:

 See current beta mailing list for several
 examples of what should have never happened in real stable development process.


The reason it is a beta is so we can identify problems and deal with them
before 
a release.
May 23 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 23 May 2013 at 09:26:31 UTC, Walter Bright wrote:

 On 5/23/2013 2:01 AM, Dicebot wrote:

 See current beta mailing list for several
 examples of what should have never happened in real stable 
 development process.


 The reason it is a beta is so we can identify problems and deal 
 with them before a release.


In perfect world beta exists to identify problems _unknown_ 
before. Almost all issues I have seen mentioned so far was known 
by developers (those were bug fixes after all) but considered 
acceptable to put into compiler anyway. And that is a problem.
May 23 2013
parent reply "Mr. Anonymous" <mailnew4ster gmail.com> writes:
On Thursday, 23 May 2013 at 09:29:22 UTC, Dicebot wrote:

 On Thursday, 23 May 2013 at 09:26:31 UTC, Walter Bright wrote:

 On 5/23/2013 2:01 AM, Dicebot wrote:

 See current beta mailing list for several
 examples of what should have never happened in real stable 
 development process.


 The reason it is a beta is so we can identify problems and 
 deal with them before a release.


 In perfect world beta exists to identify problems _unknown_ 
 before. Almost all issues I have seen mentioned so far was 
 known by developers (those were bug fixes after all) but 
 considered acceptable to put into compiler anyway. And that is 
 a problem.


I don't think it's possible for a language to both evolve and 
keep being stable. At least not with the current release process, 
with a single branch.

There should at least be 2 branches - stable (as in binary stable 
- 0% code breakage), and experimental/beta/you name it, which 
breaks code when reasonable.
Then, after some amount of time, this experimental branch becomes 
the new stable branch (while the previous is still available for 
download).

I think the "Development and Release Process" wiki page proposes 
exactly that.
http://wiki.dlang.org/Release_Process
May 23 2013
parent "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 23 May 2013 at 09:39:18 UTC, Mr. Anonymous wrote:

 I think the "Development and Release Process" wiki page 
 proposes exactly that.
 http://wiki.dlang.org/Release_Process


Yeah, it is how it is usually done and it was proposed numerous 
times in various forms. But unless those who actually do release 
will adopt it and truly believe it is the way to go - it is just 
a text.
May 23 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/23/13 5:01 AM, Dicebot wrote:

 On Wednesday, 22 May 2013 at 23:52:25 UTC, Jonathan M Davis wrote:

 What it comes down to is that breaking changes must provide a
 sufficiently high
 ROI, or they're unacceptable.


 And what was the reason to take this as an axiom? What makes you think
 core D developers can decide for all other D users what is sufficiently
 high ROI and what is not? For _everyone_. And how do you define
 "sufficiently high"?


You are right. As Bjarne famously said, "no one knows what most 
programmers do". We can at best make guesses or use proxies to infer 
what is best for our community. Conversely, a small vocal minority of 
the community would have difficulty claiming to be the most 
representative sample.

It's an imperfect system, and we do our best with what we know, whom we 
work with, and what we believe. We all have the same goal. To be frank - 
relax. There's no reason to get overly combative over this.


 That is exactly what I call "intention-based stability". Your intentions
 are good and goal is noble but lack of strict rules make it essentially
 useless. Problem is, "stability" is not some abstract merit that can be
 measured. It is a certain expectation with pragmatical use cases.


Yes but we get back to the binary notion that you seem to endorse: every 
breakage is as bad, and any breakage creates a precedent for any other 
breakage. I disagree with this.


 One good way to make compiler/language stable is to ask "Why do people
 need it stable? What problems does it solve? How our guarantees help?".
 And most common answer for first question I have encountered so far :
 "Because people hate to spend time in the middle of project to fix
 unexpected issues from already working code base". Note that this has
 nothing to do with features, or ROI, or correctness, or whatever. It is
 all about expectation of a change. And despite all efforts, D falls
 miserably here. See current beta mailing list for several examples of
 what should have never happened in real stable development process.


This view would ignore all progress we've made in improving stability.


Andrei
May 23 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 23 May 2013 at 13:08:25 UTC, Andrei Alexandrescu 
wrote:

 It's an imperfect system, and we do our best with what we know, 
 whom we work with, and what we believe. We all have the same 
 goal. To be frank - relax. There's no reason to get overly 
 combative over this.


I am really glad to hear that you at least accept it is imperfect 
system. Beg my sincere pardon if my comments sound hostile, it is 
very hard to keep the right balance between being polite and 
actually breaking the comfort zone.

You don't answer the question though - why adopting widely used 
release processes to address this is not an option for D? Do you 
see any hidden issues there?


 Yes but we get back to the binary notion that you seem to 
 endorse: every breakage is as bad, and any breakage creates a 
 precedent for any other breakage. I disagree with this.


As I have already said, I have never said that "any breakage 
creates a

 precedent for any other breakage". It is more like "any 
 breakage marks release as breaking".



 This view would ignore all progress we've made in improving 
 stability.


Because for me personally there have been no improvements in 
_release_ stability. Overall compiler quality has increased 
tremendously, but process stays roughly the same. I am sorry to 
say this.
May 23 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/23/13 9:25 AM, Dicebot wrote:

 On Thursday, 23 May 2013 at 13:08:25 UTC, Andrei Alexandrescu wrote:

 It's an imperfect system, and we do our best with what we know, whom
 we work with, and what we believe. We all have the same goal. To be
 frank - relax. There's no reason to get overly combative over this.


 I am really glad to hear that you at least accept it is imperfect
 system. Beg my sincere pardon if my comments sound hostile, it is very
 hard to keep the right balance between being polite and actually
 breaking the comfort zone.

 You don't answer the question though - why adopting widely used release
 processes to address this is not an option for D? Do you see any hidden
 issues there?


The only issue I see is we need buy-in from all major contributors. They 
are working hard within a setup and accumulated a number of habits and 
ways of doing things. It's very easy to say what other people should do. 
It's quite a bit more difficult to effect such change.

Also, you seem to be 100% convinced that one particular release model 
must be used, but there wasn't as much consensus as you imply. The whole 
adoption thing must be predicated on the assumption that we are 
convinced we're choosing the right thing.


Andrei
May 23 2013
parent "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 23 May 2013 at 17:19:56 UTC, Andrei Alexandrescu 
wrote:

 The only issue I see is we need buy-in from all major 
 contributors. They are working hard within a setup and 
 accumulated a number of habits and ways of doing things. It's 
 very easy to say what other people should do. It's quite a bit 
 more difficult to effect such change.


Sure. But has this been even discussed among major contributors? 
:) (Also _all_ contributors should not really care, only those 
who do release and branch management).


 Also, you seem to be 100% convinced that one particular release 
 model must be used, but there wasn't as much consensus as you 
 imply. The whole adoption thing must be predicated on the 
 assumption that we are convinced we're choosing the right thing.


I have a terrible imagination and when example is needed tend to 
use solutions I like most personally :) However, in practice I 
would have been incredibly glad with _any_ solution which can be 
formally defined and eagerly adopted by D developers. And I am 
quite sure that if you will want to have one, you will create one 
much better than any single approach I can possibly propose.

In that sense I am extremely satisfied that you at least agree 
this is a problem and important opportunity for improvement. My 
goal is not to push some specific approach but to oppose possible 
conception that current approach is good enough to care not.

Thanks for your time!
May 24 2013
prev sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
On Wednesday, 22 May 2013 at 23:35:14 UTC, Jesse Phillips wrote:

 So while people claim they don't want breaking change, what 
 they really mean is "I only want breaking change when I decide 
 I to take it." And each person/situation will have different 
 desire on what they wish to have broken. What we want is to 
 select changes that people will want, make it easy to 
 make/expect the changes, and enough time they will make the 
 choice on their own.


That is exactly what I want! But if we keep saying "we are 
stable, trying to be stable, almost there" it won't change. It 
requires some formal process, not only simple desire to be 
stable. Current attitude just hides away real issues inventing 
local meaning for "stability".
May 23 2013
parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Thursday, 23 May 2013 at 08:50:11 UTC, Dicebot wrote:

 On Wednesday, 22 May 2013 at 23:35:14 UTC, Jesse Phillips wrote:

 So while people claim they don't want breaking change, what 
 they really mean is "I only want breaking change when I decide 
 I to take it." And each person/situation will have different 
 desire on what they wish to have broken. What we want is to 
 select changes that people will want, make it easy to 
 make/expect the changes, and enough time they will make the 
 choice on their own.


 That is exactly what I want! But if we keep saying "we are 
 stable, trying to be stable, almost there" it won't change. It 
 requires some formal process, not only simple desire to be 
 stable. Current attitude just hides away real issues inventing 
 local meaning for "stability".


I realize this, but you are arguing by using examples of those 
that don't ever want to change (they do exist, and they only 
change because they are forced to).

There shouldn't need to bring up the works/doesn't argument 
because that isn't what we are after. We want to provide some 
category of bug fixes or library additions for a defined period 
of time, while elsewhere we are making language improvements, 
which will eventual freeze and then later replace previous 
release.

Those who wish to never receive a non-breaking change are stuck 
with whatever version of the compiler they started building with. 
I'm not saying this to be mean, only because you can't change the 
compiler without the potential of having broken something 
somewhere (and now someone relying on that broken behavior).
May 23 2013
parent "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 23 May 2013 at 16:19:26 UTC, Jesse Phillips wrote:

 I realize this, but you are arguing by using examples of those 
 that don't ever want to change (they do exist, and they only 
 change because they are forced to).


I am using examples of real-world stability maniacs I have 
personally encountered :) Those guys (management) do want to 
change process though if it brings some potential profit. They 
will only do it in a fully controlled way though and once in a 
few years, thus all the hype about LTS.


 There shouldn't need to bring up the works/doesn't argument 
 because that isn't what we are after. We want to provide some 
 category of bug fixes or library additions for a defined period 
 of time, while elsewhere we are making language improvements, 
 which will eventual freeze and then later replace previous 
 release.


Well, I have been proposing something like this in one old thread 
I remember you posting to :)


 Those who wish to never receive a non-breaking change are stuck 
 with whatever version of the compiler they started building 
 with. I'm not saying this to be mean, only because you can't 
 change the compiler without the potential of having broken 
 something somewhere (and now someone relying on that broken 
 behavior).


That is not mean, that is reasonable. Only deal is about 
categorization - I argue that "backwards compatible or not" is a 
more useful one that "feature or bug-fix".
May 24 2013
prev sibling next sibling parent David Gileadi <gileadis NSPMgmail.com> writes:
On 5/21/13 9:05 AM, Walter Bright wrote:

 Also,

      dmd -man

 suffices for "long help".


Ah, man!!
May 21 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 21 May 2013 at 16:05:57 UTC, Walter Bright wrote:

 I generally agree with Andrei here. People hate it when their 
 makefiles break. There needs to be an awfully good reason to do 
 it, not just clean up.

 Also,

     dmd -man

 suffices for "long help". There is no reason to have 3 
 different help texts.


I generally agree, but -man isn't really where such information 
is looked for. DMD command line is especially confusing at time, 
but LDC's and GDC's are consistent, if that matter to the dev, 
solutions already exists.

Also, compiler interface isn't really language definition itself.
May 21 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2013 2:47 PM, deadalnix wrote:

 Also,

     dmd -man

 suffices for "long help". There is no reason to have 3 different help texts.


 I generally agree, but -man isn't really where such information is looked for.


That's because it's an innovative improvement. I find it handy myself.
May 21 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-21 17:29, Andrei Alexandrescu wrote:


 I think this DIP should be rejected. Even if implemented to perfection
 it would do nothing to make D better.

 Overhauling command line syntax would only help if the situation was
 unbearable or if people couldn't do what they wanted to do. As things go
 I find the situation marginally clunkier than it could be, but command
 line syntax can never be beautiful or perfect.


I think the git command line syntax is pretty good and consistent.

-- 
/Jacob Carlborg
May 21 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2013 10:04 AM, Jacob Carlborg wrote:

 I think the git command line syntax is pretty good and consistent.



If it is consistent, I have failed to figure out what the rule is. Each thing I 
want to do I have to write out on a crib sheet.
May 21 2013
next sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 21 May 2013 at 18:29:49 UTC, Walter Bright wrote:

 On 5/21/2013 10:04 AM, Jacob Carlborg wrote:

 I think the git command line syntax is pretty good and 
 consistent.



 If it is consistent, I have failed to figure out what the rule 
 is. Each thing I want to do I have to write out on a crib sheet.


Git exposes implementation details in high-level design and 
trying to use git without knowing those usually leads to lot of 
problems. Once you have learnt how stuff is organized, it is 
pretty consistent (but not perfect, of course).
May 21 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 21 May 2013 at 18:35:46 UTC, Dicebot wrote:

 On Tuesday, 21 May 2013 at 18:29:49 UTC, Walter Bright wrote:

 On 5/21/2013 10:04 AM, Jacob Carlborg wrote:

 I think the git command line syntax is pretty good and 
 consistent.



 If it is consistent, I have failed to figure out what the rule 
 is. Each thing I want to do I have to write out on a crib 
 sheet.


 Git exposes implementation details in high-level design and 
 trying to use git without knowing those usually leads to lot of 
 problems. Once you have learnt how stuff is organized, it is 
 pretty consistent (but not perfect, of course).


http://stevelosh.com/blog/2013/04/git-koans/
May 21 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 21 May 2013 at 21:56:23 UTC, deadalnix wrote:

 http://stevelosh.com/blog/2013/04/git-koans/


I was referring exactly to those :) They look weird but make some 
sense once you start noticing that stuff is grouped by what it 
does internally, not by user workflow cases. For example, "git 
checkout" always changes a working tree, it does not matter what 
was the reason to change it. And so on.
May 22 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 22 May 2013 at 08:16:58 UTC, Dicebot wrote:

 On Tuesday, 21 May 2013 at 21:56:23 UTC, deadalnix wrote:

 http://stevelosh.com/blog/2013/04/git-koans/


 I was referring exactly to those :) They look weird but make 
 some sense once you start noticing that stuff is grouped by 
 what it does internally, not by user workflow cases. For 
 example, "git checkout" always changes a working tree, it does 
 not matter what was the reason to change it. And so on.


That still don't explain most of the inconsistencies.
May 22 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-21 20:29, Walter Bright wrote:


 If it is consistent, I have failed to figure out what the rule is. Each
 thing I want to do I have to write out on a crib sheet.


Git:

* Flags with a single letter always start with a single dash
* Flags with multiple letters always start with two dashes
* If a flag contains multiple words they're concatenated with a dash
* I can run --help after each command to get help info
* Each flag has a full name and many have a single letter version as well

DMD:

* All flags start with a single dash, except for --help
* Flags that take arguments sometimes require a space, sometimes an 
equal sign and sometimes nothing
* Some flags are a complete word, some flags are a single letter, some 
flags are a couple of letters and so on

-- 
/Jacob Carlborg
May 21 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, May 21, 2013 20:49:16 Jacob Carlborg wrote:

 On 2013-05-21 20:29, Walter Bright wrote:

 If it is consistent, I have failed to figure out what the rule is. Each
 thing I want to do I have to write out on a crib sheet.


 
 Git:
 
 * Flags with a single letter always start with a single dash
 * Flags with multiple letters always start with two dashes
 * If a flag contains multiple words they're concatenated with a dash
 * I can run --help after each command to get help info
 * Each flag has a full name and many have a single letter version as well


This is how every command line tool should do it, and it's semi-standard, but 
unfortunately not all programs follow it (compilers in particular seem to do a 
bad job of it). On a related note, one of my pet peeves is the fact that 
std.getopt doesn't do bundling by default, as that's another thing that's 
semi-standard. Most *nix apps actually get this right (particularly if they're 
not ancient - the only ones seem more likely to have screwy rules about the 
order of flags and how many dashes you use and whatnot), but dmd doesn't follow 
the proper flag rules at all (probably because it's primary maintainer is 
primarily a Windows guy).

- Jonathan M Davis
May 22 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-05-22 20:14, Jonathan M Davis wrote:


 This is how every command line tool should do it, and it's semi-standard, but
 unfortunately not all programs follow it (compilers in particular seem to do a
 bad job of it). On a related note, one of my pet peeves is the fact that
 std.getopt doesn't do bundling by default, as that's another thing that's
 semi-standard. Most *nix apps actually get this right (particularly if they're
 not ancient - the only ones seem more likely to have screwy rules about the
 order of flags and how many dashes you use and whatnot), but dmd doesn't follow
 the proper flag rules at all (probably because it's primary maintainer is
 primarily a Windows guy).


Yeah, I don't know what's up with compilers. GCC, Clang and DMD all use 
a non-standard flag format. Although Clang follows GCC with many flags 
to be compatible.

-- 
/Jacob Carlborg
May 22 2013
prev sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Tuesday, 21 May 2013 at 15:29:49 UTC, Andrei Alexandrescu 
wrote:

 On 5/21/13 5:44 AM, Timothee Cour wrote:

 Abstract:
 This DIP seeks to improve dmd and rdmd's command line flags, 
 to make it
 more self-consistent and consistent with other tools 
 (including other D
 compilers), more expandable, avoid existing corner cases, and 
 better
 interact with other tools such as rdmd. It also proposes new 
 flags and
 proposes a simple deprecation path to follow.

 Link:
 http://wiki.dlang.org/DIP41


 I think this DIP should be rejected. Even if implemented to 
 perfection it would do nothing to make D better.

 Overhauling command line syntax would only help if the 
 situation was unbearable or if people couldn't do what they 
 wanted to do. As things go I find the situation marginally 
 clunkier than it could be, but command line syntax can never be 
 beautiful or perfect.


 Andrei


Andrei, there is a perfect, diplomatic solution to this - you 
make a survey of D community, and if the majority votes "YES" for 
a breaking change, then after that when someone complains, you 
just give that person a link to the survey result, with a comment 
"you asked for it!".
May 23 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/23/13 9:22 AM, Dejan Lekic wrote:

 Andrei, there is a perfect, diplomatic solution to this - you make a
 survey of D community, and if the majority votes "YES" for a breaking
 change, then after that when someone complains, you just give that
 person a link to the survey result, with a comment "you asked for it!".


Making a survey is difficult; only a small subset hangs out in this 
newsgroup. True, that subset is the most influential.

Andrei
May 23 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/23/2013 10:14 AM, Andrei Alexandrescu wrote:

 On 5/23/13 9:22 AM, Dejan Lekic wrote:

 Andrei, there is a perfect, diplomatic solution to this - you make a
 survey of D community, and if the majority votes "YES" for a breaking
 change, then after that when someone complains, you just give that
 person a link to the survey result, with a comment "you asked for it!".


 Making a survey is difficult; only a small subset hangs out in this newsgroup.
 True, that subset is the most influential.


I agree that there are many D users who do not hang out here, who sometimes 
surface and argue that they weren't informed about something. We have to 
consider their interests, too.
May 23 2013
parent "Zach the Mystic" <reachzach gggggmail.com> writes:
On Thursday, 23 May 2013 at 18:50:12 UTC, Walter Bright wrote:

 I agree that there are many D users who do not hang out here, 
 who sometimes surface and argue that they weren't informed 
 about something. We have to consider their interests, too.


Could a list of users be assembled who would be emailed directly 
when serious decisions require the input of the widest possible 
user base? Would that be a reliable way to maintain good 
communications? The idea would be to spare them the effort of 
keeping up to date on the busy newsgroups.

I feel bad about the stability versus innovation issue. I'm no 
expert in communications, but it would be great to discover that 
effective communications could solve problems that hacking 
wizardry alone could not. It might be too idealistic to imagine 
that the community will ever be one big happy family, rallying 
around important breaking changes for the sake great language 
design. But I don't think it's a Wild West, everyone for himself, 
kind of deal either. It even seems like the kind of issue where 
it's not so much about solid language design as it is about 
managing people's expectations and the process of change.

Until, that is, the day when D is so mainstream that it's being 
used by all sorts of rabble and vermin, who just can't take 
change the same way. But hasn't someone brought up the fact that 
PHP changed a value type to a reference type even in its very 
mature state? I don't know the details of that, but if it's true, 
then I think D seriously needs someone from PHP's public 
relations committee to jump that ship and board this one. :-)

And feel free to take my opinions with a grain of salt. I want D 
to succeed, but I wouldn't consider myself a serious trench 
soldier here, as you know.
May 24 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 23 May 2013 at 17:14:52 UTC, Andrei Alexandrescu 
wrote:

 On 5/23/13 9:22 AM, Dejan Lekic wrote:

 Andrei, there is a perfect, diplomatic solution to this - you 
 make a
 survey of D community, and if the majority votes "YES" for a 
 breaking
 change, then after that when someone complains, you just give 
 that
 person a link to the survey result, with a comment "you asked 
 for it!".


 Making a survey is difficult; only a small subset hangs out in 
 this newsgroup. True, that subset is the most influential.


Name related stuff are beneficial when you learn. Once you 
remember the new name, it is way less beneficial.

std.uni seems to have confused a lot of people when they learn. 
The thing is that people that already use std.uni will have their 
code broken and do not get something out of it.

Same goes for command line.

Change is difficult to lead when the one who pay for it isn't the 
one who benefit from it.

As a side note, I still go back to PHP doc for many function I 
use for years, because order of argument is completely random. 
Some part of phobos feel the same.
May 23 2013
prev sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Tuesday, 21 May 2013 at 09:45:19 UTC, Timothee Cour wrote:

 Abstract:
 This DIP seeks to improve dmd and rdmd's command line flags, to 
 make it
 more self-consistent and consistent with other tools (including 
 other D
 compilers), more expandable, avoid existing corner cases, and 
 better
 interact with other tools such as rdmd. It also proposes new 
 flags and
 proposes a simple deprecation path to follow.

 Link:
 http://wiki.dlang.org/DIP41


I think it would be good to implement the syntax used by other 
compilers. I don't see a need for deprecation, just remove 
documentation.

New flags shouldn't be part of this proposal.
May 21 2013