This looks great. We have a lot of bash tools because it's the only stable interpreter that we have readily available on all our systems. But bash is a pain to write so this might actually make things easier.
Bash is great for orchestrating other Unix tools into an automated workflow. Only when that workflow requires stuff that Bash doesn't have is it time to break out Python. Integrate Shellcheck into your editor, and you get automated help for writing more reliable Bash.
Thank you, but... why not just write in Bash, or the shell you prefer? Why learn a yet another opinionated wrapper?
Yes, Bash or any shell is a very complex and utterly environment dependent language to approach with all due care for security and compatibility, yet hence the lack of wrapper that may not even be aware of these crucial cases at all.
There are other communities where movement in the language came from outside tooling that built extensions on top of the language, such as Sass or TypeScript.
It always comes to be a social problem. Sort of. I want to use X instead of Y, but maybe everyone does not want the same, or adaption of X is harder in technology wise. So I use wrapper Z that compiles to Y, and avoid some problems, but bring new problems. Maybe these problems are smaller ones than just keeping to use Y directly.
bash is really painful to use for anything beyond the most rudimentary logic. Bourne and Mashey were terrible language designers. (By contrast, Thompson's V6 shell is very elegant, if limited.)
That said, this should just be a shell itself and not something that generates into other shell dialects. Otherwise, why not use Ruby or something like it that has actual expressive power?
> That said, this should just be a shell itself and not something that generates into other shell dialects. Otherwise, why not use Ruby or something like it that has actual expressive power?
I'm guessing the advantage here would be that the compiled "bytecode" (the resulting bash) can be distributed to systems that would then not need to have Amber installed. (And vs. a real binary from, e.g., Go/Rust/etc., it isn't tied to the platform, either.)
Vs. a Ruby script would require Ruby as a run-time dependency; Amber here is effectively a compile-time dependency.
Python 3 is available basically everywhere these days though, so I think there's still a lot of merit to just using a higher level language like you suggest. Even Ruby, while not available out of the box, is not exactly hard to get on most OSes.
Literally the worst of both worlds.
On the other hand, we're at a point for a binary language (or standard / framework) that one AI/LLM creates and another one validates.
What are we missing?
If your script is complex enough to need a higher level language you might as well just switch to python
Yes, Bash or any shell is a very complex and utterly environment dependent language to approach with all due care for security and compatibility, yet hence the lack of wrapper that may not even be aware of these crucial cases at all.
There are other communities where movement in the language came from outside tooling that built extensions on top of the language, such as Sass or TypeScript.
That said, this should just be a shell itself and not something that generates into other shell dialects. Otherwise, why not use Ruby or something like it that has actual expressive power?
I'm guessing the advantage here would be that the compiled "bytecode" (the resulting bash) can be distributed to systems that would then not need to have Amber installed. (And vs. a real binary from, e.g., Go/Rust/etc., it isn't tied to the platform, either.)
Vs. a Ruby script would require Ruby as a run-time dependency; Amber here is effectively a compile-time dependency.
Python 3 is available basically everywhere these days though, so I think there's still a lot of merit to just using a higher level language like you suggest. Even Ruby, while not available out of the box, is not exactly hard to get on most OSes.