- Amber, a programming language that compiles to BASH
- The slippery slope of in-product messaging
- Daylight Computer, an alternative to Kindle and iPad?
Shell scripting times a million
Amber is a new programming language that allows you to write code converted into BASH shell scripts. The language's syntax is a mix of JavaScript, Python, and something else (Kotlin? Rust?). The idea is to write in a language with a modern syntax, type-safety, and safety features.
One of those safety features forces you to write code to handle failures whenever you run a shell command.
The syntax also makes it more apparent that command failures are being handled:
let files = ["config.json", "file.txt", "audio.mp3"]
loop index, file in files {
$mv {file} {index}{file}$ failed {
echo "Failed to rename {file}"
}
}
If you're only occasionally writing shell scripts, Amber may not be a priority for you. In such cases, linting tools like ShellCheck could be more beneficial. However, if you find yourself frequently writing shell scripts, to the point where you're considering Python or Ruby for better re-usability, then Amber is definitely worth your attention.
In-app tour guides are marketing
It's an interesting take, though I can't entirely agree. In-product messaging helps guide users/customers through new product features, regardless of whether the new feature's user experience is well-designed.
In-product messaging is another marketing touchpoint that informs the customer about a feature that may not be part of their typical workflow. Not to mention, once a customer/user has seen them, they won't reappear. Think about it this way: from a B2B SaaS perspective, the customer gets an email about a new feature release, logs into the app, and sees a small notification icon or a banner on the page about the new feature release. They go to some other page and get invited to go through a tour of the feature. This kind of repetition is needed even for well-designed user experiences.
A tablet you might use every single day
The Daylight Computer is a mix between the Kindle and the iPad. The screen resembles the Kindle screen, and it has the form factor of an iPad, including a stylus. It is extremely interesting that the screen's refresh rate is much higher than the typical ebook reader. It's high enough to be a tablet.
The Daylight Computer, DC-1, runs Android, so you can run any Android tablet app on it with a kinder and gentler screen for the eyes.
Screen glare is not a problem with the DC-1.
I've bought a few tablets before and used them for reading, watching movies (and sometimes video games and coding). I use them once in a while. I also have a Kindle and use it every day.
It will be interesting to see whether the DC-1 lives up to the hype.
Top comments (3)
I looked at Amber for a few minutes and ran away! The generated code for the first example was almost unreadable with a strange sed invocation thrown in. And that's the example they chose!
The real problem with all preprocesors is that they generate less readable code than the source they start with and when there are any run time errors, they reference the generated code and that's what you have to debug. I'm old. I remember Ratfor. That had the same problems. A fancy preprocessor could embed a symbol table and line numbers in the generated code, but things like that really only make sense in compiled languages.
If Amber is so good (and I'm not judging it either way), they should make it a real interpreter or compiler, not a preprocessor. Or, how about a general shell based on Python? It's already an interpreted language with an interactive shell.
Real amber fossilized bugs, it didn't get rid of them. :)
Indeed; I've had that happen a few times as well with generated code. With Python or Ruby it's still shell commands at the end; with Amber it's generated output that's fit for a machine to execute but not fit for a human to read.
Based on the docs and code examples, it definitely feels like a hard sell and very experimental. Having a failure handler for commands, for example, could be added as part of a function wrapper whenever a shell command is called, whether in bash, zsh, or in Python or Ruby or other languages.
That would work with some problems:
It would add significant overhead for anything that needed to be somewhat fast (for a shell/interpreter anyway).
It would add some sort of shell level or nested process that would complicate some scripts,especially those that want to use job control to run things in the background...
It would probably make using the trap command to trap signals pretty convoluted if it worked at all.
All of this works nicely in an unimpeded shell/interpreter, so when an enhancement makes as many problems as it solves, it may not be worthwhile.
Where something like this may make sense is with preprocessors that compile Haskell into JavaScript or something similar, because the source language doesn't have robust runtime code of its own. IDK much about that, but the geniuses in the Cardano ecosystem do things like that.
Another use might be for AI agents which can use the representations to build better programs and still be smart enough to handle the mappings back to the source code.