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

311–320 of 330 posts

Re: Amber: Programming language compiled to Bash

#311

Post by DemocracyFTW2 »

> In Amber, there is a rule that allows you to use a : symbol where you intend to write only one statement, wherever you can write a block of code. This can be handy when you want to perform multiple conditions with a single statement each.

This feature, optional omission of delimiters in the special case of a single statement per branch, originated in early C and has since facilitated untold numbers of bugs, not least the spectacular Heartbleed bug (which has its own homepage, https://heartbleed.com).

Re: Amber: Programming language compiled to Bash

#313

Post by hnlmorg »

nucleardog wrote: post #307
jonathankoren wrote: post #294

Earlier quoted context omitted.

Yeah. Sh needs to be abandoned. There's a million better alternatives, including those without such an asinine syntax.

If I’m going to install a tool to run my code, why would I pick any of these alternatives instead of going straight to a “real” programming language? Most of the value in sh to me is that it’s ubiquitous. I write a script and the runtime is already available across most devices, operating systems, containers, and everywhere else without an extra steps.

Because a shell is also REPL for interacting with command line utilities. It solves a different problem to “real programming languages”.

Re: Amber: Programming language compiled to Bash

#314

Post by hnlmorg »

KerrAvon wrote: post #278
lytedev wrote: post #257

Earlier quoted context omitted.

I'm guessing because Bash is "more everywhere" than Python.

As slow as Python is, though, Bash is more slow. Much more slow.

It’s actually fork() that’s slow, rather than Bash itself.

If you were to write Python code that did a of its business logic by spawning new processes rather than using its core libraries (which are written in C) then you’d find Python would be just as slow too.

But the exact point of Bash and other shells is to make launching new processes easy. This is the point that people miss when they say “write it in a real programming language”. Shells solve an entirely different problem to other languages. And “real” programming languages suck at working with other executables in a quick and convenient way.

Re: Amber: Programming language compiled to Bash

#315

Post by fluidcruft »

zem wrote: post #298
fluidcruft wrote: post #156

Earlier quoted context omitted.

I sort of see that, but at the same time why not just compile to python instead? I get that python can be less convenient syntactically for "scripting" type things, but if you're writing in what's effectively a DSL that gets transpiled for a different interpreter anyway...

i guess the idea is that you can scp the output script to a machine that has only a minimal *nix install and run it there without having to install anything more. so bash, bc and sed but not python or ruby

That's an argument for POSIX sh, not bash.

Re: Amber: Programming language compiled to Bash

#316

Post by deaddodo »

xnickb wrote: post #118
deaddodo wrote: post #108

Earlier quoted context omitted.

You know that your shell environment is not forced on you, right? You can just switch to ZSH, fish, etc. The only time this complaint is valid is if you're in a professional environment and you're not allowed to use alternate shells in your account, for some reason.

> The only time this complaint is valid I've dealt with bash scripts running in high load production systems and I'm very happy I don't have to any more. There is a reason my comment was a response and not a standalone statement. The OP was explicitly speaking about using it a professional setting.

> The OP was explicitly speaking about using it a professional setting.

Note the little asterisk at the end there?

I've worked as a systems administrator/engineer and a DevOps Engineer at quite a few companies. Very few of them cared what shell your personal account used (and usually had zsh, if not also fish). And they wouldn't run shell scripts in production; but if they did allow that, they probably wouldn't care which one you included in your shebang (as long as the package was in our standard deploy set).

Obviously that doesn't represent all places, thus why I added the caveat. However, the number of places that A) allow you to run shell scripts in production and B) are also so overly paranoid as to limit user account shell interface are probably the exception, not the rule.

Re: Amber: Programming language compiled to Bash

#317

Post by pasc1878 »

0x457 wrote: post #263
pasc1878 wrote: post #78

Earlier quoted context omitted.

No as I really don't understand that - beer costs money.

It's a difference between the freedom to say "I want a beer" and a free beer given to you. That it means it's free in a monetary sense.

That is the nearest to an explanation in all the answers ie saying "Beer is NOT free' all the others still confuse me as I read its literally. and 'Free as in beer' makes no sense so the whole thing just does not compute.

I do understand what GPL does and the reasons for this just not this slogan.

Re: Amber: Programming language compiled to Bash

#318

Post by chme »

chme wrote: post #270
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

It isn't even pure bash, if it uses external commands like `bc` and `sed`. It should probably limit itself to posix shell (or bash, if they need to) and coreutils. They are only listing `bc` and `bash` as a prerequisite, but the example uses `sed`, so this is also not complete. So a full list of all required tools would be the first step. But I am working on embedded systems where I write lots of POSIX shell scripts…

I tested this a bit now, because I was curios, so it also requires `sudo` for the installation, installing it as `root` or as user with write permissions to `/opt` will not work and causes the misleading error:

    Please make sure that your user can access /opt/amber directory.
Creating this directory, either manually or by the script before it fails to download amber, will cause the installer script think that amber is already installed. So not a very high quality shell installer script for a tool that generates shell scripts.

Re: Amber: Programming language compiled to Bash

#319

Post by chme »

sgarland wrote: post #283
jimrandomh wrote: post #277

Earlier quoted context omitted.

There might be reasons to use `bc` like this if you don't know the type of `age` and it could be a non-numeric string. Buuuuut a programming language where a simple integer-comparison leads to two subprocesses is going to be slower than the slowest existing programming languages, by orders of magnitude.

Am I missing something, like `bc` can parse `one + two`? Input sanitizing should be done before trying to hand inputs over to be summed.

The amber source of that is [here](https://docs.amber-lang.com/basic_syntax/basic_syntax) and contains:

    // Define variables
    let name = "John"
    let age = 30
    
    // Display a greeting
    echo "Hello, my name is {name}"
    
    // Perform conditional checks
    if age
So there is no input, everything is known statically. No sanitation required. Any additional checks done by amber in the bash code is unnecessary.

Re: Amber: Programming language compiled to Bash

#320

Post by zem »

fluidcruft wrote: post #315
zem wrote: post #298

Earlier quoted context omitted.

i guess the idea is that you can scp the output script to a machine that has only a minimal *nix install and run it there without having to install anything more. so bash, bc and sed but not python or ruby

That's an argument for POSIX sh, not bash.

that is definitely true! though i wonder whether bash is ubiquitous enough these days that it can serve as an acceptable "we can rely on this being there" shell.
Post reply on HN