"They despise your kind because you understand the machine, while they have to turn jungles into fuel and enslave thousands of computers just to pretend that the machine speaks to them too." -...
Heh fun, "ECMA Script-like syntax". It looks like typescript where the creators got scared of types and left it at the most basic ones :P. Honestly though, nodejs is my fallback scripting...
Heh fun, "ECMA Script-like syntax". It looks like typescript where the creators got scared of types and left it at the most basic ones :P.
Honestly though, nodejs is my fallback scripting environment as JavaScript is the language I am most comfortable writing in. Bash I can read, but is not something I use often enough to get muscle memory for. This might have gotten a lot of use from me a few years ago if it had been around.
At the moment I don't have much of a use for it, and it very much is still an alpha product. I also checked out the repo, and it looks like the last activity was three months ago. For a product still in alpha stage that isn't promising.
I have some other thoughts as well. Specifically about the ECMA "script-like" part. I guess "like" is doing a lot of heavy lifting here, someone familiar with JavaScript will trip over a lot of the differences when first using this:
Using echo instead of console.log.
Having a not keyword instead of using !
The way shell commands are executed doesn't resemble an ECMA api let stdtests = trust $ /usr/bin/ls "src/tests/stdlib/" $.
Functions are defined with fun name(args) instead of function name(args).
String interpolation is also different as it seems with Amber you can use {variable} in any string where with ECMA you can only do that with template literals and need a dollar sign ${variable}
No try catch blocks, instead it looks file there is a failed {} or trust{} thing going on.
Loop syntax is different.
And much more.
Honestly, I might be focussing on this too much. But they specifically mentioned it is like ECMA, but there are enough differences that I am not sure I agree entirely. Having said that, compared to bash, this would be a lot easier to pick up for someone coming from any high level language.
I am wondering how the bash output looks like. It would be nice if it compiles to a readable format and not some minimized spaghetti mess.
If this project is developed further it would also be interesting to see if they implement a bash to amber "decompiler".
Their example on the homepage didn't compile for me (type checker said no), but with a little tweak it did. The bash it produced looked more readable than I expected. Minification is a build...
Their example on the homepage didn't compile for me (type checker said no), but with a little tweak it did. The bash it produced looked more readable than I expected. Minification is a build option but it doesn't seem to change the output.
Source:
import { join } from "std/text"
fun get_weather(cities: [Text]): Null {
let temperatures = [Text]
for city in cities {
const result = $ curl -s "https://wttr.in/{city}?format=1" $ failed {
echo "Error: Failed to get weather for {city}"
continue
}
temperatures += [result]
}
//return temperatures
}
get_weather(["Mumbai", "Jakarta"])
Result:
get_weather__29_v0() {
local cities=("${!1}")
__AMBER_ARRAY_0=();
local temperatures=("${__AMBER_ARRAY_0[@]}")
for city in "${cities[@]}"; do
__AMBER_VAL_1=$( curl -s "https://wttr.in/${city}?format=1" );
__AS=$?;
if [ $__AS != 0 ]; then
echo "Error: Failed to get weather for ${city}"
continue
fi;
local result="${__AMBER_VAL_1}"
__AMBER_ARRAY_2=("${result}");
temperatures+=("${__AMBER_ARRAY_2[@]}")
done
# return temperatures
}
__AMBER_ARRAY_3=("Mumbai" "Jakarta");
get_weather__29_v0 __AMBER_ARRAY_3[@];
__AF_get_weather29_v0__17_1="$__AF_get_weather29_v0";
echo "$__AF_get_weather29_v0__17_1" > /dev/null 2>&1
"They despise your kind because you understand the machine, while they have to turn jungles into fuel and enslave thousands of computers just to pretend that the machine speaks to them too." - Wisdom of the Pentium-M Man
I will be taking the weekend off please inform my manager
Heh fun, "ECMA Script-like syntax". It looks like typescript where the creators got scared of types and left it at the most basic ones :P.
Honestly though, nodejs is my fallback scripting environment as JavaScript is the language I am most comfortable writing in. Bash I can read, but is not something I use often enough to get muscle memory for. This might have gotten a lot of use from me a few years ago if it had been around.
At the moment I don't have much of a use for it, and it very much is still an alpha product. I also checked out the repo, and it looks like the last activity was three months ago. For a product still in alpha stage that isn't promising.
I have some other thoughts as well. Specifically about the ECMA "script-like" part. I guess "like" is doing a lot of heavy lifting here, someone familiar with JavaScript will trip over a lot of the differences when first using this:
echoinstead ofconsole.log.notkeyword instead of using!let stdtests = trust $ /usr/bin/ls "src/tests/stdlib/" $.fun name(args)instead offunction name(args).{variable}in any string where with ECMA you can only do that with template literals and need a dollar sign${variable}failed {}ortrust{}thing going on.Honestly, I might be focussing on this too much. But they specifically mentioned it is like ECMA, but there are enough differences that I am not sure I agree entirely. Having said that, compared to bash, this would be a lot easier to pick up for someone coming from any high level language.
I am wondering how the bash output looks like. It would be nice if it compiles to a readable format and not some minimized spaghetti mess.
If this project is developed further it would also be interesting to see if they implement a bash to amber "decompiler".
Their example on the homepage didn't compile for me (type checker said no), but with a little tweak it did. The bash it produced looked more readable than I expected. Minification is a build option but it doesn't seem to change the output.
Source:
Result: