4 ms·
>That's more of cultural problem in the Python community. The Python community also loves making minor breaking changes. Like the language itself, with the cha
by logicchains 3y ago
>That's more of cultural problem in the Python community.
The Python community also loves making minor breaking changes. Like the language itself, with the changes from Python2 to Python3, then later on the changes to e.g. introduce "async" as a keyword and break all existing code that had a variable of the same name. Some dynamic languages, like Clojure, take the approach that it's not okay to collectively waste tens to hundreds of thousands of hours of users' collective time just to satisfy the library developer's aesthetic urges, and packages very rarely make breaking changes. Personally I'd much prefer a language/library with some deprecated cruft than one that wastes days of my time updating my code every time some developer finds a new way to make their API "cleaner".
- BiteCode_dev 3y agoPython was created 30 years ago, before Java, at the time the first game boy came around. It accumulated a lot of things, and it’s a constant battle to balance what to change (to keep the project lean and modern) and what to keep (to maintain compat). Whatever move you chose, someone in the community will say the core devs are doing it wrong. I read as many posts saying python is moving too fast as ones saying it’s not adopting “feature x” fast enough. As many people saying we should get rid of the GIL than one saying they are deprecating too many API. When you are as popular as Python, with a community as diverse, it’s very hard job.
- logicchains 3y ago>Python was created 30 years ago, before Java, at the time the first game boy came around. C++ was created even earlier, and it largely managed to maintain backwards compatibility; most code from back then will still compile, albeit with warnings.
- BiteCode_dev 3y agoIndeed, and you can hear how many people will critic it for having accumulated so many cruft. You just cannot win.
- crabbone 3y agoPython was never lean nor modern. It was a still-born language, intended more like a toy / joke, if you want to give credit to its author. It's very aspirational to claim that there's some process that involves intelligent thought that decides what features should be added or removed from the language. From where I stand, a petri dish has more intelligence than all Python core devs combined.
- barbariangrunge 3y agoWhy is python so popular? It reminds me of a less flexible JavaScript, except a little cleaner feeling. However, the flexibility (functions are data, etc) is the main allure of JavaScript, besides it being required for web What draws everyone to python? Why don’t people use c# or Java or c++ or some other language? What’s the killer benefit they get?
- orwin 3y agoNumpy, scikit (learn/image), panda, and probably tensorflow (never used that one). Tbf numpy+pandas is like using a mathlab that also have easy way to do http requests/web scraping, so there's that. I didn't really do datascience in 6 years now (except that one time I demo'ed our jupyterlab+dask setup vs a classic Hadoop), but to me those are the clear reasons. Also the first time I used python I was doing a CTF and had to add between 70 and 130 NOP (randomly) before the payload. I think I now could do that in perl and awk, but at the time it was a python one-liner and I do think python was the easiest to debug between the three, hence was the best solution.
- crabbone 3y agoToday, Python is popular because Python is popular. It doesn't have any engineering merits of its own. But you also cannot compete against it on engineering merits. It doesn't matter if you do everything better in your language than how it's done in Python. Unless you find a way to make it popular, Python will stay popular and your language will fade into oblivion. What was the initial seed that created this popularity? -- well, it seemed cool for nonsense reasons. The choice of Python was often reactionary, to spite those who chose Java. Python just happened to fill the niche of "what language should I write in if I think Java sucks?" This had an appeal to better programmers of that time (early 2000s), and this made others believe that language was what made those better programmers better. The better programmers started to flee Python some 5-10 years later, but it had already enough momentum to attract lots of mediocre programmers, and before you knew it, Python started to be used everywhere, and while the quality of Python programmers consistently dropped, the popularity only grew. So... if you are planning on a project for yourself, or for a group of skilled and motivated individuals -- there's no reason to choose Python, in fact, you'll come to regret it if you do. But, if your goal is to make a project in the context of an industry giant, then Python is a great pick -- you'll have an infinite stream of replaceable programmers, lots of 3rd-party libraries. You'll save a lot on developing the product. It won't be a high-quality one, but in this context nobody cares about quality anyways.
- andybak 3y ago> The Python community also loves making minor breaking changes. This is almost entirely untrue. Python 3 was a huge deal because the community held off for so long on making breaking changes. The async thing was probably a misstep. That happens.
- crabbone 3y agoThat's actually very true, the author just didn't choose a very good example. The reality of Python is this: there's no standard and no obligation to keep any Python code working. The matrix of supported environments is huge. So, to even build and test packages for more than 4 minor language versions is prohibitively expensive. The 4 here is a very important number. Python's own release cycle is intended in such a way that they don't care about more minor versions backwards: and typically, you can no longer build Python of that version on a modern OS with a modern compiler. Another consequence of this is that if you need to install an older package, even if in principle it should work with current Python, you'll discover that Python packages will have a lot of very particular and very convoluted dependency relationships. These typically work if you can allow yourself to be within last 4 versions of Python, but if you fall behind -- all bets are off. You start to discover that you can no longer install things due to botched dependency specification, you start installing things manually, repackaging while fixing dependency definitions and so on. Some of these problems can be blamed / explained in terms of others. Eg. interface of SSL library Python uses changed in incompatible ways not so long ago, which now prevents older codebase from building with new library and newer codeabse building with the old one. There's a similar story with C interface, TK bindings, and probably more that I didn't encounter personally. > community held off for so long on making breaking changes. That's bullshit. Community bravely moves fast and breaks things. Just not in the case of Python 2.X -> Python 3.X transition. But that's rather an odd exception to the rule.
- newZWhoDis 3y ago> introduce "async" as a keyword and break all existing code that had a variable of the same name. Seriously? Anyone who named a variable “async” had it coming.