I'd love to have a centralized page/wiki/site that would contain:

* D design flaws
* proposed improvements (including far ranging ones)

otherwise it gets lost in emails


On Fri, Nov 8, 2013 at 6:49 AM, Wyatt <wyatt.epp@gmail.com> wrote:

> On Friday, 8 November 2013 at 14:21:45 UTC, Dicebot wrote:
>
>> "Thread hijacking" achievement unlocked ;)
>>
>>  Now, now, I changed the title.  If this were a proper hijack, I'd be
> trying to extract a ransom (like fixed AAs). ;)
>
>
>  On topic of such wiki page - it is kind of nice to have but lot of
>> potential entries are controversial and need some serious discussion (for example, I'd place optional parens there as damaging mistake but reasonable people will disagree :P) before being documented. It risks being biased to preferences of view editors or turn into edit wards :) I don't know what is a good way to do this without devoting too much efforts.
>>
>
> I don't think it needs to be that strict.  Optional parentheses are something that there are mixed opinions on, so that should be noted.  It may be better to think of it as "things to reconsider in the next version"-- discuss later, once we have a lot more time with the current stuff and it's actually TIME to hash out the future.
>
> "Not gospel" means it's okay for things like that to be in there.  Heck, compare the vision for X12 with what Wayland [0] is actually shaping up to be: they're...rather different. ;)  (I'm aware that being "the next X11" wasn't Kristian's goal and it was originally an experiment to be folded into X.org, but reality is weird.)
>
> -Wyatt
>
> [0] http://wayland.freedesktop.org/architecture.html
>

On Thursday, 7 November 2013 at 20:16:46 UTC, Jonathan M Davis wrote:
>
> With regards to the cost/benefit ratio, such a change fails miserably. This is
> exactly the sort of change that Walter and Andrei were talking about stopping
> completely at dconf, precisely because it doesn't actually fix anything.
> Breaking changes need to provide real, tangible benefits which are greater than
> the cost that they incur. And while I tend to agree that it would be better
> had none of the built-in attributes used @, changing it won't fix any bugs and
> won't make any software easier to mantain save perhaps for a tool which
> lexes/parses the language, and handling the few built-in attributes with @ is
> trivial in that case. The benefits are aesthetic, and changing it requires
> changing pretty much all existing D code. And even if you can avoid having the
> change break code immediately, it still requires changing the code, so it's
> not like that eliminates the cost of the change. It just spreads it out.
>
> If you want anything like this to happen, you'll have to convince Walter and
> Andrei, and I would be shocked if they were ever convinced. They want to focus
> on stability, not on tweaking everything in search of making the language
> perfect. Breaking changes - especially breaking changes on this scale - need
> to provide real, tangible benefits which outweigh the cost of the breakage. And
> changing the @ attributes doesn't even come close.
>
> - Jonathan M Davis

I would add that constant breaking changes make the language unfit for industrial usage in the long term.
Let's remember that D is being pushed in production by Andrei at Facebook. If the language breaks everything at each release, there is no way Facebook or any other company for that matter is going to bet a dime on it.

On Friday, 8 November 2013 at 14:21:45 UTC, Dicebot wrote:
> "Thread hijacking" achievement unlocked ;)
>
> On topic of such wiki page - it is kind of nice to have but lot of potential entries are controversial and need some serious discussion (for example, I'd place optional parens there as damaging mistake but reasonable people will disagree :P) before being documented. It risks being biased to preferences of view editors or turn into edit wards :) I don't know what is a good way to do this without devoting too much efforts.

You could allow comments at the bottom of the page, or like wikipedia, add a comments page to the DIP ?

On Thursday, 7 November 2013 at 07:50:35 UTC, Daniel Kozak wrote:
> On Thursday, 7 November 2013 at 07:29:16 UTC, Jacob Carlborg wrote:
>> On 2013-11-07 07:48, Rob T wrote:
>> I agree with you. Unfortunately the those with commit access do not agree. They have no interest, what so ever, in breaking backward compatibility due to consistency.
>>
>> The result is exactly what happened with D1. At some arbitrary point in time it was decided that backwards compatibility must be kept, almost at all cost. This was decided even though the language and the standard library was far from stable.
>
> If this is true, than D lost a chance to became more popular, unfortunately :'(

In the contrary, ensuring stability gives it a chance to be accepted/supported by major industrial players (like Facebook for instance), which would help boost the language's development and ecosystem.

On Saturday, 9 November 2013 at 00:12:22 UTC, Timothee Cour wrote:
> I'd love to have a centralized page/wiki/site that would contain:
>
> * D design flaws
> * proposed improvements (including far ranging ones)
>
> otherwise it gets lost in emails

Just need a single person to start the wiki page and define default entry formatting ;)

On 11/9/13 1:27 AM, SomeDude wrote:
> I would add that constant breaking changes make the language unfit for
> industrial usage in the long term.
> Let's remember that D is being pushed in production by Andrei at
> Facebook. If the language breaks everything at each release, there is no
> way Facebook or any other company for that matter is going to bet a dime
> on it.

Agreed with qualifications. We at Facebook are well aware that bumping the gcc release will inevitably cause breakages, and are able and willing to put up with them for the sake of the benefits. This of course is guided by the breakage/benefits ratio.

Andrei

After all, we have a language philosophy and we can have a some planning with breaking changes.
Facebook, no doubt, it is good. But "stability" in such way will cause that the D will became another C++'s reincarnation in case without consistency.

As example of "oh, sh*t it's changed", please, remember add/removing in github repo a new syntax of "alias this" in new way like alias aliasName = symbol.

@/@safe/@UDA -> causes dissonance over 9000% !!!


Sorry for this Inglesh.

On 11/10/2013 05:39 PM, Andrei Alexandrescu wrote:
> On 11/9/13 1:27 AM, SomeDude wrote:
>> I would add that constant breaking changes make the language unfit for
>> industrial usage in the long term.
>> Let's remember that D is being pushed in production by Andrei at
>> Facebook. If the language breaks everything at each release, there is no
>> way Facebook or any other company for that matter is going to bet a dime
>> on it.
>
> Agreed with qualifications. We at Facebook are well aware that bumping
> the gcc release will inevitably cause breakages, and are able and
> willing to put up with them for the sake of the benefits. This of course
> is guided by the breakage/benefits ratio.
>
> Andrei
>

What about just shipping a fully automated fix-up tool when trivial but major breaking changes happen?

On 11/10/13 11:14 AM, Timon Gehr wrote:
> On 11/10/2013 05:39 PM, Andrei Alexandrescu wrote:
>> On 11/9/13 1:27 AM, SomeDude wrote:
>>> I would add that constant breaking changes make the language unfit for
>>> industrial usage in the long term.
>>> Let's remember that D is being pushed in production by Andrei at
>>> Facebook. If the language breaks everything at each release, there is no
>>> way Facebook or any other company for that matter is going to bet a dime
>>> on it.
>>
>> Agreed with qualifications. We at Facebook are well aware that bumping
>> the gcc release will inevitably cause breakages, and are able and
>> willing to put up with them for the sake of the benefits. This of course
>> is guided by the breakage/benefits ratio.
>>
>> Andrei
>>
>
> What about just shipping a fully automated fix-up tool when trivial but
> major breaking changes happen?

That's nice because in a good way it puts the onus on the breakers. For it to be useful, the tool would have to be rock solid and work in 100% cases.

Andrei

> What about just shipping a fully automated fix-up tool when trivial but major breaking changes happen?

search/replace regexp ?)