new DIP41: dmd/rdmd command line overhaul.

[Dmitry S]

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130522/3d908285/attachment-0001.html>