Well said, Joseph. Unfortunately, many companies are run these days with a view toward the IMMEDIATE bottom line. I mean numbers like revenues or expenses are seen short-term. If a project stops development on new things and spends time redoing old things, there are expenses recorded with no revenues. Another organization might go ahead and get up to date and a few years down the road their projects are sailing along while the first employer keeps running into obstacles and is not able to get new developments and so on. But often, the manager making the decision will have taken their bonus or promotion and perhaps moved on or retired.
Not to be political, I note many government entities, especially including the state I live in, have gigantic pension obligations they have no easy way to meet. Over the years in negotiations with unions they have often traded rich promises for the future instead of immediate pay hikes. The costs may largely be invisible and did not impact their current budgets so they could waste money on other things such as giveaways that help them get re-elected to ever higher office. But the costs are getting very visible now, and especially when the stocks they invest in decline. Back in the computer world, Y2K gave such managers some cover. There was a FIRM deadline. I wonder how many used the impending arrival of the year 2000 as an excuse to perhaps clean up other parts of their act and charge it to prevention. I mean they might suggest they rewrite some legacy COBOL or even machine language programs into something more modern or other improvements like getting a new database including new hardware. I also wonder if jobs for some programmers declined sharply in the years after when not only were they not desperately needed, but perhaps not needed at all unless they developed new talents. Just FYI, the name Y2K always struck me as similar nonsense. They abbreviated Year and 2000 from at least 8 characters to 3 and did it wrong as 2K is 2048. As far as I know, nothing special will happen in 2048 and I also have no special vision for 2020. -----Original Message----- From: Python-list <python-list-bounces+avigross=verizon....@python.org> On Behalf Of Schachner, Joseph Sent: Thursday, January 17, 2019 1:46 PM To: Python <python-list@python.org> Subject: RE: Pythonic Y2K I'd like to add one more thing to your list of what companies will have to consider: 6) The ability to hire and retain employees who will be happy to program in an obsolete version of Python. A version about which new books will probably not be written. A version which new packages will not support. A version which most other companies will no longer be using, so programming only in Python 2 will place the employee at a disadvantage compared to others who have gained experience with Python 3 if they ever have to change employers. --- Joseph S. -----Original Message----- From: Chris Angelico <ros...@gmail.com> Sent: Wednesday, January 16, 2019 2:15 PM To: Python <python-list@python.org> Subject: Re: Pythonic Y2K On Thu, Jan 17, 2019 at 6:04 AM Avi Gross <avigr...@verizon.net> wrote: > > I see messages like the following where someone is still asking how to > do something in some version of python 2.X. > > I recall the days before the year 2000 with the Y2K scare when people > worried that legacy software might stop working or do horrible things > once the clock turned. It may even have been scary enough for some > companies to rewrite key applications and even switch from languages like COBOL. > > What is happening in the python community, and especially in places > where broken software may be a serious problem? > > I assume versions of python 2.X will continue to be available for some > time but without any further support and without features being back-ported. Commercial support for Python 2 will probably continue for a while, in the same way that support for versions older than 2.7 is still available to Red Hat customers today (if I'm not mistaken). Otherwise, well, the software will continue without updates or security patches until it breaks. Companies will have to weigh up five costs against each other: 1) The cost of the status quo: the risk of critical failures or external attacks against unsupported and unpatched software 2) The cost of migrating to Python 3 3) The cost of migrating to a completely different language 4) The cost of maintaining their own local fork of Python 2 5) The cost of using a supported commercial platform such as RHEL. For most small to medium projects, it's probably going to come down to #1 or #2, where #1 has the laziness bonus. For many larger companies, #1 is an unpayable cost. Everyone has to make that choice, and remember that "cost" doesn't just mean money (for instance, the cost of moving to Linux might be quite considerable for a Windows shop, and even within a Linux ecosystem, switching to Red Hat may have consequences to other programs you might need). ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
