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

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.

Micropython can fit :P

Yeah but its another thing to bundle

/bin/sh will always be there

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.

You make an awful lot of assumptions about population of the site where you can be practically anonymous to other users.

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.

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).

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.

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.

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.

The script in question was an interface for controlling WiFi (hostapd, wpa_supplicant) in a variety of ways, abstracting across different chipsets.

I don't know what you mean by seven tiered support structures. My tech lead was a Senior Staff Software Engineer, L7, level seven, etc. Just meant that he was a relatively senior guy (not that he didn't get his hands dirty, there were just better places for him to do so). There are lots of levels on Google's SWE job ladder.

And maintaining a 1200 line shell script that can brick hardware in people's homes and disable their WiFi (or internet access altogether) is something to be careful with. There were five or so SWEs doing wifi-related things for Fiber (including me and one other person new to the team), and yes, he was the only one of us who knew shell well enough to reliably catch mistakes. He was a few years older than the rest of us, maybe that's why.

I have a BS in CS from Georgetown and a MS in CS from Stanford. I don't think I ever had a class at either school that required me to write a single conditional statement or loop in shell. I probably never would have picked it up at Google either if I hadn't joined an embedded team.

You have deep technical ladders and they may make sense in a place like Google. Who knows. I've seen a couple young men I've mentored go to work at Google and don't hear anything negative from them.

Any code anywhere is worth being careful with and a shell script can be more dangerous than your average glue language (tcl,python,perl) script. I don't see why you need 1200 lines of shell script unless most of it is error handling and safe execution wrapping.

Funny, I've worked at Georgetown and my grandfather went to Stanford. I've written (over 20+ years) good and bad shell scripts. They get better the older I get and they also seem to be (mostly) less than 50 lines. I don't understand why people say these things about edu unless it's intended to awe the easily impressed. Smart is smart and well rounded is well rounded anywhere.

Sorry, I wasn't trying to show off. All I meant was that I had a pretty thorough mainstream CS education. If I didn't learn shell on the way then it's safe to assume most CS students these days don't either.

> 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

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

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.

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.

> 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?

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.

Try fish shell. Not too different but not as bad.

https://fishshell.com

And an effort to get rid of bash as Oil shell. (They really need a better name for Googleability.)

https://www.oilshell.org

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

Then of course, there is oil shell:

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/

The stalwart fish:

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/

which has a lisp like syntax

as does https://github.com/dundalek/closh which uses clojure and its syntax

and i'm sure there are more.

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).

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.

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.

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.

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

If the application can be reduced to some form of simple piping of existing programs...

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.

> 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, ...

Yes indeed, it sure was. I realize that. Don't forgot those awesome Amiga workstations

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.