By David Stewart on September 16, 2015
"Whoa, lady, I only speak two languages: English and Bad English." - Korben Dallas, The Fifth Element
Unfortunately, my facility with spoken languages is about on the level of Korben Dallas. Spoken languages are studied by linguists, particularly when a language is in danger of going extinct. When a language has no longer has any living native speakers, it is referred to as a dead language. One way that language death can manifest itself is top-to-bottom, "when language change begins in a high-level environment such as the government." 
What about computer languages? Can there be top-to-bottom language death? Of course, I can think of many examples where computer languages were superseded by new versions and the old versions simply wasted away due to lack of use.
My current job is to lead our company's work on dynamic server languages, such as performance optimization and feature enabling. Besides PHP and HHVM, we want to improve Python. There is a huge amount of Python code in use out there, for example running OpenStack, Swift, DropBox and many others. What I didn't realize when I took the job was that much of this use is in a "dead" language.
I put that in quotes, because Python is far from being a dead language. But major server usages of Python is on a version (Python 2) which is supposed to be frozen. There are to be no new language features in Python 2, because the Python community would really like everyone to move to Python 3.
The problem is, moving to Python 3 requires you to port your code. When you have a stable, working system at the core of your business, you might plan to eventually move to Python 3, but unless there is a burning need, it might take a while.
This would make it impossible to speed up the core of the cloud until they port to Python 3!
“Because a thing seems difficult for you, do not think it impossible for anyone to accomplish.” – Marcus Aurelius
Something I have learned over the years that in open source, code speaks louder than words. Our engineers worked very hard to find ways to speed up Python 2.7 and came up with some excellent patches. One of which was an implementation of the computed goto optimization by Vamsi Parasa. This was both a port of computed gotos from Python 3 as well as improvements. (You can view the lengthy discussion thread here: https://mail.python.org/pipermail/python-dev/2015-May/thread.html#140219). I am really grateful for the really hard work of Vamsi and the other engineers to implement these code changes.
I'm also very grateful for the Python community, who wrestled with this idea of us contributing performance patches to Python 2.7 and eventually agreed that we should do it. Part of our agreement here is to optimize both Python 2 and Python 3; we providing analysis and optimization work to both versions, so that we don't slow down the eventual migration to Python 3, that everyone agrees is a good thing to do.
We are now submitting performance patches to both Python 2 and Python 3, and I'm confident we can help the community a lot in this.