That certainly depends on exactly what you're doing...
> But, I would argue, if you have a system with python, you should probably write PHP.
That's a new one, I've never heard anybody seriously advocate for PHP as a system scripting language before...
> Python has many uses, I just don't think system scripts or system utilities is one of them. That's C, perl, or bash land, and perl is clearly the frontrunner there.
Having written plenty of all of those in my life, I really disagree. Python is easier and faster to write, and for scripting that matters more than just about anything else. Performance is almost irrelevant.
Python is really not faster or easier to write than perl. It might be if you don't know perl, but if you do know perl, you basically can't get more expressive and terse than that.
The main problem with python is getting it on systems is the biggest pain in the ass imaginable. Even deploying C++ is simpler.
If you're making the script for yourself then sure, fine. As soon as you're distributing to systems you don't 100% control, drop python. It's just annoying and it's not worth it. That 150 like python script could've been a 100 line perl script, or a 150 line one if you want. And then, you can just plop the file on basically any unix-like and run it.
I should have said "accessible" not "easier to write", that's what I was trying to say. A much larger portion of programmers have meaningful experience writing python than perl or php. I'm more likely to get patches and/or good bug reports from users when the scripts break if the scripts are written in a language they have experience with.
> The main problem with python is getting it on systems is the biggest pain in the ass imaginable.
Just avoid external dependencies and use /usr/bin/python, most scripting doesn't need any external dependencies. Or maybe I'm not understanding what you mean?
> A much larger portion of programmers have meaningful experience writing python than perl or php
Yes, I would agree, and this has value. But if you're in the position of making the decision of what to use and you know both, then that changes things. It's the same thing with Bash. Lots of people, and sysadmins, know bash, so they write bash. But bash is still not the optimal choice for, I'd say, 90% of the stuff it's chosen for. And it's a self-eating beast. Shoving bash where it doesn't go only strengthens it's grip. You're feeding the gremlin, you know?
> Just avoid external dependencies and use /usr/bin/python
I think this is easier said than done and it's also partially cultural. I have seen many, many system scripts that assume a very recent version of python AND assume a bunch of python libraries. This is bad, and people need to stop doing this. At least have the decency to bundle the libraries or, better yet, statically link them using C or C++ or Rust or Zig or whatever. And if that seems overkill to people, I think that means they haven't considered what they're actually doing and if they even need those external libraries.
Bash has this problem, too, and much worse, because it just calls system utilities. So it assumes a very specific running environment.
Anyway, all of that being said, if you're not using any libs than maybe Python is fine, if you know the systems you're targeting will have Python. If not though, I stand by Perl. Just use 5.10 or whatever and boom, that shit will run truly anywhere.
That certainly depends on exactly what you're doing...
> But, I would argue, if you have a system with python, you should probably write PHP.
That's a new one, I've never heard anybody seriously advocate for PHP as a system scripting language before...
> Python has many uses, I just don't think system scripts or system utilities is one of them. That's C, perl, or bash land, and perl is clearly the frontrunner there.
Having written plenty of all of those in my life, I really disagree. Python is easier and faster to write, and for scripting that matters more than just about anything else. Performance is almost irrelevant.