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