It is a very useful tool that is downloading and copying lots of stuff for you, from Google, Bing, ARC etc and generating scenery for a flight sim.
Oh yeah, I even mentioned a few times that it has its uses, no doubt about that. For some reason it was a lot more popular like a decade ago, so there's lots of useful libraries for it , e.g. for web scraping stuff. That's typically network bound, so who cares that the language itself is dog slow — if it works, it works.
We were discussing the merits of the language itself; it's quite obvious for anybody who's not deluded or a fanatic that it's a terrible idea to start some serious big project in Python these days. Like you correctly identified
Burning Bridges, replacing more complex shell scripts with Python is another area where it's still relevant (convenience plays a large part in that, as Python is included by default in virtually all Linux distros and in macOS).
I guess that is the reason why some startups picked it up as the main development language for web-only stuff a decade or more ago. The perception (and perhaps even the reality) back then was that you can develop stuff in "dynamic" languages faster (whether that's actually true even medium-term, I very much doubt it, but it can feel faster in the beginning). In startups like that time to market is the primary consideration, doesn't matter if v1.0 is a piece of shit technically and a maintenance burden, it only needs to barely function so you get your next round of funding money, then you can rewrite the whole crap anyway.
Ironically, Porky is right that CEO/CTOs of startups picked up Python & Ruby a lot more often in the past; usually these people are hucksters with just enough technical knowledge to be dangerous, so they probably just picked up some dynamic language because other startups did the same, read an article about it, or believed that it would help them produce their v1.0 prototypes faster. What gets forgotten is that 99.99% of huckster-lead startups fail, so there's a large dose of survivor bias in that "brilliant companies use Python" argument... "Brilliant" is also relative — they can be financially successful and still have a net-negative effect on mankind as a whole.
That's ironically the Achilles heel of Porky's argument — now that strongly typed languages with good type inference that *also* compile quickly are widespread, there's very little reason to fuck around with something inferior like Python (or Ruby, or whatever). Basically, the relative "popularity" of it you can still somewhat observe is due to inertia. Plus some researchers/academics who are not primarily coders picked it up for scientific stuff, but that's changing quickly as people are migrating to better options that are just as easy to use but perform several orders of magnitude better (e.g. for AI, data analysis, statistics, etc.)
For example:
https://github.com/mratsim/Arraymancer
Arraymancer is a tensor (N-dimensional array) project in Nim. The main focus is providing a fast and ergonomic CPU, Cuda and OpenCL ndarray library on which to build a scientific computing ecosystem.
The library is inspired by Numpy and PyTorch and targets the following use-cases:
...
The ndarray component can be used without the machine learning and deep learning component. It can also use the OpenMP, Cuda or OpenCL backends.
Note: While Nim is compiled and does not offer an interactive REPL yet (like Jupyter), it allows much faster prototyping than C++ due to extremely fast compilation times. Arraymancer compiles in about 5 seconds on my dual-core MacBook.
For many real-world problems no computer in existence is fast enough. And when compilation times for complex projects go down to a few seconds, dynamic languages start to lose all their advantages, basically.
For reference, when I'm recompiling DOSBox on my Mac after making changes to implementation files only, recompilation is less than 2 seconds with Meson.
A strong argument *for* dynamic languages is LISP, where you can modify the running program, hot replace functions, and do many other interesting things. However, some of the cool LISP functionality has been replicated in JVM debuggers. I would personally only bother with dynamic languages if it's a LISP or Scheme.
