3 ms·

I'm writing a ticketing manager for the terminal entirely in bash. Reasonably non-trivial project, and it's been pretty enjoyable working "exclusively" with bas

I'm writing a ticketing manager for the terminal entirely in bash. Reasonably non-trivial project, and it's been pretty enjoyable working "exclusively" with bash. ("exclusively" here used in quotes, because the whole point of a shell scripting language is to act as a glue between smaller programs or core utilities in the first place, which obviously may well have been written in other languages. but you get the point). Having said that, if I were to start experimenting with an altogether different shell, I would be very tempted to try jshell! Incidentally, I hate when projects say stuff like "Oils is our upgrade path from bash to a better language and runtime". Whether a change of this kind is an "upgrade" is completely subjective, and the wording is unnecessarily haughty / dismissive. And very often you realise that projects who say that kind of thing are basically just using the underlying tech wrongly, and trying to reinvent the wheel. Honestly, I've almost developed a knee reflex to seeing the words "upgrade" and "better" in this kind of context by now. Oils may be a cool project but that description is not making me want to find out more about it.

bbkane 2y ago
Man if you think Bash doesn't need an upgrade, more power to you, but every time I use it for anything slightly complicated I regret it, so I'm firmly in the "dear Lord, let's find a smooth upgrade from Bash" camp and I'm excited about Oils
- tpoacher 2y ago
  Well I didn't necessarily mean that Bash is perfect and could never be improved; or that Oils may not have good ideas that are an 'improvement' over some things in bash. I meant that, if I come up with a project called "Spills: an improved Oils without all the awful warts", this says nothing good or meaningful about my project itself, and all it really does is make a casual implication that Oils is crap. So such a sentence would (personally) put me off Spills, rather than get me excited about it. Especially if I was already happy with Oils and in fact found it enjoyable, and certainly not having "awful warts". Yes you can go 'delve' into the project to figure out if and why Spills is actually better than Oils (and if and why Oils is 'crap' according to your tagline), but a tagline is chosen for a reason. It's a single sentence you use to describe and sell your project with. If your best tagline is "that other product is crap" then I'm not that interested to do any 'delving' in the first place. That was my point. Also, I think partly the reason bash gets a bad rep is because it's a scripting language, and the canonical one for that matter. A lot of the time people get frustrated with bash, I find it's because they're trying to use it as a 'system' language and get everything done via bash. But you're not supposed to. It's a scripting language, it's intended as 'glue'. Where system languages rely on external libraries, bash relies on external programs. You want to validate your inputs? Use a validator program. You want to operate on specific types? Use a type-specific program. If you need type-specific validation and you're doing it in bash, then of course you're going to get frustrated; it probably can be done, and possibly even well, but the language was just never designed for that kind of thing and you'd have to get knee-deep into arcane hackery rather than have lovely clean maintainable code.
  - bbkane 2y ago
    I respect that, and if I was happier with Bash I would probably agree with you :)

bbkane 2y ago

Man if you think Bash doesn't need an upgrade, more power to you, but every time I use it for anything slightly complicated I regret it, so I'm firmly in the "dear Lord, let's find a smooth upgrade from Bash" camp and I'm excited about Oils

tpoacher 2y ago
Well I didn't necessarily mean that Bash is perfect and could never be improved; or that Oils may not have good ideas that are an 'improvement' over some things in bash. I meant that, if I come up with a project called "Spills: an improved Oils without all the awful warts", this says nothing good or meaningful about my project itself, and all it really does is make a casual implication that Oils is crap. So such a sentence would (personally) put me off Spills, rather than get me excited about it. Especially if I was already happy with Oils and in fact found it enjoyable, and certainly not having "awful warts". Yes you can go 'delve' into the project to figure out if and why Spills is actually better than Oils (and if and why Oils is 'crap' according to your tagline), but a tagline is chosen for a reason. It's a single sentence you use to describe and sell your project with. If your best tagline is "that other product is crap" then I'm not that interested to do any 'delving' in the first place. That was my point. Also, I think partly the reason bash gets a bad rep is because it's a scripting language, and the canonical one for that matter. A lot of the time people get frustrated with bash, I find it's because they're trying to use it as a 'system' language and get everything done via bash. But you're not supposed to. It's a scripting language, it's intended as 'glue'. Where system languages rely on external libraries, bash relies on external programs. You want to validate your inputs? Use a validator program. You want to operate on specific types? Use a type-specific program. If you need type-specific validation and you're doing it in bash, then of course you're going to get frustrated; it probably can be done, and possibly even well, but the language was just never designed for that kind of thing and you'd have to get knee-deep into arcane hackery rather than have lovely clean maintainable code.
- bbkane 2y ago
  I respect that, and if I was happier with Bash I would probably agree with you :)