> shell scripts are the wrong solution for anything over ~50 lines of code.
I don't think LOC is the correct criterion.
I do solve many problems with bash and I enjoy the simplicity of shell coding. I even have long bash scripts. But I do agree that shell scripting is the right solution only if
= you can solve the problem quickly
= you don't need data structures
= you don't need math
= you don't need concurrency
In my opinion, shell scripting is the right tool when you need to do a lot of calling programs, piping, and redirecting. Such programs end up being cumbersome in "proper" languages.
If there are already software written to do the stuff and I'm just coordinating them (no other computation other than string manipulation) I'd take bash every day. I would only reach to python if I need to do stuff like manipulating complex data structures or something with heavy logic.
~1k lines of bash with recutils for data persistency and dc for simple math. Was not quick to solve for me, custom invoices .fodt to .pdf to email, but I got it done. Shell is the only other scripting language I am familiar with other than Ruby. And I am worse at Ruby.
Sometimes options are limited to what you know already.
You mean, the complexity of shell coding? Any operation that in a regular language is like foo.method(arg) in shell expands into something like ${foo#/&$arg#%} or `tool1 \`tool2 "${foo}"\` bar | xargs -0 baz`.
My comment was more about basic string/number ops implemented as cryptic incantations, not functions per se. I regularly write bash. Simple things like trimming, deleting suffix, removing quotes, taking a substring, etc always look like someone is cursing in the code. I can’t remember this afterthought gibberish no matter how many times I write it, so I have to maintain few pages of bash snippets in my obtf.
Be damned the day I decided to write a set of scripts in it rather than looking for a way to make typescript my daily driver, like it is now. Bash “code” “base” is one of the worst programming jokes.
some data structures, math, and some concurrency are just fine in shell scripts. bash has arrays so you can do pretty elaborate data structures. where it falls down is being bug-prone. but some code is useful even if it's buggy
That’s a testament to your distribution/package manager’s stability, not to the language itself. I happen to write my scripts in Elixir (which is as fast-moving as Python 3), using a pinned version of it in a Nix flake at the root of my `~/bin` directory. Scripts from 5 years ago are still as reproducible as today’s.
Unless you have pinned the exact version numbers in requirements.txt (which you should) or kept you conda/venv..etc around it might be hard. I know at this stage this would be too much compared to what we are talking about regarding python scripts but non-python dependencies are real painful.
I know that this is probably beyond bash scripting vs python scripting but I was just replying to how 6 months project can have problems.
Also not a 6 months scale but the python standard library definitely changes and I would take bash anytime if I have to use venv for running util scripts.
Edit: When python3.8 removed 'time.clock()' it was annoying to change that. I know that it was deprecated since 3.3 (as I remember) but this is the example I have in mind now. But probably it was before I was born that people using
start=$(date +%s%N)
end=$(date +%s%N)
And I will be dead before/if this becomes impossible to use.
I agree with the general idea, but
1) LOC is not a good metric
2) I would immediately take off the list Python and Typescript, and anything what is compiled, leaving the list much shorter
TypeScript is good for this kind of a thing if you're only running it on your own machines and don't have to mess around with environments all the time. You can also run it with ts-node.
Use a better programming language. Go, Typescript, Rust, Python, and even Perl come to mind.