Hacker News Reader

Comment by fluidcruft | Hacker News Reader

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...

View on HN

I am wondering why not take an existing language like python, and compile that to bash?

Also for this to be really unique and good it needs insanity like being able to avoid all external dependencies, or else idempotently installing them in ways that can not affect anything else externally, or even temporarily, in multiple crazy various environments including nix? my mind never shuts up

> I am wondering why not take an existing language like python, and compile that to bash?

You'll run into the Alternative Implementation Problem

https://pointersgonewild.com/2024/04/20/the-alternative-impl...

https://news.ycombinator.com/item?id=40337036 - 10 days ago, 84 comments

Relevant excerpt:

> You may read this and think that the key lesson of this post follows the old adage that “if you can’t beat them, join them”. In some ways, I suppose it does. What I want to say is that if you start a project to try and position yourself as an alternative but better implementation of something, you are likely to find yourself stuck in a spot where you’re always playing catch up and living in the shadow of the canonical implementation.

This concept doesn't exactly map 1:1, but gist seems correct. Who wants to program in a worse and very limited version of Python? Who's going to keep things up to date in e.g. Amber as Python continues to evolve? Not fun.

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.

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.

Reply on news.ycombinator.com