3 ms·

> echo " > \$$(echo "100 ${default_hourly}" | bc -l) 100.00 \$${default_hourly} 50 acme"* > Don't tell me you prefer writing shell scripts that do simple ari

by nickjj 8y ago

> echo " > \$$(echo "100 ${default_hourly}" | bc -l) 100.00 \$${default_hourly} 50 acme"* > Don't tell me you prefer writing shell scripts that do simple arithmetic because it's more convenient than using Python. That's not a fair comparison. The code you pasted isn't just doing the calculation. It's dynamically generating a human readable help menu that shows both the input and output of what the script will do. That requires quite a bit more characters and escaping. The "real" calculation to get the hourly is: amount="$(echo "${total_hours} * ${hourly_rate}" | bc -l)" Seems pretty straight forward to me. Plus, that's a really cherry picked example in Python's favor. You should evaluate the whole script's purpose. It's mostly just reading and filtering text output from a file and then performing basic math on the filtered text. Seems like a textbook case to use Bash IMO.

DonHopkins 8y ago
It's perfectly fair. You're the one who got to cherry pick the script to use as an example, so don't complain that I cherry picked the most ridiculous line of that code. Python can generate a human readable help menu with much less trouble. Tell me one thing about that script that's easier in bash than in Python. Forking off sed? Python doesn't need to, it has string manipulation. Forking off bc? Python doesn't need to, it has arithmetic. And why are you using sed regular expressions just to do arithmetic? Now you have two problems! https://blog.codinghorror.com/regular-expressions-now-you-have-two-problems/ https://blog.codinghorror.com/regular-expressions-now-you-ha... Again, look at the Linux kernel and userland source code and give me a ballpark estimate of how many instructions it requires to multiply a number by 100 by forking off bc or sed, instead of executing a single "mul" instruction. And Python code doesn't require a page of comments to explain why it has to go to so much effort and work around so many pitfalls just to convert a couple of strings to decimal hours. Why, Python even has named function parameters -- now THAT is TRULY "amazing". And in the number of keystrokes it took you to write the following comments (and the number of trials and errors it took you to finally get it right), you could have imported a hell of a lot of powerful Python modules, and read a lot of the interactive built-in help documentation about their APIs. Your time would be much better spent getting used to using Python rather than sed. to_decimal_hours () { local hours="${1}" local minutes="${2}" # [h: ] uses the "h", ":" or " " character as a split delimiter. # # If the first split argument ends with "m", then we're not dealing with # hours at all, only minutes, so now $1 becomes minutes and we divide by # 60 because you can't have more than 60 minutes in 1 hour. # # Otherwise, we have both hours ($1) and minutes ($2). The hours can be # taken as is, and like before the minutes get divided by 60. # # It's also important to send both the hours and minutes in without a # space as input, otherwise values like "30m" will end up being "30m " # which makes $1 no longer end with an "m" and it will incorrectly report # back 30.00 instead of 0.5. # # awk will automatically remove the "h" and "m" characters when it comes # time to do the addition. # # Yep, awk is amazing. I'm just getting used to using it! awk -F '[h: ]' '{ if ($1 ~ /m$/) printf("%.2f\n", ($1 / 60)); else printf("%.2f\n", $1 + ($2 / 60)) }' <<< "${hours}${minutes}" }
- nickjj 8y ago
  I'm not even going to reply to all of that. Look, if you want to sit there and rip into a stranger on the internet for open sourcing a Bash script (on their free time) then by all means knock yourself out. For the record I've written more Python than I have Bash (by a substantial amount). I wrote that script in Bash because it took literally 3 minutes to prototype it on the command line with grep, cut and bc so I spent the extra hour turning it into its current form. It does exactly what I want it to do (nothing less, nothing more). Also the code is MIT licensed. Free free to fork it, rewrite it in Python, test it on 50+ real invoices, write extensive test coverage, write ~1500+ words of documentation and then make a ~20 minute video showing to use it.
  - DonHopkins 8y ago
    You're the one who offered up that code as an example in the first place, to prove your point about bash being really great for people who don't want to bother reading documentation. Being open source doesn't magically make your code great or efficient or bug-free or easy and irresistible for millions of eyeballs to examine and audit (in spite of what ESR's fallacious "Linux's Law" might claim), or obligate anyone to complement it or use it or take it and run with it. https://en.wikipedia.org/wiki/Linus%27s_Law https://en.wikipedia.org/wiki/Linus%27s_Law If you make your code open source, then post links to it in public forums, right after bragging about only reading the language documentation a couple of times, you'd better get over being thin skinned about criticism. I'm not criticizing your code, or your decision to open source it, or which license you chose, or your pride in only reading the documentation twice, or your decision to cherry pick and share that script as the best example you could come up with of bash's superiority. I'm criticizing your decision to write the code in bash instead of Python. Can you at least please answer this one simple question: Name one thing about that code that is easier in bash than in Python? >I've written literally thousands of lines of shell scripts (maybe even 10k+) across dozens of scripts over the years and I've only really looked at the docs a couple of times. Of course I'm Googling various syntax things that are humanly impossible to remember, but I never once really sat there and combed through all of the docs or even read a book on Bash. At least you admit 1) you've only really looked at the docs a couple of times, and 2) bash syntax things are humanly impossible to remember. Have you ever written any 10k+ line bash scripts? No, because it doesn't scale (and machine generated configure scripts don't count). I have a 16,078 line Python script in my emacs buffer right now that I wrote over more than a decade (which is just one facet of a big system written in many other languages). My point (which is just a corollary of JWZ's Law of Software Envelopment and Greenspun's Tenth Rule) is that programs always grow over time, and you never realize how big and complex your programs are going to grow or how far they're going to evolve when you first write them. So never assume you can get away with using a language that's so lame it has to call out to two other different languages just to perform simple string manipulation and arithmetic. Good grief, even TCL can perform string manipulation and arithmetic without forking a bunch of new processes. You should invest more time using languages with docs you can actually read, and with syntax you can actually remember. You might like it. https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles >Zawinski's law of software envelopment (also known as Zawinski's law) comments on the phenomenon of software bloating with popular features: >Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule >Greenspun's tenth rule of programming is an aphorism in computer programming and especially programming language circles that states: >Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

by nickjj 8y ago

DonHopkins 8y ago

It's perfectly fair. You're the one who got to cherry pick the script to use as an example, so don't complain that I cherry picked the most ridiculous line of that code. Python can generate a human readable help menu with much less trouble. Tell me one thing about that script that's easier in bash than in Python. Forking off sed? Python doesn't need to, it has string manipulation. Forking off bc? Python doesn't need to, it has arithmetic. And why are you using sed regular expressions just to do arithmetic? Now you have two problems! https://blog.codinghorror.com/regular-expressions-now-you-have-two-problems/ https://blog.codinghorror.com/regular-expressions-now-you-ha... Again, look at the Linux kernel and userland source code and give me a ballpark estimate of how many instructions it requires to multiply a number by 100 by forking off bc or sed, instead of executing a single "mul" instruction. And Python code doesn't require a page of comments to explain why it has to go to so much effort and work around so many pitfalls just to convert a couple of strings to decimal hours. Why, Python even has named function parameters -- now THAT is TRULY "amazing". And in the number of keystrokes it took you to write the following comments (and the number of trials and errors it took you to finally get it right), you could have imported a hell of a lot of powerful Python modules, and read a lot of the interactive built-in help documentation about their APIs. Your time would be much better spent getting used to using Python rather than sed. to_decimal_hours () { local hours="${1}" local minutes="${2}" # [h: ] uses the "h", ":" or " " character as a split delimiter. # # If the first split argument ends with "m", then we're not dealing with # hours at all, only minutes, so now $1 becomes minutes and we divide by # 60 because you can't have more than 60 minutes in 1 hour. # # Otherwise, we have both hours ($1) and minutes ($2). The hours can be # taken as is, and like before the minutes get divided by 60. # # It's also important to send both the hours and minutes in without a # space as input, otherwise values like "30m" will end up being "30m " # which makes $1 no longer end with an "m" and it will incorrectly report # back 30.00 instead of 0.5. # # awk will automatically remove the "h" and "m" characters when it comes # time to do the addition. # # Yep, awk is amazing. I'm just getting used to using it! awk -F '[h: ]' '{ if ($1 ~ /m$/) printf("%.2f\n", ($1 / 60)); else printf("%.2f\n", $1 + ($2 / 60)) }' <<< "${hours}${minutes}" }

nickjj 8y ago
I'm not even going to reply to all of that. Look, if you want to sit there and rip into a stranger on the internet for open sourcing a Bash script (on their free time) then by all means knock yourself out. For the record I've written more Python than I have Bash (by a substantial amount). I wrote that script in Bash because it took literally 3 minutes to prototype it on the command line with grep, cut and bc so I spent the extra hour turning it into its current form. It does exactly what I want it to do (nothing less, nothing more). Also the code is MIT licensed. Free free to fork it, rewrite it in Python, test it on 50+ real invoices, write extensive test coverage, write ~1500+ words of documentation and then make a ~20 minute video showing to use it.
- DonHopkins 8y ago
  You're the one who offered up that code as an example in the first place, to prove your point about bash being really great for people who don't want to bother reading documentation. Being open source doesn't magically make your code great or efficient or bug-free or easy and irresistible for millions of eyeballs to examine and audit (in spite of what ESR's fallacious "Linux's Law" might claim), or obligate anyone to complement it or use it or take it and run with it. https://en.wikipedia.org/wiki/Linus%27s_Law https://en.wikipedia.org/wiki/Linus%27s_Law If you make your code open source, then post links to it in public forums, right after bragging about only reading the language documentation a couple of times, you'd better get over being thin skinned about criticism. I'm not criticizing your code, or your decision to open source it, or which license you chose, or your pride in only reading the documentation twice, or your decision to cherry pick and share that script as the best example you could come up with of bash's superiority. I'm criticizing your decision to write the code in bash instead of Python. Can you at least please answer this one simple question: Name one thing about that code that is easier in bash than in Python? >I've written literally thousands of lines of shell scripts (maybe even 10k+) across dozens of scripts over the years and I've only really looked at the docs a couple of times. Of course I'm Googling various syntax things that are humanly impossible to remember, but I never once really sat there and combed through all of the docs or even read a book on Bash. At least you admit 1) you've only really looked at the docs a couple of times, and 2) bash syntax things are humanly impossible to remember. Have you ever written any 10k+ line bash scripts? No, because it doesn't scale (and machine generated configure scripts don't count). I have a 16,078 line Python script in my emacs buffer right now that I wrote over more than a decade (which is just one facet of a big system written in many other languages). My point (which is just a corollary of JWZ's Law of Software Envelopment and Greenspun's Tenth Rule) is that programs always grow over time, and you never realize how big and complex your programs are going to grow or how far they're going to evolve when you first write them. So never assume you can get away with using a language that's so lame it has to call out to two other different languages just to perform simple string manipulation and arithmetic. Good grief, even TCL can perform string manipulation and arithmetic without forking a bunch of new processes. You should invest more time using languages with docs you can actually read, and with syntax you can actually remember. You might like it. https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles >Zawinski's law of software envelopment (also known as Zawinski's law) comments on the phenomenon of software bloating with popular features: >Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule >Greenspun's tenth rule of programming is an aphorism in computer programming and especially programming language circles that states: >Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.