Thread overview | ||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
August 16, 2020 [OT] Dear Google Cloud: Your Deprecation Policy is Killing You | ||||
---|---|---|---|---|
| ||||
Ran across this via reddit yesterday and thought people here might find it interesting. https://medium.com/@steve.yegge/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc |
August 16, 2020 Re: [OT] Dear Google Cloud: Your Deprecation Policy is Killing You | ||||
---|---|---|---|---|
| ||||
Posted in reply to jmh530 | On Sunday, 16 August 2020 at 22:03:07 UTC, jmh530 wrote:
> Ran across this via reddit yesterday and thought people here might find it interesting.
>
> https://medium.com/@steve.yegge/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc
I enjoyed it.
We should learn from this.
|
August 16, 2020 Re: [OT] Dear Google Cloud: Your Deprecation Policy is Killing You | ||||
---|---|---|---|---|
| ||||
Posted in reply to jmh530 | On 8/16/20 6:03 PM, jmh530 wrote:
> Ran across this via reddit yesterday and thought people here might find it interesting.
>
> https://medium.com/@steve.yegge/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc
>
That is a fabulous article, thanks!
-Steve
|
August 16, 2020 Re: [OT] Dear Google Cloud: Your Deprecation Policy is Killing You | ||||
---|---|---|---|---|
| ||||
Posted in reply to jmh530 | On 8/16/2020 3:03 PM, jmh530 wrote:
> Ran across this via reddit yesterday and thought people here might find it interesting.
>
> https://medium.com/@steve.yegge/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc
>
Thanks! Steve, as always, writes great articles.
|
August 16, 2020 Re: [OT] Dear Google Cloud: Your Deprecation Policy is Killing You | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | On Sun, Aug 16, 2020 at 11:27:47PM +0000, Stefan Koch via Digitalmars-d wrote: > On Sunday, 16 August 2020 at 22:03:07 UTC, jmh530 wrote: > > Ran across this via reddit yesterday and thought people here might find it interesting. > > > > https://medium.com/@steve.yegge/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc > > > I enjoyed it. > We should learn from this. I feel like we're not even in that ballpark yet. First things first, we need to stop releasing with new regressions... second, we need to stop releasing with *any* regressions. Third, now we can start talking about deprecation policy. T -- Public parking: euphemism for paid parking. -- Flora |
August 17, 2020 Re: [OT] Dear Google Cloud: Your Deprecation Policy is Killing You | ||||
---|---|---|---|---|
| ||||
Posted in reply to jmh530 | On 2020-08-17 00:03, jmh530 wrote: > Ran across this via reddit yesterday and thought people here might find it interesting. > > https://medium.com/@steve.yegge/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc If you never can remove anything, you have to live with the old baggage forever. The means documentation, books, specs and other material that wants to be complete need to still include the deprecated things. There are also some language issue that can never be fixed, like implicitly convert integer and character literals to bool (I guess they could be fixed by introducing new types). With a library code it's much easier, just point users to a new function. This is basically what happens to C++. Adding new things, never remove the old. The old will always be around. I'm sure there still new code being written that uses old style C++. The biggest advantage and disadvantage with C++ is the C source level compatibility. Perhaps something like editions in Rust. For D, that would be something like supporting D2 and adding new non-breaking things to it. At the same time developing D3 which gets the new non-breaking things and possibly breaking changes as well. Both editions working side by side in the same application. But it's the same problem as always, we don't have the manpower. -- /Jacob Carlborg |
August 17, 2020 Re: [OT] Dear Google Cloud: Your Deprecation Policy is Killing You | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Mon, Aug 17, 2020 at 01:16:00PM +0200, Jacob Carlborg via Digitalmars-d wrote: [...] > If you never can remove anything, you have to live with the old baggage forever. The means documentation, books, specs and other material that wants to be complete need to still include the deprecated things. [...] Not necessarily. You can remove it from documentation, but leave the implementation intact, so that newer code will stop using it but older code will not break. But yeah, backwards compatibility does come at a cost. T -- Why have vacation when you can work?? -- EC |
August 17, 2020 Re: [OT] Dear Google Cloud: Your Deprecation Policy is Killing You | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Monday, 17 August 2020 at 11:16:00 UTC, Jacob Carlborg wrote:
> This is basically what happens to C++. Adding new things, never remove the old. The old will always be around. I'm sure there still new code being written that uses old style C++. The biggest advantage and disadvantage with C++ is the C source level compatibility.
>
> Perhaps something like editions in Rust. For D, that would be something like supporting D2 and adding new non-breaking things to it. At the same time developing D3 which gets the new non-breaking things and possibly breaking changes as well. Both editions working side by side in the same application. But it's the same problem as always, we don't have the manpower.
Personally I much prefer the current approach where we can sort of take deprecations on a nice smooth gradient. With a hard D2/D3 cut it would be difficult to know when to make the jump, and old code that wasn't worth switching to D3 would eventually fall off the update bandwagon. I think the current approach of "opt in flag new feature, deprecate old feature, fallback flag old feature, old feature removed" is a good one.
I'm in favor of killing old code. Google and MS can afford to carry deprecations because they can literally throw hundreds of people at it. (And make no mistake - it costs them.) D should focus on being the best language it can be in each moment. I think our reaction to this should much rather take the form of cautiously weighing new features against their maintenance cost than worrying about whether or not D should deprecate old ones. Worstcase, you get old features that linger and look usable despite nobody being willing to maintain them or being actively discouraged from maintaining them, cough std.json cough.
|
August 17, 2020 Re: [OT] Dear Google Cloud: Your Deprecation Policy is Killing You | ||||
---|---|---|---|---|
| ||||
Posted in reply to FeepingCreature | On Mon, Aug 17, 2020 at 02:17:58PM +0000, FeepingCreature via Digitalmars-d wrote: [...] > I'm in favor of killing old code. Google and MS can afford to carry deprecations because they can literally throw hundreds of people at it. (And make no mistake - it costs them.) D should focus on being the best language it can be in each moment. I think our reaction to this should much rather take the form of cautiously weighing new features against their maintenance cost than worrying about whether or not D should deprecate old ones. Worstcase, you get old features that linger and look usable despite nobody being willing to maintain them or being actively discouraged from maintaining them, cough std.json cough. I think we should pay attention to the distinction Steve draws between deprecation in the sense of discouraged but still working, vs. deprecation in the sense of it won't compile until you fix your code. One way to discourage the use of certain deprecated features but still allow old code to work, is to deprecate them, then undocument them, but never remove them. So the old code still compiles and works as before, but the old features are no longer documented and so new code will no longer use them. Of course, as you said, maintaining forever backward compatibility does come with a cost, a potentially very heavy one. You have to keep the old code around basically forever, *and* maintain it in the face of new changes. And the existence of this old code may forever prevent certain things from ever being fixed, because the fix would break the old code in a fundamental way. In some cases you might be able to re-implement the old code in terms of the new, but that isn't always possible and it's a big resource sink. Probably bigger than we have the manpower for. T -- Life is complex. It consists of real and imaginary parts. -- YHL |
August 17, 2020 Re: [OT] Dear Google Cloud: Your Deprecation Policy is Killing You | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On Monday, 17 August 2020 at 14:38:54 UTC, H. S. Teoh wrote: > > I think we should pay attention to the distinction Steve draws between deprecation in the sense of discouraged but still working, vs. deprecation in the sense of it won't compile until you fix your code. One way to discourage the use of certain deprecated features but still allow old code to work, is to deprecate them, then undocument them, but never remove them. So the old code still compiles and works as before, but the old features are no longer documented and so new code will no longer use them. Another key difference is that you can opt-out of the deprecation, pretty easily. Just don't update your compiler. Or your dependencies. We don't remove old versions from the website, so if your code compiled with v2.052.0, then it will still compile with it today... Unless you're using Mac, in which case you will be force to upgrade to a recent version, because Apple. Another example that I really like is Github. You guys remember we renamed the organization name on Github years ago ? Well the redirect still works (http://github.com/D-Programming-Language/dmd). |
Copyright © 1999-2021 by the D Language Foundation