It certainly isn’t a new idea to compile a language into an intermediate language. The original C++ compiler outputs C code, for example. Enhanced versions of Fortran were often just conversions of new syntax to old syntax. Of course, it makes sense to output to some language that can run on lots of different platforms. So, using that logic, Amber makes perfect sense. It targets — no kidding — bash. You write with nice modern syntax and compile-time checks. The output is a bash script. Admittedly, sometimes a hard-to-read bash script, but still.
If you want to see the source code, it is available on GitHub. Since Windows doesn’t really support bash — if you don’t count things like Cygwin and WSL — Amber only officially supports Linux and MacOS. In addition to compiling files, Amber can also execute scripts directly which can be useful for a quick one-liner. If you use Visual Studio Code, you can find a syntax highlighter extension for Amber.
To get a flavor of how it works, here’s a simple Amber file to rename some files:
let files = ["config.json", "file.txt", "audio.mp3"]
loop index, file in files {
$mv {file} {index}{file}$ failed {
echo "Failed to rename {file}"
}
}
Here’s the output shell script:
__AMBER_ARRAY_0=("config.json" "file.txt" "audio.mp3");
__0_files=("${__AMBER_ARRAY_0[@]}");
index=0;
for file in "${__0_files[@]}"
do
mv ${file} ${index}${file}
__AMBER_STATUS=$?;
if [ $__AMBER_STATUS != 0 ]; then
echo "Failed to rename ${file}"
fi
let index=${index}+1
done
Looks much easier. Still, bash isn’t that hard. If you must have bash scripts for some reason, this might be worth a look. As a general-purpose programming language, you should probably stick with something more traditional.
Catching errors early is a good thing, but there are other ways to do that. While you could probably use a debugger on the output bash code, it looks a bit hard to follow, so an Amber debugger would be welcome.
That simple example is not going to work if any of the filenames have spaces in.
Right out of their documentation. I didn’t look but the key would be if the bash is quoted not necessarily if it is quoted in Amber since I don’t think it has that notion. So even if that is true, the compiler could (and should) quote everything defensively, I would think.
It’s also using problematic single square testing. I get the feeling the author has never read the Advanced Bash Scripting Guide.
I once wrote a compiler which targeted GNU Make files. (Macro language, no shell callouts.) Working with a language which doesn’t have arithmetic was a challenge, but I got three-quarters of the way through a maths standard library before coming to my senses — addition, subtraction and multiplication. I did have enough to run Conway’s Game Of Life, very slowly.
http://cowlark.com/2013-10-19-insane-make/index.html
Oh, that is awesome! Although reading the makefile code feels a little like I’ve been staring at car crash longer than I should have been staring. :)
Does this need a certain version of GNU Make? It doesn’t work for me with v4.4.1:
$ make -f life.mk
Initialising. (Be patient…)
life.mk:630: *** empty variable name. Stop.
Yeah, I just tried it and noticed that. Clearly something’s broken over the years. I could fix it, but… then I’d have to touch it…
Admittedly I don’t do Win64 work often (usually open source), but feel a Windows install isn’t complete until Cygwin is install (but I am bias since that came from a former employer of mine).
Now, what about compiling Amber to BASH, then BASH to C, and C to a local (or cross-compiled) binary:
https://github.com/neurobin/shc
If compiling stuff to other languages looks like fun for you, then have a look at Ribbit: https://github.com/udem-dlteam/ribbit
This is clever, but it feels like you’d be better in almost every situation with a python script. And that’s coming from me who isn’t a fan of python.
I use Python a lot. In the Windoze world at work, I did remove all batch files from one of our systems and converted them to Python 3 (along with what was being called from the batch file like a VB script in Excel or Access). Only made sense. KISS principle. And very maintainable. That system is very reliable now, where before it needed a boot to the head every few days/weeks. Same with Linux. I use bash for simple one-liners like calling rsync multiple times to backup a few directories — say ‘rsync -av here there’. Anything more complicated and it gets a Python script, or to compiled language depending on the job at hand.
Now a days it really isn’t necessary to convert language to another language as you a have MANY languages already to handle the situation. If Python doesn’t work for situation, maybe Perl. Or go heavy with Java, or C/C++, C#, Pascal, Fortran/Cobol ;) , Rust, Ada, etc. …. Bash application programming should be retired to the dust bin of history and just used for very very ‘small’ scripts IMHO. It’s had it’s day in the sun… Time to sunset…. Python/Perl otherwise.
Anyone that recommends perl is part of the problem.
Exactly this. There isn’t much of a gap between a simple bash script and going the python way before it gets too complex. Requiring a build step also limits many use cases.
Nuthin’ new. We used a package for the S/370 that converted COBOL pseudocode into regular ANSI COBOL to let us concentrate in doing stuff instead of formatting I/O so we produced 5-10X more useful code.
Pity there wasn’t a similar tool for JCL. PITA is an understatement.
Takes me back to the time in the early 80’s when I needed to create a tool to allow users to operate a rather complex Watkins-Johnson radio measurement receiver. The said beast provided numerous combinations of LO frequency, pre-selector bandwidth , IF bandwidth and peak detector response time that would silently allow the user to take measurements outside the instrument’s calibration boundaries. The best solution seemed to be to write a simple GUI to run on a PDP11-23 and VT125 that monitored the user’s selected instrument settings and guided the user through the corresponding calibration limits.. The interface to the receiver was coded in assembler while Fortran was the “high level” language used for the GUI development due to a combination of available technology and parsimoniousness on the part of the company I was working for at that time.
For those of you that have not had the pleasure of coding in Fortran it’s an extremely inefficient language in terms of the number of keystrokes and care required in formatting for the actual amount of machine code produced. Only when I ran into yaml did I realize that it maybe Fortran wasn’t that bad – while yaml may not be that verbose the formatting is a real pain in the tail-end.
The solution was a terse meta-language that when input to two TECO editor macros fleshed out 95%+ compilable Fortran code.
Dude has no idea what he is doing, just have a look at the installation process, right from the website:
curl -s “https://raw.githubusercontent.com/Ph0enixKM/AmberNative/master/setup/install.sh” | $(echo /bin/bash)
its bot the curl | bash that’s bothering me here, but what’s that brother?
| $(echo /bin/bash)
btw, that used to be
sudo curl -s “https://raw.githubusercontent.com/Ph0enixKM/AmberNative/master/setup/install.sh” | $(echo /bin/bash)
a few days ago.
There is no clue how bash works :-D
If you want help with the output (bash code) then run it past an AI, I got good results running locally with the following command:
ollama run vanilj/llama-3-8b-instruct-coder-v2The prompt used was of the form “explain this Bash code and rewrite it but just adding informative comments to the code:…” Insert the code you need explained and enhanced with comments after the prompt. No make sure that the results make sense, don’t be a lazy boss and assume that your AI working isn’t on drugs and hallucinations as that is a risk with these systems.