4 ms·

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 fr

by 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.
- nibbula 8y ago
  Thanks, Don, for continuing to stand for truth in a energetic and entertaining manner.
- nickjj 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. I posted a link to it next to the sentence that talked about the types of tools I use it for, such as things on my dev box to help me in my day to day. > Have you ever written any 10k+ line bash scripts? No, because it doesn't scale (and machine generated configure scripts don't count) I've written a bunch of 1k+ line scripts. They aren't a problem to maintain and a number of them are being actively used and maintained by other people. These are for real production systems too. Some are single files, others are broken up into multiple files. I haven't personally written a 10k+ line script (the need for that has never happened), but I've seen a number of multiple thousand line scripts out in the wild that are very well maintained and are part of mission critical systems like setting up a PKI realm for a bunch of servers. That PKI script was something like 4,800 total lines of code but it being 10k+ wouldn't have made a difference for the worse. Shellcheck helps a lot with writing pretty well formed shell scripts. It's a really good linter.
  - DonHopkins 8y ago
    I just wanted to be clear that I'm not just making this stuff up, and you really did write what I quoted (claiming to have written 10k+ lines of shell scripts, that you only really looked at the docs a couple of times, and that bash syntax is humanly impossible to remember), but you ninja-edited it out later, after I quoted what you originally wrote: >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. Only really looking at the docs a couple times isn't something to brag about, and doing that doesn't make bash good. Nor is it good for languages to be designed so you don't have to read the manual (or else you get COBOL or HyperTalk, and then you still have to read the manual). Nor is it good for languages to have syntax things that are humanly impossible to remember. All those claims you deleted actually support my point about bash being terribly inferior to Python (whose syntax is extremely simple and easy to learn and remember and most importantly read, and it even has built-in interactive "help" documentation), which is why I quoted what you originally said in the first place. Again, what is it about that script you offered as an example that is easier, more elegant, or more maintainable and understandable to do in bash than in Python? If you don't have an answer to that, can you show me any other bash code that was better off written in bash than in Python? And explain how it's better, please.

by nickjj 8y ago

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.

nibbula 8y ago
Thanks, Don, for continuing to stand for truth in a energetic and entertaining manner.
nickjj 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. I posted a link to it next to the sentence that talked about the types of tools I use it for, such as things on my dev box to help me in my day to day. > Have you ever written any 10k+ line bash scripts? No, because it doesn't scale (and machine generated configure scripts don't count) I've written a bunch of 1k+ line scripts. They aren't a problem to maintain and a number of them are being actively used and maintained by other people. These are for real production systems too. Some are single files, others are broken up into multiple files. I haven't personally written a 10k+ line script (the need for that has never happened), but I've seen a number of multiple thousand line scripts out in the wild that are very well maintained and are part of mission critical systems like setting up a PKI realm for a bunch of servers. That PKI script was something like 4,800 total lines of code but it being 10k+ wouldn't have made a difference for the worse. Shellcheck helps a lot with writing pretty well formed shell scripts. It's a really good linter.
- DonHopkins 8y ago
  I just wanted to be clear that I'm not just making this stuff up, and you really did write what I quoted (claiming to have written 10k+ lines of shell scripts, that you only really looked at the docs a couple of times, and that bash syntax is humanly impossible to remember), but you ninja-edited it out later, after I quoted what you originally wrote: >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. Only really looking at the docs a couple times isn't something to brag about, and doing that doesn't make bash good. Nor is it good for languages to be designed so you don't have to read the manual (or else you get COBOL or HyperTalk, and then you still have to read the manual). Nor is it good for languages to have syntax things that are humanly impossible to remember. All those claims you deleted actually support my point about bash being terribly inferior to Python (whose syntax is extremely simple and easy to learn and remember and most importantly read, and it even has built-in interactive "help" documentation), which is why I quoted what you originally said in the first place. Again, what is it about that script you offered as an example that is easier, more elegant, or more maintainable and understandable to do in bash than in Python? If you don't have an answer to that, can you show me any other bash code that was better off written in bash than in Python? And explain how it's better, please.