My primary use case for Amber is when I need to write a Bash script but don’t remember the silly syntax. My most recent Bash mistake was misusing test -n and test -z. In Amber, I can just use something == "" or len(something) == 0
I get why this is useful, and it’s useful for me as well, but the perfectionist in me asks why target bash instead of posix?
As someone who knows nothing about POSIX, what’s the difference or in your opinion what would make it specifically better with the context of amber?
This is an interesting idea and from the looks of it well executed, but I am having trouble imagining a scenario were I would prefer to use Amber over a scripting language like Python. If your bash scripts are getting long enough to warrant the use of Amber you are probably already in a situation where you can justify installing Python.
If your program relies too many external tools then I think it makes more sense to use bash than abuse os.system
I agree, but I can envision scenarios where you are integrating into someone else’s workflow/machine and they (or their build system etc.) are expecting a shell script. Python is ubiquitous but sometimes you just want to work like everything else.
One reason is that Python is not built-in on macOS anymore, so it’s hard to justify using it for management scripts. Particularly when you do not have control of the execution environment to begin with. I’ve written some obnoxiously complicated bash (or zsh) scripts because I want to make sure it will run on a vanilla Mac with no additional dependencies. 10 years ago I would’ve done all that stuff in Python, but not anymore. Thanks, Apple!
From a technical perspective, sure, I could push out a portable python environment and it wouldn’t affect the rest of the system. But that comes at a cost. I don’t want to fight for it, and I don’t want to be responsible for maintaining it. It’s easier to just use bash/zsh.
Python is also too heavy for some embedded devices. Not sure if I can count on Amber scripts to run in a busybox environment but maybe?
That said, if the question is “is it worth learning a whole new thing when I already know bash/zsh”, I am not so sure. But in principle, I dig it, regardless of how practical it is with my specific background and needs. I mean, if I learned about this 20 years ago I feel like I might still be reaping rewards.
Nice. I find the bash syntax so clunky…
I didnt realize it could go to different bash versions.
That could actually be really handy for me, write once and out for the versions I need…
When do you need a newer or older version of Bash to target? I mean usually this is not a thing to concern about.
Client systems outside of my control.
It is not usually a thing to be concerned about. It is something I end up having to be concerned about though.
You have my deepest condolences.
Its an interesting life I suppose.
I don’t like it.
Interesting. There is this example in the docs:
let result = $ cat file.txt | grep "READY" $ failed { echo "Failed to read the file" }https://docs.amber-lang.com/basic_syntax/commands
How can we know for sure what failed here? Was it the cat or the grep? My instinct says the pipe returns the code of the last cmd or failure, which could be either.
Perhaps it’s just a contrived example and it would be better to separate testing file existence from grepping in real code…
