> I write a lot of Python code and don’t really run into Python 2 vs 3 issues anymore.
I think you are missing the key point here: I don't write a ton of Python. I don't write any Python. Of course you think this is old news. You write a lot of Python. You're totally plugged in. You've known this is coming, this inside baseball is "the thing" for you. My point is that, believe it or not, the rest of the world does not keep up to date with whatever the Python community is doing. This is not unique to Python. Most people in dev community X are not aware of what is happening in dev community Y. What is unique to Python is that all of a sudden we were forced to become aware as the downstream apps began to break. By creating a backwards compatibility issue in an interpreted language, you necessarily "backload" the end-user pain to when the apps, which by definition are updated later than the code within the apps, begin to break as packages are removed from package managers, or things are EOL'ed, etc. This is a situation that I can honestly not remember happening with any other language. I can't remember any other circumstance, and certainly not one where it proceeded to happen repeatedly, where I've been abruptly made aware that utilityX was written in a no-longer-supported version of C/perl/whatever (when I previously didn't even know what language it was), after I had been running it for ages.
What shelf? A garage? Detached? A shed? How humid? You may want to resurface and oil that saw after a decade. The wood handle may have rotted, or the plastic one may be gummy. Taking care of tools is how they last.
That's cool, but if the 100 year old saw had been used regularly it would have required maintenance and sharpening to continue working well. Software also requires maintenance.
I can't think of any 100-year old software that is being used today (ha-ha).
I'm sure some airline reservation systems and banking systems written in COBOL in the 70s are still around, but they all have ongoing maintenance to keep them working correctly.
The commenter's complaint seems particularly worse with dynamic languages like JavaScript and Python than compiled things. Old projects written in node are often just as hard to get running or installed as something written in Python 2. The dependencies are out of date, you have to install an older version of Node.js, or the dependencies just don't exist anymore. And JS stuff usually generates a huge tree of dependencies even if they only directly rely on a handful of packages.
End of story, I think if these Python-2 tools/scripts were such a huge part of his project that they keep breaking builds, the company should be invest time in either rewriting them in their language of choice or maintaining those projects or a fork of those projects.
One of my old bosses was strict about this - no COMPANY projects should be relying on external package repositories, unapproved third-party dependencies, definitely not some github project maintained by only a few people. Yeah, I think if your company is relying on "requests" or some other massively popular project with tons of community maintenance, you don't want to fork that and it's important to use the standard versions. But if you're bringing in something that is used and maintained by only a few people - you either need to become part of the community that maintains it publicly or fork the project and maintain your own version.
This isn't NIH syndrome, it's basic protocol for keeping your builds reliable and dependency management simple.
>This isn't NIH syndrome, it's basic protocol for keeping your builds reliable and dependency management simple.
Why should I, an end user, ever need to build WikidPad? I don't need to do so on Windows, why doesn't Linux support the same thing, shipping an executable?
When you go to the store, you're not presented with a set of tools for making a saw, you're given a complete, ready to go tool. Perhaps the very idea of users having to build things in Linux is the problem?
It is very similar to the problems with Windows, always pushing updates/upgrades that aren't necessary, and often break things. Windows machines are far less reliable on Wednesday than they are on Monday, because of Microsoft's idea of pushing patches on Tuesdays.
It's as if JavaScript had shipped a non-compatible update, browsers had on a magic day stopped supporting the old JavaScript, and all of a sudden her crossword website stopped working because that site's developer didn't update the JavaScript. This grandma sure complains a lot about broken websites for someone who supposedly doesn't know what JavaScript is. What an entitled grandma. Why doesn't she just build Linux from source and check out a previous release of the browser from git.
Backward compatibility is not free, it would eventually become bloat that is too big to fix. MS Windows and Office for example, and Adobe Flash was killed for good. I’m sure you can find a lot of examples.
That is precisely what happened: I don't write Python (grandma doesn't write JS). Python changed (JS changed). Environment stopped supporting the old one (browser for grandma, package manager for me). End-user apps didn't keep up (website for grandma, the apps for me). I am now forced to go resolve these issues. This is 100% analogous. Please explain how it is not. In both scenarios you would blame the "app developer" (in the Python case you would blame app/library developers for bad dev practices or whatever, in the hypothetical you would blame the website developer for not updating the crossword page), and the end-use for being entitled (in my case, the user of various apps that are broken, and the grandma using the crossword website). You supposed solution is that we should either not complain, or I guess, ironically, just learn the base systems better to be more on top of things so we can compensate for the bad dev practices ourselves.
Also, I am not "trying hard" not to care about Python. I specifically said in my very first comment I go out of my way to avoid it now. I think that falls in the "cares" category. My default state is to not be aware of what language things are written in. I don't know if some given tool is written in C, bash, or JS. If I were to coincidentally learn what language it was written in, it might serve as a curiosity, but not really phase me either way. However, I was forced to become aware of a bunch of Python stuff since it started breaking, and then forced to learn about all the weird workarounds to get it working. Given that I was forced to repeatedly deal with dependency hell with apps in this language, I am now choosing to avoid it if I can in the future if I learn that an app is written in it.
The "magic date" when the breaking update came was 15 years ago. Python gave this developer 10 years to get with the program and update to the new version, and Debian kept it alive for an additional 5 just in case.
If a developer can't get their act together to change over their codebase to preserve minimum functionality despite FIFTEEN YEARS of warning, I don't want to be using their app because who knows what other obvious problems they are ignoring.
I fully agree with this sentiment and this is why I’m increasingly convinced that scripting languages (and any language that requires a VM which is not included in the platforms you deploy to) are wholly inappropriate for software which you distribute to non-developer end-users.
Nobody should ever have to be hit with obscure pip/virtualenv/pypy/etc bugs for trying to use your command line app. Nobody should have to suffer through an “installation” step that requires installing the language itself and running a language-provided package manager to install dependencies/etc. I don’t care how much you wrap it in a setup.sh that tries (and typically, fails miserably) to automate everything.
(For OS’s like linux, your distro-provided package managers make the situation slightly better, but only if you ship your app as a package using these distro’s built-in package systems, which is a huge pain if you want to support multiple distros.)
But if you opt to skip the package manager and want to ship a “simple” installation experience using something like a setup.sh, and you want to use a scripting language like python/ruby/etc (integrated with an installation of that language in $HOME or in some system directory), you’re treating your users to a world of pain. Please, please use a compiled language, and ship a binary (or collection of binaries/libraries that can sit in a folder together and just work when you run it.)
It's always amusing when the other person has to fall back on "The tricks on you! You invested time talking to me, while I deviously spent way less time and put less thought into my arguments. Don't you feel foolish now?" No, not really. As it turns out writing a couple paragraphs does not meaningfully impact the progress of my other work. And I would assume that's the case with most people.
How is it odd and entitled for an end user to not like it when things suddenly break?
That is, I believe, the entire point of the parent, is it not? That this whole migration was not quarantined to the Python developer community. That it spilled over to users in totally unrelated spaces.
I prefer Hg over Git but I use Git. Why? One time I tried to use hg command and it didn't work. Why? I was on a system that had incompatible Python interpreter to the Hg scripts.
That was it. Since then I use Git everywhere even though I prefer Hg.
It’s like my grandma complaining about the internet being slow... because her CPAP machine is tethered to the clinic with an IP connection and is shutting down every night at 2 AM because a Python script on the server at the other end is no longer running.
We've banned this account for repeatedly and egregiously breaking the site guidelines. Not cool.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
I think you are missing the key point here: I don't write a ton of Python. I don't write any Python. Of course you think this is old news. You write a lot of Python. You're totally plugged in. You've known this is coming, this inside baseball is "the thing" for you. My point is that, believe it or not, the rest of the world does not keep up to date with whatever the Python community is doing. This is not unique to Python. Most people in dev community X are not aware of what is happening in dev community Y. What is unique to Python is that all of a sudden we were forced to become aware as the downstream apps began to break. By creating a backwards compatibility issue in an interpreted language, you necessarily "backload" the end-user pain to when the apps, which by definition are updated later than the code within the apps, begin to break as packages are removed from package managers, or things are EOL'ed, etc. This is a situation that I can honestly not remember happening with any other language. I can't remember any other circumstance, and certainly not one where it proceeded to happen repeatedly, where I've been abruptly made aware that utilityX was written in a no-longer-supported version of C/perl/whatever (when I previously didn't even know what language it was), after I had been running it for ages.