Amber Documentation
docs.amber-lang.com
Documentation for Amber programming language

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

  • Victor@lemmy.world
    2·
    1 day ago

    I just installed fish shell a few years ago. Best scripting language I’ve come across. No need to remember all this weird bash syntax you have to look up every time you want to use it. All of fish shell fits in your working memory, seriously. It’s tiny.

      • Victor@lemmy.world
        2·
        1 day ago

        In which way is it weird? It’s different, but how is it weird?

        No need to apologize, you’re allowed your opinions and feelings.

        I would suggest reading the manual page for argparse thoroughly from top to bottom of you haven’t already. I struggled with argparse at first too, but it’s because I skimmed the manual instead of reading it.

        I would also read through all of the manual, and you’ll find useful idiomatic fish things like not setting PATH directly, but using fish_add_path, among other things. 👍

    • BB_C@programming.dev
      1·
      2 days ago

      They know you can just do if ((age < 18)) in bash, right?

      Or rather if ((10#$age < 18)) because age=021 would not be adult 😉 Hopefully, they protect against that at least.

      (I had to double-check this stupid default is still a thing, since I moved to zsh many years ago.)

    • Samueru_sama@programming.devEnglish
      1·
      2 days ago
      [ "$age" \< 18 ] && {
	echo "I'm not an adult yet"
} || {
	echo "I'm an adult"
}

      if you want to be using braces in if statements lol

  • Samueru_sama@programming.devEnglish
    3·
    2 days ago

    My most recent Bash mistake was misusing test -n and test -z. In Amber, I can just use something == “” or len(something) == 0

    test -n can be [ "$something" ] and test -z can be [ "$something" = "" ]

    And this applies to posix shell, not just bash.

  • IanTwenty@piefed.socialEnglish
    7·
    3 days ago

    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…

    • lens0021@programming.devOP
      3·
      2 days ago

      Yep, the code you provided is compiled into this:

      command_0="$(cat file.txt | grep "READY")"
__status=$?
if [ "${__status}" != 0 ]; then
    echo "Failed to read the file"
fi

      So, the outcome would depend on the pipefail option. (set -o pipefail)

      As you suggested, an Amberic snippet would be:

      import { file_read } from "std/fs"
import { match_regex } from "std/text"

const result = file_read("file.txt") failed {
    echo "Failed to read the file"
}
if match_regex(result, "READY"):
    echo "file.txt contains READY"
      • IanTwenty@piefed.socialEnglish
        2·
        2 days ago

        Thanks for that, makes sense. I like that Amber gives the ability to code more defensively/robustly where appropriate but can also get out the way if you just need to run a bunch of BASH raw.

  • gtrcoi@programming.dev
    3·
    3 days ago

    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?

    • lens0021@programming.devOP
      3·
      2 days ago

      Currently, Amber does not even support Bash 2 because Bash 2 does not support the += operator. (ticket) However, I believe that POSIX compliance is on Amber’s long-term milestone, and that it will eventually achieve this as its support range expands.

    • sga@piefed.socialEnglish
      3·
      2 days ago

      my guess is mostly lack of arrays in posix shell. there are other things as well, but arrays are really useful, especially when they are making other things easier to write. A stupid comparison i can think of is a compiled language targettng x86-64v2 or 3 instead of v1 because it has avx (i am not actually sure when avx was added, but imagine some instruction being added). without avx, your binary would be slower (in posix, for arrays, you essentially need to maintain a string and use awk/sed/cut to get particular elements, and many things would just not be possible). If they would target v1 (posix), it will run in more places, but it would be slower for a lot of people who have v2 or newer. And a lot of people have v2 or newer (bash).

    • Jakeroxs@sh.itjust.works
      2·
      3 days ago

      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?

      • gtrcoi@programming.dev
        4·
        2 days ago

        To add to the great response from @confusedpuppy@lemmy.dbzer0.com, amber would address one thing only: writing the syntax.

        Most people don’t need it, and even if they had it would break the compliance in other ways besides syntax, but I’m sure there are people out there that know what they are doing who would appreciate amber.

        Amber will still support bash stuff, or perhaps even other non-posix shells through the use of flags.

      • confusedpuppy@lemmy.dbzer0.com
        3·
        2 days ago

        I’ve been writing POSIX scripts as a sort of hobby and don’t really have any Bash experience but I think I can still give some insight. Hopefully what I say is accurate but this is what I’ve learned so far.

        POSIX is a standard, to say it as simple as possible, it sets the minimum requirements for environment, programs, commands and options for those commands with the purpose of having those commands be as portable as possible. That way a POSIX script will work on any POSIX compliant system. For example a POSIX script could work on Arch, Debian, on a Raspberry Pi or even Mac products. In theory if could work on windows too. If an Operating System ships with a POSIX compliant shell, you are very likely able to run a POSIX script.

        Bash is a shell but it has a bunch of features that expand beyond the basic features set by the POSIX standard. Bash also has more features and flexibility for scripting which is why it’s so common to see Bash scripts. Those scripting features are usually referred to as “bashisms.” Since it expands on POSIX scripting, it can look similar to a POSIX script but would not work as intended if you ran a Bash script outside of a Bash shell.

        With a lot of modern OS’s, they would likely have Bash installed and you most likely don’t need to worry about anything. However, Bash is not a standard and not required to be installed on every system.

        If you care about your script working on as many systems as possible without the worry about what shell is being used, you will probably prefer writing a sh shell, POSIX compliant script.

        Since POSIX shells and scripts work on a much more basic level, it can lack some depth and finding work arounds for issues can start to look unreadable/insane. A good example is how arrays are handled. POSIX is limited to one array where Bash has much better support for arrays.

        There are advantages to using either but with the popularity of Bash, it’s not really that big of a deal in the end.