December 14, 2012
On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:
> Like any major user of a language, they want confidence in our full support of them. Asking them to use a patched or branch version of the compiler does not inspire confidence.
>

But nobody agreed here on supporting that ! It never was released !

> What I'm doing is hardly unique in business history. When Boeing designed the 707, they showed the prototype to Pan Am, their biggest potential customer. Pan Am wanted a slightly wider fuselage. At enormous expense, Boeing threw out their tooling and built all new tooling and a new design, all just to make the sale to Pan Am. It paid off enormously for Boeing, because with Pan Am buying 707s, the other airlines all couldn't wait to buy them, too.
>

I'm pretty sure Boeing employee were informed and payed for that work. Here you have a community that is not informed and work on D on their free time.

> When Westinghouse had AC and Edison had DC, they competed for the Niagra power project. Both knew that would be the lynchpin of their industry, and both did whatever it took to get that design win. Westinghouse got the contract, and that's why our electrical grid is 60 Hz AC.
>

Considering the physics constraints, DC isn't even an option. Having the contract at the time would have simply delayed electricity deployment like we know now.

> Ok, we're not Boeing or Westinghouse. But we have an opportunity to go big time, and I'm not going to let that get away from us.

You'll go nowhere without a community.
December 14, 2012
On Friday, December 14, 2012 01:17:08 David Nadlinger wrote:
> For 1., I would guess at most something like half an hour for a large codebase where the feature is used pervasively (you just keep editing/compiling until there are no more syntax errors), which is why I can't quite understand the fuzz you are making about keeping the feature. And even if they cannot switch right now, as the Remedy guys are obviously willing to use experimental compiler versions, can't they just use a patched version until they have made the switch?

I would think that they could just use the version that they're using now until they've had time to make the change (which I wouldn't think would take all that long, though it wouldn't surprise me if it took them a few hours rather than half an hour if their code base is large). I can only see that being an issue if they absolutely must have some other fix that's been checked in since that change.

Regardless, I think that this needs to be fixed before the actual release.

- Jonathan M Davis
December 14, 2012
On Fri, Dec 14, 2012 at 01:05:21AM +0100, deadalnix wrote:
> On Thursday, 13 December 2012 at 23:47:56 UTC, Walter Bright wrote:
> >It's Remedy Games. It's a big deal for them, and their use of D is a big deal for us, big enough that we can bend our procedure for them. They were also under severe time pressure. They began using UDAs the same day I implemented them. Remedy could very well be the tipping point for D, and I'm not going to allow them to fail.
> >
> >It's also not a conflict of interest - what they want from D is really what we all want from it.
> >
> >I understand that some of you may be frustrated by my giving their needs priority, but I hope that the end result will be better for all of us than if I didn't, and that you'll indulge me with this.
> 
> You have to understand that this isn't their need that is important here. They need stuff that we mostly all need, so I tend to agree. The fact is that you unilaterally decide to give that priority, when we are not even aware of them or of their needs. And that is the problem.
> 
> I understand that this game is a big deal for D and I'm all for supporting that effort. But, it can't be done against the community, or you'll alienate everybody here.
> 
> We all here are trying to support D in different ways, but if we are not aware of the goals, it simply will not work. You will ends up with a fork continuing that way, and I think phobos vs Tango for D1 was already enough.
> 
> Isn't it preferable to help them to migrate to the new syntax rather than bringing everybody in the same boat ? The feature hasn't been released, so I'm pretty sure most D actor don't have a lot of them in their codebase, which make the support into the transition easy.
> 
> Introducing new deprecated feature into a release seems completely backward to me, and reading other comment, it seems that I'm not the only one. We should consider other solutions before sticking to that one. And you have to work with D community on that one, or you'll loose it.

This just underscores our desperate need to start implementing a sane release process, as proposed by the ongoing discussion in the PROCESS thread.

And now is about the most critical time for us to start doing this. We're on the verge of possibly hitting it big, and so big changes in the community are likely to be on the horizon. To deal with the influx of users that will very likely flood in when the news about Remedy adopting D goes out, we better get our act together NOW and start using a sane release process.  Otherwise, D's potentially big break in terms of adoption may turn out to break D, possibly fatally.

The current proposal is being drafted up on the wiki:

	http://wiki.dlang.org/Release_Process

It would be very helpful if the core developers (esp. Andrei, who is apparently supposed to head this up) gave some input as to whether the proposal is workable, and/or what needs to be fixed or changed in order for make it workable.

I don't think it's an overstatement to say that we desperately need to get this worked out, the sooner the better. It had better be implemented by the time the influx of users comes, otherwise D may never get rid of the bad reputation of releases being badly managed (no matter what the actual situation is).


T

-- 
The best way to destroy a cause is to defend it poorly.
December 14, 2012
On 12/13/2012 5:10 PM, H. S. Teoh wrote:
> Remedy adopting D

Saying that would be premature and incorrect at the moment. We still have to ensure that Remedy wins with D. This is an ongoing thing.

December 14, 2012
Yet not released feature is not visible for almost D users.
What you are going to do in 2.061 is to add a warned feature suddenly.

But, it is certainly no problem for almost D users (unless users use old
@[] syntax, compiler never warn). I think what you must to do is to cut the
time limit of removing @[] syntax. X months after?  In version 2.0yy?
You should say much better answer than *in the future*.

Kenji Hara

2012/12/14 Walter Bright <newshound2@digitalmars.com>

> On 12/13/2012 4:17 PM, David Nadlinger wrote:
>
>> 1. How much work would it be for the guys at Remedy Games to convert their
>> codebase from [] to @()?
>>
>
> I don't know. All I know is it's a lot of code.
>
>
>
>  2. What is your plan moving forward, i.e. how to you intend to handle
>> deprecation/removal of the feature?
>>
>
> Warning, then deprecation, then removal. The usual.
>
>
>
>  3. Why is the message you introduced a warning instead of a normal
>> deprecation
>> error?
>>
>
> Because skipping the warning phase has historically been too abrupt for people.
>
>
>
>  For 1., I would guess at most something like half an hour for a large
>> codebase
>> where the feature is used pervasively (you just keep editing/compiling
>> until
>> there are no more syntax errors), which is why I can't quite understand
>> the fuzz
>> you are making about keeping the feature. And even if they cannot switch
>> right
>> now, as the Remedy guys are obviously willing to use experimental compiler
>> versions, can't they just use a patched version until they have made the
>> switch?
>>
>
> Like any major user of a language, they want confidence in our full support of them. Asking them to use a patched or branch version of the compiler does not inspire confidence.
>
>
>
>  Let me also repeat the most important point: If we release 2.061 like
>> this, DMD
>> will silently accept the old syntax, so your decision will actually lead
>> to
>> *more* breakage when the feature is removed in the future.
>>
>
> The [ ] syntax was never documented and won't be, so I doubt there'll be any new use of it, nor does it interfere with anything else.
>
>
> What I'm doing is hardly unique in business history. When Boeing designed the 707, they showed the prototype to Pan Am, their biggest potential customer. Pan Am wanted a slightly wider fuselage. At enormous expense, Boeing threw out their tooling and built all new tooling and a new design, all just to make the sale to Pan Am. It paid off enormously for Boeing, because with Pan Am buying 707s, the other airlines all couldn't wait to buy them, too.
>
> When Westinghouse had AC and Edison had DC, they competed for the Niagra power project. Both knew that would be the lynchpin of their industry, and both did whatever it took to get that design win. Westinghouse got the contract, and that's why our electrical grid is 60 Hz AC.
>
> Ok, we're not Boeing or Westinghouse. But we have an opportunity to go big time, and I'm not going to let that get away from us.
>


December 14, 2012
On 12/13/2012 4:55 PM, deadalnix wrote:
> You'll go nowhere without a community.

And we need major users, too.

It's a balancing act. And I wish to point out, again, that the design was based on extensive discussion threads right here in the ng, and the design was modified based on feedback right here in the ng. So to say the community was uninvolved in this is incorrect, it is very much a community design.

And, if you recall, I was initially opposed to UDAs and skeptical they'd be of any actual use :-)
December 14, 2012
On 12/13/2012 5:33 PM, kenji hara wrote:
> Yet not released feature is not visible for almost D users.
> What you are going to do in 2.061 is to add a warned feature suddenly.
>
> But, it is certainly no problem for almost D users (unless users use old @[]
> syntax, compiler never warn). I think what you must to do is to cut the time
> limit of removing @[] syntax. X months after?  In version 2.0yy?
> You should say much better answer than *in the future*.

I think in the past we've been too hasty sometimes in removing things. I think a better approach will be to allow some time to elapse, and then ask in the ng if there will be any problems with moving to the next stage.

December 14, 2012
I think we should have -future/-f switch and @future attribute. It is a rough idea, but seems a required compiler feature.

Kenji Hara

2012/12/14 Walter Bright <newshound2@digitalmars.com>

> On 12/13/2012 5:33 PM, kenji hara wrote:
>
>> Yet not released feature is not visible for almost D users.
>> What you are going to do in 2.061 is to add a warned feature suddenly.
>>
>> But, it is certainly no problem for almost D users (unless users use old
>> @[]
>> syntax, compiler never warn). I think what you must to do is to cut the
>> time
>> limit of removing @[] syntax. X months after?  In version 2.0yy?
>> You should say much better answer than *in the future*.
>>
>
> I think in the past we've been too hasty sometimes in removing things. I think a better approach will be to allow some time to elapse, and then ask in the ng if there will be any problems with moving to the next stage.
>
>


December 14, 2012
On 12/13/12 8:55 PM, kenji hara wrote:
> I think we should have -future/-f switch and @future attribute.
> It is a rough idea, but seems a required compiler feature.
>
> Kenji Hara

That sounds interesting.

Regarding attributes, a simple solution is to release it but without official documentation. We place the documentation in a /unstable/ directory of the website, distinct from the central mainstream documentation.

People who already started or want to start using attributes understand there are instabilities associated with them. Existing code is unaffected, only certain programs that are technically invalid will actually compile and run.

Works?


Andrei
December 14, 2012
On Thursday, 13 December 2012 at 23:41:32 UTC, RenatoUtsch wrote:
> Please, lets not release something not thoroughly tested when we are in the middle of the new development process discussion, we are trying to avoid exactly this kind of thing.

The process must be defined before we can use it and UDA has already missed that boat. I'm in agreement with the way Andrei has said it, we need to let this slide.

> Even if the feature is not introducing backwards incompatible changes, this will cause problems when we discover, in the future, that we made some bad decision and won't be able to change it anymore.

Hopefully we are defining the process that we can handle these changes. We'll never have enough testing to not make this mistake.

So let us go make this process for Walter to follow and neg him later. (You don't throw people in jail when what they did was criminalized a year later)