4 ms·

Bash should be recognized as the tech equivalent of asbestos.

by seemslegit 7y ago

digitalsushi 7y ago
A fair analogy, given how much money I have made as someone who is willing to deal with metaphorical asbestos.
- akiselev 7y ago
  The question is, were you the one cleaning up the metaphorical asbestos or creating it? :) There's plenty of money to be made in both.
kohtatsu 7y ago
Y'all just have bias against the string system. Writing decent code in bash is just as possible as any other language. I stick to POSIX sh but same difference.
- unixhero 7y ago
  Why POSIX sh? Bash is everywhere. I once in my career had access to and needed jobs performed on a mainframe with AIX running. It had bash, it had ruby, it had day, it had fish shell. I couldn't and can't understand why people insist on asceticism (Korn shell, POSIX sh) when nicer options are available.
  - kohtatsu 7y ago
    Eh, I simply don't need bash. Every few dozen scripts or so I'll change the shebang to bash to have more than 1 array, but other than that I seldom pine anything that it has to offer. I believe it's a bloated mess along with most GNU utils, so avoiding it is partially out of spite, but I wouldn't impair my code to do so.
  - m4r35n357 7y ago
    dash is 10% of the size of bash. You don't need the interactive features when running shell scripts, and the few "extra" features are pretty crap anyway (arrays? yeah right).
  - unixhero 7y ago
    *zsh ... Not "day"
- BiteCode_dev 7y ago
  "Thirteen Incorrect Ways and Two Awkward Ways to Use Arrays" http://www.oilshell.org/blog/2016/11/06.html http://www.oilshell.org/blog/2016/11/06.html
  - kohtatsu 7y ago
    Yeah I should clarify; I think it's well past the time of sh. Still, sh is unrivaled for portability and brevity/velocity; I wouldn't swap virtually any the shell scripts I've written for python scripts. I think sh is a decent and often well-suited tool if you can manage to wield it properly (not a straightforward endeavor). I look forward to checking out oilshell though, so thank you~ Edit: FWIW for arrays in POSIX sh I generally only use: set -- a b c echo $# echo "$1" shift echo "$@" Once in a blue moon "$*" or maybe an unquoted $@. See 2.5.2 of https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V... (My go-to reference)
montroser 7y ago
In config management, I often think to myself as I'm trying to figure out how to express in the DSL some simple thing, that I'd rather just write the bash. Why should I learn each new fashionable DSL just to have it translate back to the shell commands I spent so long translating into the DSL? It's a game of telephone. This is a cool/fun project, but I've got to say, if I'm troubleshooting a production issue I'd so rather be dealing with the (shorter) generated bash equivalent than the bashable DSL in the example they have there.
- wwright 7y ago
  My answer: so that other people can actually work with the scripts you write. Some DSLs are definitely a waste of time (hello Jenkins!), but in the anecdotal experience of myself and literally everyone I’ve talked to, Ansible is massively easier to learn than Bash. I’ve had junior devs (who don’t even know Python!) writing and maintaining useful tasks within minutes, and that’s not even an exaggeration. Shell scripts, IME, work great until you need a certain amount of logic, and then they become a collapsing Death Star of edge cases and tribal-knowledge pitfalls.
StreamBright 7y ago
Not only Bash but everything that is not compiled. The amount of grief interpreted languages introduced is outrageous.
- CraneWorm 7y ago
  Compilation does not guarantee neither readability nor ease of maintenance. Interpreted languages typically give you a very quick feedback loop; they're great fit with scripts and utilities that you won't ever write UT for.
  - StreamBright 7y ago
    And I did not claim any of those. Btw. a typical feedback loop for many of the compiled languages is 100ms (for example ReasonML). My main problem with interpreted languages is the duality of their implementation. Especially Python suffers from this, the high-performance part of the language is in C, C++, Fortran. When you install a package you get all of the problems of those languages on the top the Python problems (versions, environments, installed libraries, etc.). What I would like to have is the Rust way, compile the code on any platform and target any other platform, configuring even the libc that you want to use. OcaML also works very nicely, compiling the code to native or byte code. I think the detour to interpreted languages set us back in the long run.
- bschwindHN 7y ago
  > everything that is not compiled. Agreed. I see fixes like this in bashible that would have never happened in a compiled language with static types: https://github.com/mig1984/bashible/commit/63fcc766d0244a6fb965ca8433321e7259bbb62e https://github.com/mig1984/bashible/commit/63fcc766d0244a6fb...
m_mueller 7y ago
if Bash is asbestos, what are Windows Batch-scripts?
- seemslegit 7y ago
  Dry mud

Bash should be recognized as the tech equivalent of asbestos.

digitalsushi 7y ago

A fair analogy, given how much money I have made as someone who is willing to deal with metaphorical asbestos.

akiselev 7y ago
The question is, were you the one cleaning up the metaphorical asbestos or creating it? :) There's plenty of money to be made in both.

kohtatsu 7y ago

Y'all just have bias against the string system. Writing decent code in bash is just as possible as any other language. I stick to POSIX sh but same difference.

unixhero 7y ago
Why POSIX sh? Bash is everywhere. I once in my career had access to and needed jobs performed on a mainframe with AIX running. It had bash, it had ruby, it had day, it had fish shell. I couldn't and can't understand why people insist on asceticism (Korn shell, POSIX sh) when nicer options are available.
- kohtatsu 7y ago
  Eh, I simply don't need bash. Every few dozen scripts or so I'll change the shebang to bash to have more than 1 array, but other than that I seldom pine anything that it has to offer. I believe it's a bloated mess along with most GNU utils, so avoiding it is partially out of spite, but I wouldn't impair my code to do so.
- m4r35n357 7y ago
  dash is 10% of the size of bash. You don't need the interactive features when running shell scripts, and the few "extra" features are pretty crap anyway (arrays? yeah right).
- unixhero 7y ago
  *zsh ... Not "day"
BiteCode_dev 7y ago
"Thirteen Incorrect Ways and Two Awkward Ways to Use Arrays" http://www.oilshell.org/blog/2016/11/06.html http://www.oilshell.org/blog/2016/11/06.html
- kohtatsu 7y ago
  Yeah I should clarify; I think it's well past the time of sh. Still, sh is unrivaled for portability and brevity/velocity; I wouldn't swap virtually any the shell scripts I've written for python scripts. I think sh is a decent and often well-suited tool if you can manage to wield it properly (not a straightforward endeavor). I look forward to checking out oilshell though, so thank you~ Edit: FWIW for arrays in POSIX sh I generally only use: set -- a b c echo $# echo "$1" shift echo "$@" Once in a blue moon "$*" or maybe an unquoted $@. See 2.5.2 of https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V... (My go-to reference)

montroser 7y ago

In config management, I often think to myself as I'm trying to figure out how to express in the DSL some simple thing, that I'd rather just write the bash. Why should I learn each new fashionable DSL just to have it translate back to the shell commands I spent so long translating into the DSL? It's a game of telephone. This is a cool/fun project, but I've got to say, if I'm troubleshooting a production issue I'd so rather be dealing with the (shorter) generated bash equivalent than the bashable DSL in the example they have there.

wwright 7y ago
My answer: so that other people can actually work with the scripts you write. Some DSLs are definitely a waste of time (hello Jenkins!), but in the anecdotal experience of myself and literally everyone I’ve talked to, Ansible is massively easier to learn than Bash. I’ve had junior devs (who don’t even know Python!) writing and maintaining useful tasks within minutes, and that’s not even an exaggeration. Shell scripts, IME, work great until you need a certain amount of logic, and then they become a collapsing Death Star of edge cases and tribal-knowledge pitfalls.

StreamBright 7y ago

Not only Bash but everything that is not compiled. The amount of grief interpreted languages introduced is outrageous.

CraneWorm 7y ago
Compilation does not guarantee neither readability nor ease of maintenance. Interpreted languages typically give you a very quick feedback loop; they're great fit with scripts and utilities that you won't ever write UT for.
- StreamBright 7y ago
  And I did not claim any of those. Btw. a typical feedback loop for many of the compiled languages is 100ms (for example ReasonML). My main problem with interpreted languages is the duality of their implementation. Especially Python suffers from this, the high-performance part of the language is in C, C++, Fortran. When you install a package you get all of the problems of those languages on the top the Python problems (versions, environments, installed libraries, etc.). What I would like to have is the Rust way, compile the code on any platform and target any other platform, configuring even the libc that you want to use. OcaML also works very nicely, compiling the code to native or byte code. I think the detour to interpreted languages set us back in the long run.
bschwindHN 7y ago
> everything that is not compiled. Agreed. I see fixes like this in bashible that would have never happened in a compiled language with static types: https://github.com/mig1984/bashible/commit/63fcc766d0244a6fb965ca8433321e7259bbb62e https://github.com/mig1984/bashible/commit/63fcc766d0244a6fb...

m_mueller 7y ago

if Bash is asbestos, what are Windows Batch-scripts?

seemslegit 7y ago
Dry mud