In the absence of infinite money to actively maintain all libraries, there is no alternative.
The core of the problem is that libraries and even the language itself have to make non backwards compatible changes over time. No system can fix this.
What? People are just making decisions about how they want the language to evolve, how they want to coordinate production-grade releases, and how they approach backwards compatibility in those contexts.
Nothing about those decisions is necessitated or even strongly pressured. They're just an artifact of the Python community's particular engineering culture, and it's one that's uncommonly hostile to streamlined distribution or to shelving application code as stable and "done".
I don't understand your claim that this is a python specific issue.
There are C++ libraries that require C++11. As a result if you have an older compiler that does not support C++11 it will just not compile.
Same if you try to compile with C++11 compiler a super old project with old libraries. More likely than not it will break.
The fact that other languages ignore the problem, it does not make the problem go away.
At least python is pragmatist and comes with virtual environments instead of requiring me to set up containers or VMs to deal with package compatibility.
That was already the case for anything non-trivial in dependencies and language feature adoption.
And it was never the case (and still isn't) for projects relying on the standard library and a few popular stalwars (requests, psycopg, pandas, and so on), with conservative adoption of new language features.
There's also the fact that 2.7 and before Python seldom added new language systax, whereas 3+ is hell-bent on doing that with every release.
Fracturing happens for any popular, long-lived programming language. It's really no worse than C++, JavaScript, or Java which all have their own idiosyncracies you have to learn if you want to use the language.
Use cases evolve over time. "System Python" is a great example. One of the primary Python use cases in its 2.7 days was sysadmin scripts. For that, it made sense to have a "python" command that Just Worked that sysadmins could expect to be on any box when they SSH'd into it. These days, I suspect Python for sysadmin uses is significantly smaller than Python usage in web applications or Python for Jupyter notebooks. Those are two very different use cases, and that's why things like virtual environments, pip, poetry, conda, etc. got created.
> Fracturing happens for any popular, long-lived programming language.
There are many languages that are very stable over long periods of time. It's just that Python was a terrible language to begin with that got rushed designs and features tacked on to it over time. Even if you're a "lover" of something like asyncio, there's like three distinct "eras" of asyncio that have you write it in three different ways. Not only that, Python's asyncio is the worst implementation of it that I've seen. That's a common theme in Python packages.
Interestingly, Scala has a great solution to this, namely Scala-CLI[0]. You can do all the things... use whatever deps you want, pick the scala version, include tests in your script, etc. etc. So you can really have a self-contained scripts. (You'll need to have Scala-CLI installed, obviously, but they're working on a 'bundle-a-script-into-a-jar' thing so you'll only need a JRE.)
The dependencies thing is due to Maven repositories being The Repository standard for JVM languages. It's a low-key superpower of the JVM ecosystem, warts and all.
>You have to do this for all the languages, not just Python.
No, you only have to do this for all popular languages. Unpopular but stable long term languages exist and they are much better for system administration. I guess my point is that the pythons aren't for system admin anymore, they're for writting bleeding edge applications. A Perl interpreter from 2003 can run most Perl applications written today and a .pl script from 2003 will definitely run on a 2024 Perl.
The pythons' roles have changed and are different from the former role of Python. They have lost the stable properties it once had.
These are somewhat true but irrelevant statements. No one has used perl 4 since the early 90s. There's no Perl 6, only Raku. And I'm thankful for Raku mess diverting and then driving away developers that wanted change, it meant Perl didn't become the popular mess the pythons have.
For my entire life Perl 5 has been Perl and Perl code just works no matter when the OS system Perl is from. This is the pragmatic reality: it just works. And that's an amazing property for system administration and software distribution.
Some of that is avoidable schism. But some of it is a natural consequence of Python by itself not being quite sufficient to solve the real-world problems people are throwing at it - in particular stuff like Conda is very useful for numeric Python since it ultimately abstracts away a lot of C/Perl/etc. which downstream Python packages depend on, but which pip and venv/etc by themselves aren't designed to handle.
Technical ones? Please. It’s a particularly poor medium for anything technical and aimed at people who spend their entire days navigating text as quickly as humanly possible
Travel has always been central to my podcast listening. Now that I work from home and have no commute, I've totally fallen off my previous habit. I was at peak podcast consumption when I had a long commute both ways.
It's not just about listening to the whole podcast while you travel - you just need to get far enough so you want to finish it. So I would imagine even short commute periods could result in a lot more listening.
I also don’t get why anyone would listen to a podcast rather than something worthwhile eg an audiobook. That’s what I do during commute, and that’s what I recommend to others. I actually look forward to commuting nowadays, it’s probably the most interesting hour or so in my entire day.
Many times, and much more quickly than were I to listen to the same dialog at some practical playback speed.
But yeah, you make a good point: it's even more efficient if people just prepare material to be read in the first place instead of relying on performed dialogs at all. That's always preferred.
I keep a queue of such podcasts for times when I'm walking the dogs, cleaning the house, doing yard work, commuting, grocery shopping, waiting in line, etc. I listen to them at 1.5x to be able to hear more of them, and I still have to prioritize what I want to listen to most, but I find that little gaps in my life allow plenty of podcast listening time.
> Based on Facebook's PR campaign, the name change reflects the company's shifting long term focus of building the metaverse, a digital extension of the physical world by social media, virtual reality and augmented reality features.
Also note that they did it to get the bad PR heat off of Facebook. It was a synergistic move: less bad PR and focusing on the new thing, all at the same time!
That is true, but while it explains why the name changed it doesn’t justify why it changed to Meta specifically. My comment was only addressing the latter as that was the question.
It was also helpful to make the name change right around the time the news about the Cambridge Analytica scandal was coming out.
"Hey everybody, we're building the metaverse now so please ignore our facilitation of digital electioneering! See look our name isn't even the same so it's like we didn't do anything at all!"
even more hilarious is how society/developers just accept these new names and use them (meta, x) rather than simply resisting and continuing to call them Facebook, or Twitter. It's like they've been collectively brainwashed into thinking you can deadname a corporation and should feel bad about it.
I know I keep posting this, but my favorite (half-joking) programming advice was from a Google dev infra engineer who said "Any Python script over 100 lines should be rewritten in Bash, because at least that way you're not fooling yourself into thinking it's production quality"
52 comments
[ 3.4 ms ] story [ 118 ms ] threadThe core of the problem is that libraries and even the language itself have to make non backwards compatible changes over time. No system can fix this.
What? People are just making decisions about how they want the language to evolve, how they want to coordinate production-grade releases, and how they approach backwards compatibility in those contexts.
Nothing about those decisions is necessitated or even strongly pressured. They're just an artifact of the Python community's particular engineering culture, and it's one that's uncommonly hostile to streamlined distribution or to shelving application code as stable and "done".
There are C++ libraries that require C++11. As a result if you have an older compiler that does not support C++11 it will just not compile.
Same if you try to compile with C++11 compiler a super old project with old libraries. More likely than not it will break.
The fact that other languages ignore the problem, it does not make the problem go away.
At least python is pragmatist and comes with virtual environments instead of requiring me to set up containers or VMs to deal with package compatibility.
And it was never the case (and still isn't) for projects relying on the standard library and a few popular stalwars (requests, psycopg, pandas, and so on), with conservative adoption of new language features.
There's also the fact that 2.7 and before Python seldom added new language systax, whereas 3+ is hell-bent on doing that with every release.
Use cases evolve over time. "System Python" is a great example. One of the primary Python use cases in its 2.7 days was sysadmin scripts. For that, it made sense to have a "python" command that Just Worked that sysadmins could expect to be on any box when they SSH'd into it. These days, I suspect Python for sysadmin uses is significantly smaller than Python usage in web applications or Python for Jupyter notebooks. Those are two very different use cases, and that's why things like virtual environments, pip, poetry, conda, etc. got created.
There are many languages that are very stable over long periods of time. It's just that Python was a terrible language to begin with that got rushed designs and features tacked on to it over time. Even if you're a "lover" of something like asyncio, there's like three distinct "eras" of asyncio that have you write it in three different ways. Not only that, Python's asyncio is the worst implementation of it that I've seen. That's a common theme in Python packages.
The dependencies thing is due to Maven repositories being The Repository standard for JVM languages. It's a low-key superpower of the JVM ecosystem, warts and all.
[0] https://scala-cli.virtuslab.org/
Language toolchain.
You have to do this for all the languages, not just Python. Hence nix and other tools were made.
No, you only have to do this for all popular languages. Unpopular but stable long term languages exist and they are much better for system administration. I guess my point is that the pythons aren't for system admin anymore, they're for writting bleeding edge applications. A Perl interpreter from 2003 can run most Perl applications written today and a .pl script from 2003 will definitely run on a 2024 Perl.
The pythons' roles have changed and are different from the former role of Python. They have lost the stable properties it once had.
For my entire life Perl 5 has been Perl and Perl code just works no matter when the OS system Perl is from. This is the pragmatic reality: it just works. And that's an amazing property for system administration and software distribution.
It's not just about listening to the whole podcast while you travel - you just need to get far enough so you want to finish it. So I would imagine even short commute periods could result in a lot more listening.
Is it possible that other people have different preferences?
It's just nice that we can unite around our shared passion for correcting people who are wrong on the Internet.
It’s an advantage to have transcripts.
But yeah, you make a good point: it's even more efficient if people just prepare material to be read in the first place instead of relying on performed dialogs at all. That's always preferred.
[0] at least, they really should. kids need to socialise with others their age
Metaverse. Zuckerberg’s obsession with the concept (and that being the origin of the chosen name) is well documented.
https://en.wikipedia.org/wiki/Meta_Platforms#2021:_Rebrand_a...
> Based on Facebook's PR campaign, the name change reflects the company's shifting long term focus of building the metaverse, a digital extension of the physical world by social media, virtual reality and augmented reality features.
"Hey everybody, we're building the metaverse now so please ignore our facilitation of digital electioneering! See look our name isn't even the same so it's like we didn't do anything at all!"