[Jumziey]

Brilliant. It's a really good compliment to strangling certain parts of a large code base.

As always the key is getting the information to the right people at the right time, and making it more difficult to make the wrong choices then the right choices.

[harryf]

Exactly. What's nice about this approach is it factors in the "behavioural economics" of developers. As the author puts it...

> At the end of the day, everyone needs to get work done, and if they see a code-path already being used from 10 places in the code-base despite these soft warnings–it doesn’t seem crazy to introduce another.

Even the best person with the best intentions will take a short cut under some circumstances, meaning to fix it later then getting distracted before that happens.

[notabul]

The idea of deprecation and death of code assumes that those using it can easily stop.

That’s not always the case.

When Flash dies Jan 12, 2021, you’ll see what I mean.

There’s been so much misinformation about it, but there’s an OS datetime check in the Flash viewer code, browsers will disable the plugin even for some older versions not just new releases and have or will remove PPAPI and NPAPI support, and Windows already has an optional update to kill Flash support that will be part of regular updates in Summer 2021.

Even with three years of warning, it’s not ok.

It’s an extreme case of deprecation, being attempted by the best in the business, but it is inherently bad, and there’s hardly a good way of doing it.

[JBorrow]

I don't understand what this has to do with the article or the previous comment at all.

[notabul]

The article is about deprecating and taking functionality out of use.

My point is that deprecation is by its very nature going to hurt something that isn’t prepared for its demise.

There is no good way to do it. There are only less bad ways to do it.

[V-2]

Flash is an example of an entire technology getting deprecated. The article only talks about the codebase level.

[adewinter]

At this point if you/your company is still using Flash I find it hard to sympathize with you. How did the company come to the conclusion that using Flash was a good business decision? It's been largely unsupported/disabled in mainstream browsers for _years_ now. They also knew for 3 years it was officially going to be deprecated in 2021. Sounds like despite that they continued to develop on the technology anyway?

[notabul]

Some businesses run on code more than ten years old.

They don’t care if you sympathize. The business or institution decides how it wants to prioritize replacement, and some projects miss deadlines.

If you think that every application running in an enterprise has stopped using Flash, you’re sorely mistaken.

[adewinter]

Sure. Can't have it both ways though: you're welcome to choose to implement on a soon to be deprecated tech stack but you don't get to bitch about it or expect the maintainers of said stack to suddenly change their minds about deprecating.

[generalk]

  > My point is that deprecation is by its very nature going 
  > to hurt something that isn’t prepared for its demise.

TFA describes techniques for deprecating code paths that do their best to notify and prepare the folks working with that code.

You're describing the end of Life of Adobe Flash that hits at the end of 2020.

Deprecation is different from EOL (Flash has been deprecated for some time now), and deprecating/EOLing a creation tool/product line has little similarity with tooling to deprecate internal APIs gracefully.

Although I do think that you and TFA agree on how difficult it is to deprecate functionality that folks rely on, it seems like you're talking about two wildly different facets of that statement.