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

ZX – A tool for writing better scripts

github.com

Post reply on HN
Print view View original

71–80 of 143 posts

Re: ZX – A tool for writing better scripts

#71

Post by anonymous_sorry »

cultofmetatron wrote: post #38
Fragoel2 wrote: post #17

"[For writing complex scripts] JavaScript is a perfect choice". Not sold on that. Why should I choose it over Python, PHP or others?

yea same here. I wrote nodejs programs for years. the focus on the eventloop and everything being asynchronous is great for servers and network IO but does NOT make it the perfect choice for scripts. Its a different use case entirely. scripts are supposed to be small simple programs that run in sequence and terminate. I shouldn't need to deal with concurrency primitives at all in that particular situation.

> scripts are supposed to be small simple programs that run in sequence and terminate. I shouldn't need to deal with concurrency primitives at all in that particular situation.

I suppose bash pipes are a concurrency primitive, but I don't object to them. I think it's more about appropriate primitives.

Re: ZX – A tool for writing better scripts

#72

Post by okamiueru »

hlandau wrote: post #61
xboxnolifes wrote: post #59

Earlier quoted context omitted.

> And having the file extension be used to switch between two different incompatible source formats is really a terrible design. Isn't that what all file extensions do? Distinguish between incompatible formats?

I've very rarely seen, say, image viewers which can't handle a JPEG with a .png extension or vice versa, but they're badly designed. Most handle this from the file magic automatically. Keying on extension is definitely an antipattern IMO. I don't see people naming C++ files .c++03, .c++11, .c++17. I don't see people naming Perl files .pl-strict-mode. Yes, it's normal for people to use file extensions, but having prog…

> How am I supposed to put a script written using this tool in $PATH?

Separate file that invokes sh or bash and calls the script file with zx and the path to the mjs file.

Should do it.

Though I agree with your objection. The requirement for specific extension while also suggesting a shebang, breaks conventions and expectations. From what I can tell from comments made, it's done that way because they prefer it. Which... is a bit silly. But to each their own.

Re: ZX – A tool for writing better scripts

#73

Post by dspillett »

tehdely wrote: post #45

Useless use of cat in their example script. This is not a serious piece of software.

Maybe the example is intended to be familiar to people who are not script experts?

(rather than an example of how to do things perfectly, according to rabid accolytes of the church of demogification?)

Re: ZX – A tool for writing better scripts

#74

Post by klabetron »

a_wild_dandan wrote: post #26
from-nibly wrote: post #12

Earlier quoted context omitted.

Here's an anecdote to help your gut. I'm a platform engineer who's favorite language is Typescript. I LIVE in the terminal. The only reason I use vscode is cause it's easier to put him into vscode than it is to put vscode into vim. Otherwise I'd be in the terminal for everything but browsing.

Likewise! I use TypeScript everywhere possible, and zx is a godsend. Unfortunately, I've recently dealt with gobs of Python for ML software. After years of writing TypeScript, it's been a...sobering reminder of many painful coding issues that I'd forgotten even existed. Made me deeply appreciate what TS gives us haha.

I worked at a Python shop for a bit. I spent more time than I wish to admit trying to make all of my Python behave like TypeScript (adding typings, etc.).

Re: ZX – A tool for writing better scripts

#76

Post by Vinnl »

larusso wrote: post #54
Fragoel2 wrote: post #17

"[For writing complex scripts] JavaScript is a perfect choice". Not sold on that. Why should I choose it over Python, PHP or others?

Especially because these languages are only one package/install away and not two. I don‘t really get for which audience is targeted here. Usage in JS projects maybe, but then why not write it as npm tasks. .. I‘m playing around with dotnet-scripts [1] at the moment (C# shop mainly) and this has the same issue imho. The reason why I looked into it was because we have developers not accustomed to bash etc. I still find…

> why not write it as npm tasks.

Do you mean writing the entire script in a single line in a string in a JSON file (package.json)? Of do you mean that string just calling out to a non-inline script? Because the use case for this is very much that latter script - it will often still be started via `npm run`.

Re: ZX – A tool for writing better scripts

#77

Post by Vinnl »

bandergirl wrote: post #51

It looks like people don’t get it. This isn’t “better” than your tool of choice. This is a tool for JavaScript developers to write non-trivial scripts in a portable way without getting lost in POSIX hell. Who came up with this stuff? https://stackoverflow.com/a/13373256 If you can write shell code, Perl, Python, COBOL, suit yourself. This is for JavaScript developers in JavaScript projects.

Here's an example: https://gitlab.com/vincenttunru/penny/-/blob/main/scripts/bu...

That used to be a shell script. But this I can way more easily read (even after not touching it for a long time), I get autocompletion, and I can use the APIs I'm already familiar with. It's a pretty neat QoL improvement for me specifically.

Re: ZX – A tool for writing better scripts

#78

Post by drowsspa »

Mawr wrote: post #50

Well this doesn't make much sense. If you rightfully find bash inadequate at some point, just switch to the next most natural tool - Python. Nobody's going to be surprised when they see a Python script. If you start feeling Python is inadequate too, then: 1) You're wrong, just stick to Python 2) If you're so bent on doing away with familiarity, at least get as much leverage as you can in return and use a "proper" lan…

Honestly this looks better than Python. I hate all the subprocess.run([...], check=True, universal_newlines=True) and then you have the manage the dependency hell of virtualenvs. At least with node the node_modules is right there.

Re: ZX – A tool for writing better scripts

#79

Post by mkl »

dang wrote: post #64

Related: Zx 3.0 - https://news.ycombinator.com/item?id=28195580 - Aug 2021 (163 comments) JavaScript for Shell Scripting - https://news.ycombinator.com/item?id=27072515 - May 2021 (181 comments)

And similar:

The Bun Shell - https://news.ycombinator.com/item?id=39071688 - Jan 2024 (225 comments)

Re: ZX – A tool for writing better scripts

#80

Post by dspillett »

teo_zero wrote: post #46

The first command of the first example is a cat|grep... How can I assume the author is an experienced script writer? In any case, ZX replaces some of the shell's usual quirks with its own different quirks: you have to manually expand * with glob() and ~ with os.homedir(), you can't build commands as strings without repeated calls to push(), etc.

> example is a cat|grep... How can I assume the author is an experienced script writer?

Perhaps because they are writing documentation that can be understood be less experienced script writers as well as themselves, using a very common example seen everywhere?

I find "cat full | ..." keeps the left-to-right flow of a command nicely, and is better understood by those less familiar with shell work than prepending "Yes, it is an extra process. Yes this is less efficient, both due to the fork and the extra IPC along the pipe. But even under Windows where spawning a process is massively more costly than other OSs¹, if you are that worried about this bit of inefficiency² then perhaps you have picked the wrong tool for the job in using a shell/script in the first place?³

> with its own different quirks

I agree there. Though I can see that for some, starting from already using JS via node, this might be an acceptable trade-off.

--

[0] I sometimes also use it in part to wind up the cult of demogification, because they seem to both want to be wound up and deserve to be wound up :-)

[1] Complain to MS about that, not me and my script/one-liner.

[2] Are you using it in a tight loop? Maybe if you are doing something over thousands of files, but then the resources used by the something likely dwarf the cost of cat into irrelevance.

[3] A question that suggests the supplementary: are you an experienced ?

Post reply on HN