7 ms·

I keep posting this, but my favorite rule of thumb came from a Google dev infra engineer who said that "every Python script over 100 lines should be rewritten i

I keep posting this, but my favorite rule of thumb came from a Google dev infra engineer who said that "every Python script over 100 lines should be rewritten in bash, because at least then you won't fool yourself into thinking it's production quality"

yodsanklai 7y ago
The Google shell style guide [1] says this: "If you are writing a script that is more than 100 lines long, you should probably be writing it in Python instead. Bear in mind that scripts grow. Rewrite your script in another language early to avoid a time-consuming rewrite at a later date." [1] https://google.github.io/styleguide/shell.xml https://google.github.io/styleguide/shell.xml
- a3n 7y ago
  Related, the longer your shell script gets, the greater potential for accumulated foot-guns. When you finally do the rewrite, will you be bug-compatible? And once discovered, will you be confident on which side the bug lies?
  - blaser-waffle 7y ago
    An aside: when did the phrase "foot-guns" become a thing. Cuz I've never heard it until this thread, where it pops up multiple times. Great phrase but went 0-60 in usage.
    - mrguyorama 7y ago
      I'm pretty sure it's at least as old as usenet and mail lists
- HocusLocus 7y ago
  "If you are writing a script that is more than 100 lines long, you should probably be writing it in Perl instead." This is true, especially of Python scripts.
  - RHSeeger 7y ago
    That way, it will never be rewritten again; because nobody will be able to read it. Edit: Getting some downvotes, so to clarify, I am indeed saying that concerting something from Python to Perl has a high likelihood of making it for less maintainable. I get that people can write good perl. As someone who has had to maintain perl in the past; the fact is that it's far more common for the end result to be horrible perl. I have some issues with Python, but it is FAR more maintainable than perl.
    - bsder 7y ago
      Let me drag this to something concrete: if you are interviewing, it is almost impossible to pass an amateur "Perl screen". Every single person who doesn't use Perl every day, professionally knows a different subset of Perl. This is one of the few times where being more knowledgeable than the interviewer is also a problem. You will write something, and the interviewer will question you on it because he has never seen it. I finally solved this problem by bringing one of my personal programs written in Perl and also rewritten in Python so we could talk about it. Now, the interviewer is in MY subset of Perl AND can't argue because I have working Perl code in front of him. This was back in the 1990's when everybody in VLSI design expected you to know Perl. Because of this "different subset" issue, if you want to maintain a Perl script, you have to basically know the entire language. This is what makes maintaining Perl scripts so difficult. This "different subset" problem is the whole reason I left the Perl ecosystem back in 1996(!) at the height of Perl's popularity and never looked back.
      - cosmojg 7y ago
        As an experienced Perl programmer, what's your opinion of Raku? Is it a worthwhile replacement or too little too late?
        redis_mlc 7y ago
        > As an experienced Perl programmer, what's your opinion of Raku? Perl5 still works fine, and is maintained. > Is it a worthwhile replacement or too little too late? False dichotomy - see above.
- cookiecaper 7y ago
  Stuff like this does a huge amount of unintentional damage. Every crappy company in the world thinks they're Google and tries to copy them. Google-caliber people might be able to be reasonable about this, but ordinary employees come across something like this and interpret it to mean "bash is evil" and ostracize everyone who tries to write a bash script for anything, no matter how sensible. At work lately, there's been a spate of contorted "just why?" Python scripts that could've been accomplished elegantly in a handful of lines of shell. While no one would select shell languages as the ideal for a lot of complex logic, data parsing, etc., there's no competition for a shell when you need to do what shells are meant to do: chaining invocations, gluing and piping output, and so on.
  - Godel_unicode 7y ago
    Just because they write crappy Python doesn't mean they'd write good shell scripts. For me it indicates the opposite.
  - samtheprogram 7y ago
    As Gary Bernhardt said, and I quote often, it makes sense when it’s right half of the ass. https://youtube.com/watch?v=ZQnyApKysg4 https://youtube.com/watch?v=ZQnyApKysg4
    - pmarreck 7y ago
      wow, have seen many of Gary's talks but not this one until now; clearly I missed a gem
  - DonHopkins 7y ago
    But bash IS evil.
    - cpach 7y ago
      Why?
      - 7y ago
echelon 7y ago
That's a cute heuristic, but I think the better practice is to distrust scripts without tests as they can quickly diverge from the rest of the codebase. It's still better to script in Python or Ruby than Bash. Nobody understands Bash. It's even more mysterious than Perl.
- fiddlerwoaroof 7y ago
  I’d rather write bash for orchestration than nearly anything else: bash is designed to make coordinating processes easy, something very few programming languages have managed to do.
  - laumars 7y ago
    The thing that gets me about all the new shells and shell scripting languages popping up these days is they loosely seem to fall into 2 categories: 1. more emphasis traditional programming paradigms (be it JS, LISP, Python, whatever) which leaves a platform that is arguably a better designed language but however is a poorer REPL environment for it. Bash works because it's terse and terseness is actually preferable for "write many, read once" style environments like an interactive command prompt. 2. or they spend so much effort supporting POSIX/Bash -- including their warts -- that they end up poorer scripting languages. I think what we really need isn't to rewrite all our shell scripts in Python but rather better shells. Ones which work with existing muscle memory but isn't afraid to break compatibility for the sake of eliminating a few footguns. Shells that can straddle both the aforementioned objectives without sacrificing the other. But there doesn't seem to be many people trying this (I can only think of a couple off hand).
    - jhasse 7y ago
      What are your thoughts about fish?
      - fiddlerwoaroof 7y ago
        Does fish still have the issue where pipelines aren’t really concurrent?
reagent_finder 7y ago
I want to disagree with this so badly because I have tried to do stuff that's just a bit too complex for bash and ended up scrapping the idea... but I can't. Hacky python is even worse.

yodsanklai 7y ago

The Google shell style guide [1] says this: "If you are writing a script that is more than 100 lines long, you should probably be writing it in Python instead. Bear in mind that scripts grow. Rewrite your script in another language early to avoid a time-consuming rewrite at a later date." [1] https://google.github.io/styleguide/shell.xml https://google.github.io/styleguide/shell.xml

a3n 7y ago
Related, the longer your shell script gets, the greater potential for accumulated foot-guns. When you finally do the rewrite, will you be bug-compatible? And once discovered, will you be confident on which side the bug lies?
- blaser-waffle 7y ago
  An aside: when did the phrase "foot-guns" become a thing. Cuz I've never heard it until this thread, where it pops up multiple times. Great phrase but went 0-60 in usage.
  - mrguyorama 7y ago
    I'm pretty sure it's at least as old as usenet and mail lists
HocusLocus 7y ago
"If you are writing a script that is more than 100 lines long, you should probably be writing it in Perl instead." This is true, especially of Python scripts.
- RHSeeger 7y ago
  That way, it will never be rewritten again; because nobody will be able to read it. Edit: Getting some downvotes, so to clarify, I am indeed saying that concerting something from Python to Perl has a high likelihood of making it for less maintainable. I get that people can write good perl. As someone who has had to maintain perl in the past; the fact is that it's far more common for the end result to be horrible perl. I have some issues with Python, but it is FAR more maintainable than perl.
  - bsder 7y ago
    Let me drag this to something concrete: if you are interviewing, it is almost impossible to pass an amateur "Perl screen". Every single person who doesn't use Perl every day, professionally knows a different subset of Perl. This is one of the few times where being more knowledgeable than the interviewer is also a problem. You will write something, and the interviewer will question you on it because he has never seen it. I finally solved this problem by bringing one of my personal programs written in Perl and also rewritten in Python so we could talk about it. Now, the interviewer is in MY subset of Perl AND can't argue because I have working Perl code in front of him. This was back in the 1990's when everybody in VLSI design expected you to know Perl. Because of this "different subset" issue, if you want to maintain a Perl script, you have to basically know the entire language. This is what makes maintaining Perl scripts so difficult. This "different subset" problem is the whole reason I left the Perl ecosystem back in 1996(!) at the height of Perl's popularity and never looked back.
    - cosmojg 7y ago
      As an experienced Perl programmer, what's your opinion of Raku? Is it a worthwhile replacement or too little too late?
      - redis_mlc 7y ago
        > As an experienced Perl programmer, what's your opinion of Raku? Perl5 still works fine, and is maintained. > Is it a worthwhile replacement or too little too late? False dichotomy - see above.
cookiecaper 7y ago
Stuff like this does a huge amount of unintentional damage. Every crappy company in the world thinks they're Google and tries to copy them. Google-caliber people might be able to be reasonable about this, but ordinary employees come across something like this and interpret it to mean "bash is evil" and ostracize everyone who tries to write a bash script for anything, no matter how sensible. At work lately, there's been a spate of contorted "just why?" Python scripts that could've been accomplished elegantly in a handful of lines of shell. While no one would select shell languages as the ideal for a lot of complex logic, data parsing, etc., there's no competition for a shell when you need to do what shells are meant to do: chaining invocations, gluing and piping output, and so on.
- Godel_unicode 7y ago
  Just because they write crappy Python doesn't mean they'd write good shell scripts. For me it indicates the opposite.
- samtheprogram 7y ago
  As Gary Bernhardt said, and I quote often, it makes sense when it’s right half of the ass. https://youtube.com/watch?v=ZQnyApKysg4 https://youtube.com/watch?v=ZQnyApKysg4
  - pmarreck 7y ago
    wow, have seen many of Gary's talks but not this one until now; clearly I missed a gem
- DonHopkins 7y ago
  But bash IS evil.
  - cpach 7y ago
    Why?
    - 7y ago

echelon 7y ago

That's a cute heuristic, but I think the better practice is to distrust scripts without tests as they can quickly diverge from the rest of the codebase. It's still better to script in Python or Ruby than Bash. Nobody understands Bash. It's even more mysterious than Perl.

fiddlerwoaroof 7y ago
I’d rather write bash for orchestration than nearly anything else: bash is designed to make coordinating processes easy, something very few programming languages have managed to do.
- laumars 7y ago
  The thing that gets me about all the new shells and shell scripting languages popping up these days is they loosely seem to fall into 2 categories: 1. more emphasis traditional programming paradigms (be it JS, LISP, Python, whatever) which leaves a platform that is arguably a better designed language but however is a poorer REPL environment for it. Bash works because it's terse and terseness is actually preferable for "write many, read once" style environments like an interactive command prompt. 2. or they spend so much effort supporting POSIX/Bash -- including their warts -- that they end up poorer scripting languages. I think what we really need isn't to rewrite all our shell scripts in Python but rather better shells. Ones which work with existing muscle memory but isn't afraid to break compatibility for the sake of eliminating a few footguns. Shells that can straddle both the aforementioned objectives without sacrificing the other. But there doesn't seem to be many people trying this (I can only think of a couple off hand).
  - jhasse 7y ago
    What are your thoughts about fish?
    - fiddlerwoaroof 7y ago
      Does fish still have the issue where pipelines aren’t really concurrent?

reagent_finder 7y ago

I want to disagree with this so badly because I have tried to do stuff that's just a bit too complex for bash and ended up scrapping the idea... but I can't. Hacky python is even worse.