8 ms·

I don’t understand all the hate for bash or python in this thread. These are programming languages. Like all programming languages one must understand how to d

I don’t understand all the hate for bash or python in this thread. These are programming languages. Like all programming languages one must understand how to deploy them and use them properly. Yes bash has faults absolutely. It can be very arcane and esoteric and I think this due to the fact that it’s creators are very much of the old 1970s and 1980s Unix mindset and largely bash tools still feel like they work the way they did back then Python is also a tool. I have written scripts in python to manage processes do forking etc and it too has some warts. It is also used by companies tohat deploy thousands of lines of code or more. Yes it isn’t statically typed and yes you can get into a box but guys no single language is objectively superior to another. So learn them like you would any other tool and move on.

pstuart 9y ago
I like bash, but I think I understand the hate -- it's the slippery slope of "gluing real applications" to "I can write this all in bash!". Just because you can, doesn't mean you should.
- s3m4j 9y ago
  If the application can be reduced to some form of simple piping of existing programs...
- amptorn 9y ago
  I enjoy the section of the Advanced Bash-Scripting Guide which explains how Bash has sparse arrays which "are useful in spreadsheet-processing software".[0] Because someone out there is apparently writing spreadsheet-processing software in Bash? [0] http://tldp.org/LDP/abs/html/arrays.html http://tldp.org/LDP/abs/html/arrays.html
kazinator 9y ago
> due to the fact that it’s [sic] creators are very much of the old 1970s and 1980s Unix mindset Firstly, Bash is relied upon to conform to a standard; it's not an exploratory project which expresses the maintainers' views about what a shell should look like. Secondly, Stallman didn't start Bash because he loved Unix. It was a pragmatic choice. Stallman really wanted a free platform based on Lisp. He went with cloning the Unix user space because that was becoming a dominant OS. It was proprietary software, and he wanted to replace that directly with workalike free software, rather than to provide incompatible free software and then have to evangelize not only freedom, but also a different platform at the same time. There were some technical reasons. Stallman rejected the idea of copying the Lisp Machine approach: https://www.gnu.org/gnu/rms-lisp.en.html https://www.gnu.org/gnu/rms-lisp.en.html At first, I thought of making a Lisp-based system, but I realized that wouldn't be a good idea technically. To have something like the Lisp machine system, you needed special purpose microcode. That's what made it possible to run programs as fast as other computers would run their programs and still get the benefit of typechecking. Without that, you would be reduced to something like the Lisp compilers for other machines. The programs would be faster, but unstable. Now that's okay if you're running one program on a timesharing system — if one program crashes, that's not a disaster, that's something your program occasionally does. But that didn't make it good for writing the operating system in, so I rejected the idea of making a system like the Lisp machine. I decided instead to make a Unix-like operating system that would have Lisp implementations to run as user programs. The kernel wouldn't be written in Lisp, but we'd have Lisp. https://www.gnu.org/gnu/thegnuproject.en.html https://www.gnu.org/gnu/thegnuproject.en.html For example, we developed the GNU C library because a Unix-like system needs a C library, BASH because a Unix-like system needs a shell, and GNU tar because a Unix-like system needs a tar program. The same is true for my own programs—the GNU C compiler, GNU Emacs, GDB and GNU Make.
- no_wizard 9y ago
  Yeah, when you dig down into the specifics I was not doing the history justice. My broader point was that it was definitely designed in a different era, with a different mindset, and has still managed to persist to this day, without that mindset shifting very much (usually for good reasons, or backward compatibility, which may or not be a good reason depending on specific circumstances) I often wonder if shell scripts would get such a bad wrap if all the backwards compatible code was strip out and only the latest standards were put in. I think thats where it gets people so very confused & it definitely feels awkward. I think its actually a perfectly fine language, syntactically speaking.
danmg 9y ago
Because python was the cool thing a few years ago, and it managed to get traction in a lot of places because it was pretty easy and included a lot of tools. It's also taught as an intro language now. So now you have to deal with people who are poopooing it because it doesn't have enough nerd cred like some like some other dynlang. Shell scripting has some other issues though. While most Bourne derived shells look similar, they have different extensions and capabilities. So only a subset of scripts will work everywhere.
Retra 9y ago
Just because all languages have flaws does not mean one language cannot be superior to another. Don't respond to one fallacy by employing another one.
yodsanklai 9y ago
> no single language is objectively superior to another I would say some languages are objectively superior to other for specific tasks. The problem is that very often the task to solve doesn't exactly fall within the realm of any given programming language and one has to make compromise. As for bash, I use it when I feel it's the best option, but I also think it's the worst programming language that I have to use. I wish there were better options. Are there any modern promising replacements for bash?
- davvolun 9y ago
  Yeah, trivially, a language like Brainfuck is clearly not a good choice for anything professional or maintainable; therefore, there must be some selection criteria that makes some languages objectively better than other languages. Whether PHP is a "bad" language or C# is better than Java is harder (and generally a waste of time -- pick something that works 95% of your use-case and figure out the other 5%), but refining the phrase to "no commercially used language is objectively superior to another" starts to make the statement useless to the point of irrelevance.
- no_wizard 9y ago
  Sure, I agree, for specific tasks. Just like a hammer is a better tool than a screw driver for putting nails in a block of wood. Thats my point. They're tools not lifestyle choices. Learn your tools, know your tools, don't be afraid of other people's tools. They all, usually, have some sort of value. I might as well note this too: I am speaking in broad strokes, you're going to be able to pinhole this as much as you want because of that. I'm simply suggesting that if your immediate reaction to how another organization uses these tools to replace A with B at a certain level is "this is clearly inferior" instead of "well, what can I learn from this" well, there's the problem. I used to think programmers/computer scientists where open minded people. Then I realized as a whole it tends to be we're only open minded if its within the domain we chose to be most active in Still far and away better than any other folks I've met, of course, but this is really a community culture problem, which is why I find it so counter productive. Alternatives to bash? Many do exist. zsh is bash compatible but does implement its own tools and subsets. If you're looking for something that removes the bash syntax there is powershell, which does run on Linux/macOS now as well: https://github.com/PowerShell/PowerShell https://github.com/PowerShell/PowerShell Then of course, there is oil shell: https://github.com/oilshell/oil https://github.com/oilshell/oil which is more like a subset of bash (and somewhat close to the idea of stripping away all the legacy stuff) Then there is xonsh: lets you use python as a basis for most everything http://xon.sh/ http://xon.sh/ The stalwart fish: https://fishshell.com/ https://fishshell.com/ fish shell has alot of niceties and a more object oriented syntax (kind of) and for the daring there is ergonomica: https://ergonomica.readthedocs.io/en/latest/ https://ergonomica.readthedocs.io/en/latest/ which has a lisp like syntax as does https://github.com/dundalek/closh https://github.com/dundalek/closh which uses clojure and its syntax and i'm sure there are more.
arca_vorago 9y ago
It's because so many here on hn are the compsci theoritical programmer, sysadmins are dying devops is everything, kind of people who don't actually support production systems other than maybe their particular depts single page webapp, etc... Hn has a problem with people living in the SV filter bubble seeing everything through that lens... in the real world, bash is still a king. When your devs shit out some bad code that causes your sysadmin to get a call at 3am... he's using bash to fix your fucking nodejs or whatever fadofthemoment bullshit you decided to run with. Of course entire applications generally shouldn't be in bash... it's like a kit of duct tape, epoxy, and rivets. Of course you should have made the product better, but when it does break, bash can keep it together until you get to the shop. I also think there is a certain amount of eliteism. It has such a low barrier to entry, it's like some people hate the idea of people being able to program without being programmers. I've heard it all so much here it just goes in one ear and out the other. /end bofh rant
- IdiocyInAction 9y ago
  Don't know if I would say that bash has a low barrier of entry. I find doing stuff in Python far more intuitive than in bash, it certainly has its quirks. I agree on the rest though.
- tomc1985 9y ago
  Shell code can run in a whole bunch of environments that even getting python into can be tricky. initramfs before your drives are mounted, for example... A lot of the discussion on here is mind-blowing, so many pushing to throw out perfectly good tech because it doesn't fit their (limited) worldview.
  - cma 9y ago
    Micropython can fit :P
    - tomc1985 9y ago
      Yeah but its another thing to bundle /bin/sh will always be there
davvolun 9y ago
The Python hate here is ridiculous. This is Google's [bash] style guide -- Google has chosen to use Python as their general purpose development language so "setting up environments" and pip, virtualenv, pyenv, pipenv all of that stuff is resolved through their standard processes. So, if you're not Google, then replace "Python" with "our organization's general purpose language", whether that's Ruby, C#, PHP or what-have-you. The statement is essentially, don't try to do everything in Bash, it's not well-suited for everything and whoever comes along next that has to deal with your 1000 lines bash script is going to want to kill you.
- endtime 9y ago
  Exhibit A: When I joined Google Fiber, one of my first projects was converting a (POSIX) shell script that had grown to 1200 lines to Python. It became something that anyone could modify, including interns, rather than something that required at least a code review from our L7 tech lead, whose time was better spent elsewhere (he was the author and our only competent shell programmer).
  - zippitydoodah68 9y ago
    That is mind blowing for me in a couple ways. * You have (at least) seven tiered support structures. * You have only one 'competent' shell programmer in your 'reachable' project scope. No wonder these types of language policies are in place.
    - fjsolwmv 9y ago
      It's been decades since "writing a 1000 line script" was best done in shell, if there ever was a time. Someone with that much experience ought to be a very senior engineer.
      - zippitydoodah68 9y ago
        I have shell libraries that generate code via here documents and other templating that are > 500 lines. That is about as far as I reasonably go. Note that these are function (and scope specific variables (with hopefully unique namespaces)) only code bases with copious comments and references to underlying tools.
curun1r 9y ago
I actually like python, the language. I think it balances the needs of a dynamic language well and I like that it is, at least, strongly typed. My hate is entirely directed at python, the environment and tooling around the language. Other languages have figured this stuff out and python just hasn't. And the horribly managed 2.x -> 3.x migration made things even worse. I get that it is enjoyable to program in and I think it makes a fine choice for instances where a whole team is bought into the decision to use it. But when it's used for things that are distributed to others or force other people who aren't experts in python to wade into the ugliness of the python ecosystem, that's what makes me hate it. I've had so many python-related problems with the aws command-line client alone, let alone all the other python I've been forced to run, that I never want to touch another product written in python again. To me, it's just an instance of developers prioritizing themselves over their users (hello electron devs).
- occams_chainsaw 9y ago
  There's a bit of bias in that you're most likely to really notice something's in Python when it breaks... And the AWS client is terrible itself. And then you have a lot of stuff like Deluge where you'd never notice it's in Python until you checked under the hood.
JdeBP 9y ago
> I think this due to the fact that it’s creators are very much of the old 1970s and 1980s Unix mindset The Bourne Again shell was created in 1989. That said, the 1980s Unix mindset was not what you clearly think it to be. It was full of Sun workstations, NextStep, Orthodox File Manager clones, Terminals with graphics, GNU Screen, Threaded ReadNews, ...
- no_wizard 9y ago
  Yes indeed, it sure was. I realize that. Don't forgot those awesome Amiga workstations https://en.wikipedia.org/wiki/Amiga#/media/File:Amiga500_system.jpg https://en.wikipedia.org/wiki/Amiga#/media/File:Amiga500_sys... Way ahead of their time, those guys. I don't think my point glosses over this at all though, in that the mindset back then derived from the pioneering work done at Xerox Labs & on original Unix. I know bash itself was not created as the first shell implementation, however its syntax is clearly heavily derived from the original Bourne shell and ascribed to its overall philosophy: do one thing, and do one thing well. Besides, at that time, you either dropped into Smalltalk or C if you needed to do more than text processing, which is what bash et. al. are still insanely good for.

pstuart 9y ago

I like bash, but I think I understand the hate -- it's the slippery slope of "gluing real applications" to "I can write this all in bash!". Just because you can, doesn't mean you should.

s3m4j 9y ago
If the application can be reduced to some form of simple piping of existing programs...
amptorn 9y ago
I enjoy the section of the Advanced Bash-Scripting Guide which explains how Bash has sparse arrays which "are useful in spreadsheet-processing software".[0] Because someone out there is apparently writing spreadsheet-processing software in Bash? [0] http://tldp.org/LDP/abs/html/arrays.html http://tldp.org/LDP/abs/html/arrays.html

kazinator 9y ago

> due to the fact that it’s [sic] creators are very much of the old 1970s and 1980s Unix mindset Firstly, Bash is relied upon to conform to a standard; it's not an exploratory project which expresses the maintainers' views about what a shell should look like. Secondly, Stallman didn't start Bash because he loved Unix. It was a pragmatic choice. Stallman really wanted a free platform based on Lisp. He went with cloning the Unix user space because that was becoming a dominant OS. It was proprietary software, and he wanted to replace that directly with workalike free software, rather than to provide incompatible free software and then have to evangelize not only freedom, but also a different platform at the same time. There were some technical reasons. Stallman rejected the idea of copying the Lisp Machine approach: https://www.gnu.org/gnu/rms-lisp.en.html https://www.gnu.org/gnu/rms-lisp.en.html At first, I thought of making a Lisp-based system, but I realized that wouldn't be a good idea technically. To have something like the Lisp machine system, you needed special purpose microcode. That's what made it possible to run programs as fast as other computers would run their programs and still get the benefit of typechecking. Without that, you would be reduced to something like the Lisp compilers for other machines. The programs would be faster, but unstable. Now that's okay if you're running one program on a timesharing system — if one program crashes, that's not a disaster, that's something your program occasionally does. But that didn't make it good for writing the operating system in, so I rejected the idea of making a system like the Lisp machine. I decided instead to make a Unix-like operating system that would have Lisp implementations to run as user programs. The kernel wouldn't be written in Lisp, but we'd have Lisp. https://www.gnu.org/gnu/thegnuproject.en.html https://www.gnu.org/gnu/thegnuproject.en.html For example, we developed the GNU C library because a Unix-like system needs a C library, BASH because a Unix-like system needs a shell, and GNU tar because a Unix-like system needs a tar program. The same is true for my own programs—the GNU C compiler, GNU Emacs, GDB and GNU Make.

no_wizard 9y ago
Yeah, when you dig down into the specifics I was not doing the history justice. My broader point was that it was definitely designed in a different era, with a different mindset, and has still managed to persist to this day, without that mindset shifting very much (usually for good reasons, or backward compatibility, which may or not be a good reason depending on specific circumstances) I often wonder if shell scripts would get such a bad wrap if all the backwards compatible code was strip out and only the latest standards were put in. I think thats where it gets people so very confused & it definitely feels awkward. I think its actually a perfectly fine language, syntactically speaking.

danmg 9y ago

Because python was the cool thing a few years ago, and it managed to get traction in a lot of places because it was pretty easy and included a lot of tools. It's also taught as an intro language now. So now you have to deal with people who are poopooing it because it doesn't have enough nerd cred like some like some other dynlang. Shell scripting has some other issues though. While most Bourne derived shells look similar, they have different extensions and capabilities. So only a subset of scripts will work everywhere.

Retra 9y ago

Just because all languages have flaws does not mean one language cannot be superior to another. Don't respond to one fallacy by employing another one.

yodsanklai 9y ago

> no single language is objectively superior to another I would say some languages are objectively superior to other for specific tasks. The problem is that very often the task to solve doesn't exactly fall within the realm of any given programming language and one has to make compromise. As for bash, I use it when I feel it's the best option, but I also think it's the worst programming language that I have to use. I wish there were better options. Are there any modern promising replacements for bash?

davvolun 9y ago
Yeah, trivially, a language like Brainfuck is clearly not a good choice for anything professional or maintainable; therefore, there must be some selection criteria that makes some languages objectively better than other languages. Whether PHP is a "bad" language or C# is better than Java is harder (and generally a waste of time -- pick something that works 95% of your use-case and figure out the other 5%), but refining the phrase to "no commercially used language is objectively superior to another" starts to make the statement useless to the point of irrelevance.
no_wizard 9y ago
Sure, I agree, for specific tasks. Just like a hammer is a better tool than a screw driver for putting nails in a block of wood. Thats my point. They're tools not lifestyle choices. Learn your tools, know your tools, don't be afraid of other people's tools. They all, usually, have some sort of value. I might as well note this too: I am speaking in broad strokes, you're going to be able to pinhole this as much as you want because of that. I'm simply suggesting that if your immediate reaction to how another organization uses these tools to replace A with B at a certain level is "this is clearly inferior" instead of "well, what can I learn from this" well, there's the problem. I used to think programmers/computer scientists where open minded people. Then I realized as a whole it tends to be we're only open minded if its within the domain we chose to be most active in Still far and away better than any other folks I've met, of course, but this is really a community culture problem, which is why I find it so counter productive. Alternatives to bash? Many do exist. zsh is bash compatible but does implement its own tools and subsets. If you're looking for something that removes the bash syntax there is powershell, which does run on Linux/macOS now as well: https://github.com/PowerShell/PowerShell https://github.com/PowerShell/PowerShell Then of course, there is oil shell: https://github.com/oilshell/oil https://github.com/oilshell/oil which is more like a subset of bash (and somewhat close to the idea of stripping away all the legacy stuff) Then there is xonsh: lets you use python as a basis for most everything http://xon.sh/ http://xon.sh/ The stalwart fish: https://fishshell.com/ https://fishshell.com/ fish shell has alot of niceties and a more object oriented syntax (kind of) and for the daring there is ergonomica: https://ergonomica.readthedocs.io/en/latest/ https://ergonomica.readthedocs.io/en/latest/ which has a lisp like syntax as does https://github.com/dundalek/closh https://github.com/dundalek/closh which uses clojure and its syntax and i'm sure there are more.

arca_vorago 9y ago

It's because so many here on hn are the compsci theoritical programmer, sysadmins are dying devops is everything, kind of people who don't actually support production systems other than maybe their particular depts single page webapp, etc... Hn has a problem with people living in the SV filter bubble seeing everything through that lens... in the real world, bash is still a king. When your devs shit out some bad code that causes your sysadmin to get a call at 3am... he's using bash to fix your fucking nodejs or whatever fadofthemoment bullshit you decided to run with. Of course entire applications generally shouldn't be in bash... it's like a kit of duct tape, epoxy, and rivets. Of course you should have made the product better, but when it does break, bash can keep it together until you get to the shop. I also think there is a certain amount of eliteism. It has such a low barrier to entry, it's like some people hate the idea of people being able to program without being programmers. I've heard it all so much here it just goes in one ear and out the other. /end bofh rant

IdiocyInAction 9y ago
Don't know if I would say that bash has a low barrier of entry. I find doing stuff in Python far more intuitive than in bash, it certainly has its quirks. I agree on the rest though.
tomc1985 9y ago
Shell code can run in a whole bunch of environments that even getting python into can be tricky. initramfs before your drives are mounted, for example... A lot of the discussion on here is mind-blowing, so many pushing to throw out perfectly good tech because it doesn't fit their (limited) worldview.
- cma 9y ago
  Micropython can fit :P
  - tomc1985 9y ago
    Yeah but its another thing to bundle /bin/sh will always be there

davvolun 9y ago

The Python hate here is ridiculous. This is Google's [bash] style guide -- Google has chosen to use Python as their general purpose development language so "setting up environments" and pip, virtualenv, pyenv, pipenv all of that stuff is resolved through their standard processes. So, if you're not Google, then replace "Python" with "our organization's general purpose language", whether that's Ruby, C#, PHP or what-have-you. The statement is essentially, don't try to do everything in Bash, it's not well-suited for everything and whoever comes along next that has to deal with your 1000 lines bash script is going to want to kill you.

endtime 9y ago
Exhibit A: When I joined Google Fiber, one of my first projects was converting a (POSIX) shell script that had grown to 1200 lines to Python. It became something that anyone could modify, including interns, rather than something that required at least a code review from our L7 tech lead, whose time was better spent elsewhere (he was the author and our only competent shell programmer).
- zippitydoodah68 9y ago
  That is mind blowing for me in a couple ways. * You have (at least) seven tiered support structures. * You have only one 'competent' shell programmer in your 'reachable' project scope. No wonder these types of language policies are in place.
  - fjsolwmv 9y ago
    It's been decades since "writing a 1000 line script" was best done in shell, if there ever was a time. Someone with that much experience ought to be a very senior engineer.
    - zippitydoodah68 9y ago
      I have shell libraries that generate code via here documents and other templating that are > 500 lines. That is about as far as I reasonably go. Note that these are function (and scope specific variables (with hopefully unique namespaces)) only code bases with copious comments and references to underlying tools.

curun1r 9y ago

I actually like python, the language. I think it balances the needs of a dynamic language well and I like that it is, at least, strongly typed. My hate is entirely directed at python, the environment and tooling around the language. Other languages have figured this stuff out and python just hasn't. And the horribly managed 2.x -> 3.x migration made things even worse. I get that it is enjoyable to program in and I think it makes a fine choice for instances where a whole team is bought into the decision to use it. But when it's used for things that are distributed to others or force other people who aren't experts in python to wade into the ugliness of the python ecosystem, that's what makes me hate it. I've had so many python-related problems with the aws command-line client alone, let alone all the other python I've been forced to run, that I never want to touch another product written in python again. To me, it's just an instance of developers prioritizing themselves over their users (hello electron devs).

occams_chainsaw 9y ago
There's a bit of bias in that you're most likely to really notice something's in Python when it breaks... And the AWS client is terrible itself. And then you have a lot of stuff like Deluge where you'd never notice it's in Python until you checked under the hood.

JdeBP 9y ago

> I think this due to the fact that it’s creators are very much of the old 1970s and 1980s Unix mindset The Bourne Again shell was created in 1989. That said, the 1980s Unix mindset was not what you clearly think it to be. It was full of Sun workstations, NextStep, Orthodox File Manager clones, Terminals with graphics, GNU Screen, Threaded ReadNews, ...

no_wizard 9y ago
Yes indeed, it sure was. I realize that. Don't forgot those awesome Amiga workstations https://en.wikipedia.org/wiki/Amiga#/media/File:Amiga500_system.jpg https://en.wikipedia.org/wiki/Amiga#/media/File:Amiga500_sys... Way ahead of their time, those guys. I don't think my point glosses over this at all though, in that the mindset back then derived from the pioneering work done at Xerox Labs & on original Unix. I know bash itself was not created as the first shell implementation, however its syntax is clearly heavily derived from the original Bourne shell and ascribed to its overall philosophy: do one thing, and do one thing well. Besides, at that time, you either dropped into Smalltalk or C if you needed to do more than text processing, which is what bash et. al. are still insanely good for.