https://github.com/Ph0enixKM/Amber/blob/master/setup/install...
https://github.com/Ph0enixKM/Amber/blob/master/setup/uninsta...
The inconsistent indents and decorated variable names made them less readable than hand-written Bash scripts. I understand that most compiler outputs are not meant to be human readable, but generally we would get minification and/or obfuscation in exchange for losing readability, and Amber doesn't seem to offer those yet.
It's a bit of a stretch, but comparing it to something like MJML for HTML emails. [0] It doesn't make great HTML, but it's not unreadable and standard quality for HTML emails. It just handles all of the weird things you have to consider for maximum email client compatibility. It's basically a bunch of HTML macros, with react being an implementation detail under the hood. It's not like it's bringing any new features to HTML emails, because if it did, the output WOULD be unreadable.
If this was just some type hints, and cleaner syntax around sh, that I think would be really useful. This in it's current state is just sort of a tech debt generating machine. If something is built in amber, it's because we can only use bash for some reason, but if we can use bash we could either... use bash, or we could call something else (Ruby, Python, etc), from a 2 line bash script.
[0] https://mjml.io/try-it-live (click "View HTML" to see outputted source.)
Edit: Idea, it would be cool if you could define the environment available to the final script when using the compiler. That way, if there was something you wanted to distribute, the person building your project could say "this docker container I'm running this in won't have sed, but it will have bc and awk" or something.
I consider myself to be quite proficient in bash. I write a lot of bash professionally. I've written a compiler (transpiler?) for a strongly typed configuration language that outputs bash.
There are three main problems I see here.
(1) Pipelines, subshells, and external dependencies.
The example on the website compiles a conditional `if age < 18` into this monstrosity:
if [ $(echo ${__0_age} '<' 18 | bc -l | sed '/\./ s/\.\{0,1\}0\{1,\}$//') != 0 ]
if (( __0_age < 18 ))
Seems mildly insane that a conditional this simple would require a pipeline including `echo`, `bc`, and `sed`. Now the user needs to ensure the correct external CLI tools are installed, and match the expected versions. Hope they account for BSD vs. GNU variants. Eek.
(2) Namerefs.
> Arrays cannot be nested due to the Bash limitations
Arrays absolutely can be nested... with some trickery. Consider:
# Top level array w/ pointers to children.
declare -a arr1=( arr2 arr3 )
# Child arrays.
declare -a arr2=( item1 item2 )
declare -a arr3=( item3 item4 )
for ref in "${arr1[@]}" ; do
declare -n sub_array="$ref"
printf '%s\n' "${sub_array[@]}"
done
This is a fairly trivial operation that I'd assume the authors would know about. It's fast and allows for the creation of arbitrarily complex objects. Even rudimentary classes.
(3) Just learn bash.
I'm perpetually confused by people taking every opportunity to not just... learn bash. An otherwise skilled programmer will somehow forget everything they've learned when beginning a shell script.
Surely it can't be harder to learn the fundamentals of shell scripting than to learn whatever flavor-of-the-month alternative is?
Also: I don’t see mentioned how pipes affect the exit code propagation (i.e. pipefail).
I want to do more complex things using bash for devops stuff, because it's mostly working with other command line tools. You could directly use APIs and SDKs of cloud providers, but then things become an order of magnitude more complex than just writing the bash script.
However, when you do that you encounter bash's weaknesses, like not supporting a nested structure like Map<String, Map<String, Int>> and so on. Having to wrangle tools like jq, sed and awk all together to work around the lack of proper data structures and string manipulation is no fun either.
Something like amber could bridge the gap while still being portable across systems.
The thing I'm most proud of is the installation--you just put a single base64 encoded line at the top of your script, and everything works magically.
Maybe this is still early in development, but I don't see anything for pipes or redirection. Is this a planned feature? That's an essential feature of any shell and I can't see myself getting much done in Amber without it, especially pipes.
I suggest adding more examples to the home page, especially side by side comparisons with Bash. The home page is somewhat lacking in content right now.
Oils goal is that OSH is just a new Bash implementation (although not bug-for-bug) but with an upgrade-path to the more modern YSH for real programming with type safety etc, but still as a shell language. One of their exciting ideas is using code as data in a somewhat lisp-like manner to allow function introspection in YSH etc.
Based on other comments it seems like Oil Shell is much more principled in working to actually understand Bash as it exists and presenting an alternative language. I would be interested in what differentiates Amber and whether they have a response to Oils?
It's a shame that they provided such weird syntax for the most important thing you tend to do in a bash script, while providing fairly nice syntax for everything else.
Don't get me wrong, I hate writing shell scripts, so this is definitely an improvement over that. It just doesn't seem like the most practical solution (unless I'm missing something).
I'm having a hard time deciding why I would want this. It seems more likely to result in bugs than being a useful feature.
I've done a bunch of DSLs (CLI with some elaborate syntax really) that compile to bash as a target. It just works for me. Bash is always available; the constructs you can use are there (coreutils are mostly enough for the primitives and xargs for parallelization) It has been great so far for basic cases. Where things get complex (as other's have said) is handling failures, errors and intrinsic cases. That's when you're reminded why people didn't stuck with bash in the first place and we got other scripting languages.
https://amber-lang.com/pipelines/compile.svg
It also, hilariously, feels a bit fitting given my actual complaint ;P.
if [ $(echo ${__0_age} '<' 18 | bc -l | sed '/\./ s/\.\{0,1\}0\{1,\}$//') != 0 ];
if [ "${__0_age}" -lt 18 ]; thenThis feature, optional omission of delimiters in the special case of a single statement per branch, originated in early C and has since facilitated untold numbers of bugs, not least the spectacular Heartbleed bug (which has its own homepage, https://heartbleed.com).
e.g. https://github.com/amberframework/amber
https://ambermd.org/tutorials/
https://openjdk.org/projects/amber/
I'm probably grumpy, but I like unique names.
I'm unsure how to feel.
But I always feel that if you reach a certain complexity in your bash scripts, you should rather pivot to any other $lang.
Bash scripts should be simple glue between programs (unix-principle).
Notice that when executing a single expression, Amber automatically includes it's standard library for you.Maybe there are existing scripting langs that make this so? Ambers approach is not bad but I feel it could be even better.
I would prefer that it produces code with a bit more whitespace for readability.
Download(file.gz)
and that gets converted to either a wget or curl based on what the system has.
We got some great BASH alternatives: Zsh, Fish, Elvish, Nushell, Xonsh. I did not evaluate them all, but if Amber is even better, why not have Ambersh?
Can somebody please explain?
I don't get it. Asking not to be rude but to be educated.
I have WebGL disabled in my main browser for privacy reasons (super-easy to fingerprint), and I only get to see 'Application error: a client-side exception has occurred (see the browser console for more information).' with an error about ThreeJS initialization in the console.
I assume it's for the fancy animation, and I find that ridiculous. Loading a whole 3D library just to show a fancy animation. This could have been done much simpler by using an animated image format, though admittedly with less functionality - but is it even needed?
I fear the whole industry suffers from overengineering and this is just a symptom.
Even if you're convinced you need the fancy animation, why not gracefully fallback to not showing it and still make the docs usable?
That said, very interesting syntax. I agree with others about the $...$ being kind of odd, but other than that this is really cool.
Why would I ever use this instead of just using perl5, which solves all these problems already and is preinstalled on every Unix machine I've ever seen (and I've seen a lot from HPUX to AIX) since there's always some ancient innards component that depends on it, so it's basically impossible to remove...
And even if you don't know perl, you're better off learning it than Amber, because perl may not be super popular anymore but it's still way way bigger with way more resources and libraries and documentation and even people you could hire etc etc (If you prefer python2, you can probably get close to but not quite the same level of universal compatibility)
But imagine you need to deploy a server but for whatever reason you can't use Puppet, Ansible, or other configuration management tools. You need to write a deployment script using a "real" programming language.
How would you tackle the problem using Go, for example? Does anyone have examples of deployment or install scripts written in Go, Rust, or whatever else?
Thinking out loud I assume you would need a zypper (assuming openSUSE) package with Repository and Package structs and their methods, a secrets package to handle getting secrets from your secrets manager and setting them, and I'm drawing a blank on everything else.
As a system admin I picked up Go a few months ago to slowly reduce my Bash usage, but I still find myself using Bash whenever I have to write a install script because of how easy and fast it's to write compared to other languages.
Just built a CLI a couple days ago with golang and it was an incredible experience where these things have come.
Things - acute product dev tools. Tools to create peculiar or not soo common tools.
I also question the mindset that conflates programming with using a program. It seems until some philosopher explains the difference programming can't move forward.
Aside from that shell is the way many (most?) people interact with their computer, so some may find it offensive.
