Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Amber: Programming language compiled to Bash

amber-lang.com

Post reply on HN
Print view View original

201–210 of 330 posts

Re: Amber: Programming language compiled to Bash

#201

Post by galdosdi »

Cool idea. In practice: they already did this and it's called PERL!

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)

Re: Amber: Programming language compiled to Bash

#202

Post by kbp »

michaelmior wrote: post #134
mort96 wrote: post #61

Earlier quoted context omitted.

It's a common practice in Rust at least, where instead of having a mutable variable which you modify across several lines, you declare a new immutable variable with the same name on those lines. I like it, but I guess it really just comes down to preference and what you're used to.

I guess I haven't read enough Rust code to come across this patterns, but I don't think I particularly like it. Perhaps I would get used to it though :)

It works the same way in Haskell, eg

  main = do
    let x = 2
    let x = "foo"
    y
which is really the same as

  main =
    let x = 2
    in let x = "foo"
       in pure 3 >>= \y ->
                       pure "bar" >>= \y ->
                                        putStrLn $ x ++ y
So it works pretty naturally where each assignment is kind of like a new scope. If the type system is good, I don't think it really causes issues.

Re: Amber: Programming language compiled to Bash

#203

Post by Retr0id »

nerdponx wrote: post #194
Retr0id wrote: post #192

Bash is nice, but if we're going to all the effort of transpilation, I'd really like to see plain POSIX sh as the target

The generated code already looks kind of insane, I can imagine it would only be worse without the benefit of Bash features.

The alternative stance is that if it's already bad, can't hurt to make it worse ;)

Something you could do to alleviate this is to interleave comments with the original Amber source, along with line numbers (which would balloon the script size, but probably not a huge deal).

Edit: you could also bundle a tool to recover the original Amber source from those comments, to allow for easy in-the-field script edits and/or audits.

Re: Amber: Programming language compiled to Bash

#204

Post by nick238 »

sgarland wrote: post #198
nerdponx wrote: post #194

Earlier quoted context omitted.

The generated code already looks kind of insane, I can imagine it would only be worse without the benefit of Bash features.

THIS. Why does this: if age compile to this: __0_age=30; if [ $(echo ${__0_age} ' instead of this: __0_age=30; if [[ ${__0_age} -lt 18 ]]; then ... If you're going to compile to Bash, then use Bash-isms. EDIT: `-gt` is POSIX, but tbf if there's no input sanitization, then bash (or sh) will choke on the float. In that case, as long as you aren't trying to round, you could use parameter substitution to truncate: __0_ag…

So you want it to compile to POSIX sh but you're unhappy it doesn't use more POSIX-incompatible features? Maybe full POSIX sh compat is WIP, or in some simpler cases maybe it already is?

Re: Amber: Programming language compiled to Bash

#205

Post by partdavid »

carlinigraphy wrote: post #40

To my eye, this does not look good. 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 if [ $(echo ${__0_age} ' Pipelines and sub…

I've done (some? a lot?) of bash scripting and failing correctly in the absence of dependencies is really important. And once you've incorporated them you've destroyed what was good about targeting bash in the first place, because you're back to giving the user a configuration management problem, and if you were going to do them, you might as well have them install $better_language anyway.

Re: Amber: Programming language compiled to Bash

#206

Post by melodyogonna »

galdosdi wrote: post #201

Cool idea. In practice: they already did this and it's called PERL! 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…

I find all the "Why should I use this when X exist" nonsensical. If you can't see any use for it then it's not for you. There are a whole lot of people who will find this more attractive than Perl.

Re: Amber: Programming language compiled to Bash

#207

Post by ecef9-8c0f-4374 »

postalrat wrote: post #128
cess11 wrote: post #77

Earlier quoted context omitted.

I don't think it's incredibly unusual. On sensitive machines in corporate settings you commonly disable pretty much everything on every page that isn't in the 'trusted zone' or whatever. Personally, by default I shut down all the browser crap that might needlessly allocate RAM or allow memory leaks or slurp cycles without giving me some kind of value. I think this allows me to hold at least a few hundred extra tabs o…

If you mean block all network traffic that isn't in the trusted zone then sure. But disabling features you personally don't like isn't a good security practice.

Disabling features less attack surface

Re: Amber: Programming language compiled to Bash

#208

Post by rewgs »

okennedy wrote: post #114
bogwog wrote: post #110

This is interesting, but I don't see why I would use this instead of Python or Go? With those I'd get portability, modern features, etc but with the added bonus of a powerful standard library and ecosystem. 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).

Bash is ubiquitous and stable, making bash scripts incredibly portable. All of the other languages you bring up are great for authoring code, but have a non-zero amount of friction when running code in the wild. Python may be omnipresent, but you can rarely count on a specific version or the presence of specific libraries. Go requires compiling platform-specific binaries. Even JVM- or JS-based software requires insta…

But whenever people talk about writing Bash, you always have someone advocating that you should write POSIX sh instead if you want maximum portability. To paraphrase Qui-Gon Jinn, "there's always a more portable language."

Underlying all of these discussions is an attempt to reduce issues of portability to 0. It's a good goal, but IMO interpreted languages will by-definition never be the solution.

I've started reaching for Go in situations in which I'd usually reach for Bash or Python, and it's a godsend, because I can control for portability at compile time. If you make compiling for various GOOS and GOARCH targets the norm, portability is never an issue again.

Re: Amber: Programming language compiled to Bash

#209

Post by olejorgenb »

nick238 wrote: post #204
sgarland wrote: post #198

Earlier quoted context omitted.

THIS. Why does this: if age compile to this: __0_age=30; if [ $(echo ${__0_age} ' instead of this: __0_age=30; if [[ ${__0_age} -lt 18 ]]; then ... If you're going to compile to Bash, then use Bash-isms. EDIT: `-gt` is POSIX, but tbf if there's no input sanitization, then bash (or sh) will choke on the float. In that case, as long as you aren't trying to round, you could use parameter substitution to truncate: __0_ag…

So you want it to compile to POSIX sh but you're unhappy it doesn't use more POSIX-incompatible features? Maybe full POSIX sh compat is WIP, or in some simpler cases maybe it already is?

Retr0id, not sgarland want posix.

> Maybe full POSIX sh compat is WIP

Still - I sure hope it's possible to do a comparison in sh without spawning two processes.

Re: Amber: Programming language compiled to Bash

#210

Post by greggyb »

biggestlou wrote: post #163
LectronPusher wrote: post #151

I haven't seen a mention of the Oil Shell ( https://oilshell.org ) project's OSH/YSH yet and I'm quite surprised. 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 in…

Oil shell requires osh to run. That means that you can't run Oil scripts on systems that only have Bash installed.

Osh is stricter than bash. Anything written to osh should run in bash with no issues whatsoever.

Ysh implements new, non-compatible syntax and semantics.

Osh and ysh are two different shell languages from the Oils for UNIX project. The release build generates a single binary, oils-for-unix, and installation creates two symlinks for the two different shell personalities, similar to how the bash binary will behave in its POSIX-compliant mode when it is invoked as sh.

There is no "Oil shell" now, at least not without ambiguity.

Post reply on HN